On 04/02/2018 06:58 PM, Marcus D. Leech wrote:
> On 04/02/2018 06:09 PM, Philip Balister wrote:
>> On 04/02/2018 05:01 PM, MASDR GS wrote:
>>> I'm having issues with installing GNU radio using PYBOMBS. It
>>> successfully
>>> installs the SDK and UHD but once it reaches to GNU Radio I receive a
>>>
On 04/02/2018 06:09 PM, Philip Balister wrote:
On 04/02/2018 05:01 PM, MASDR GS wrote:
I'm having issues with installing GNU radio using PYBOMBS. It successfully
installs the SDK and UHD but once it reaches to GNU Radio I receive a
missing python six message. I have been using this guide from Et
On 04/02/2018 05:01 PM, MASDR GS wrote:
> I'm having issues with installing GNU radio using PYBOMBS. It successfully
> installs the SDK and UHD but once it reaches to GNU Radio I receive a
> missing python six message. I have been using this guide from Ettus for
> reference.
>
> https://kb.ettus.c
I'm having issues with installing GNU radio using PYBOMBS. It successfully
installs the SDK and UHD but once it reaches to GNU Radio I receive a
missing python six message. I have been using this guide from Ettus for
reference.
https://kb.ettus.com/Software_Development_on_the_E310_and_E312#Prepara
Hello
I was trying to generate a flow graph using file source descriptor and a file
sink. But after generating the output instead of writing to the file, it
prints the output in the screen. Below is the code. Please let me know where I
am going wrong.
gr::blocks::file_descriptor_source::sp
On Mon, 2018-04-02 at 13:44 -0400, Andy Walls wrote:
> > All PLL based symbol clock recovery blocks/methods in GNURadio
> require
> symbol centers to be peaked.
Slight correction. The MSK TED's don't require the input pulses to be
peaked, but that's because they operate on the FM'ed pulses, and
> Date: Mon, 2 Apr 2018 09:48:00 +0100
> From: Thomas Habets
> Hi.
>
> As an experiment I'm trying to decode an FT8 signal I've captured.
> I've
> gotten far enough that I can clearly see the packet (
> https://blog.habets.se/tmp/ft8_packet.png), but now I want to
> actually turn
> that into bits.
On 04/02/2018 07:51 AM, Thomas Habets wrote:
It is indeed an amateur M-FSK. Like I said it's FT8[1] which is 8FSK,
and was captured at 14.074MHz.
I've captured some 20m, 30m, and 40m (at the same time, because 10Msps
is enough for that) and the goal is not so much actually learning what
the m
Thanks, hadn't seen it. I'm afraid it's a little over my head right now.
Adrian
On April 2, 2018 1:08:35 PM UTC, Anon Lister wrote:
>I don't know if you saw his presentation but Andy Walls did a talk on
>the
>new clock recovery block he wrote to address issues he had with
>existing
>ones. I beli
I don't know if you saw his presentation but Andy Walls did a talk on the
new clock recovery block he wrote to address issues he had with existing
ones. I believe it's in tree now?
https://www.gnuradio.org/wp-content/uploads/2017/12/Andy-Walls-Samples-to-Digital-Symbols.pdf
On Mon, Apr 2, 2018, 0
I should add that the main problem I face is getting it synchronized fast
enough for short bursts.
Adrian
On April 2, 2018 11:54:21 AM UTC, Thomas Habets wrote:
>I just seem to recall that being said.
>
>I've used M&M successfully in the past, but it does require some
>massaging
>of the data to
Hi Thomas,
I use it for 4FSK, it does work, not optimally it seems, but I attribute that
to my lack of understandimg of the algorithm.
Regarding the square wave issue, I use a low pass filter in front of it with
bandwidth = samp-rate / samples-per-symbol.
Regards,
Adrian
On April 2, 2018 11:54
I just seem to recall that being said.
I've used M&M successfully in the past, but it does require some massaging
of the data to not be "square wave" before it'll work. Also does it work
(well) for M-FSK?
On 2 April 2018 at 11:16, Adrian Musceac wrote:
> Hi,
>
> Why is the M&M algorithm discour
It is indeed an amateur M-FSK. Like I said it's FT8[1] which is 8FSK, and
was captured at 14.074MHz.
I've captured some 20m, 30m, and 40m (at the same time, because 10Msps is
enough for that) and the goal is not so much actually learning what the
messages are as learning to decode them. I use fldig
I don't think there's a preamble. Yeah it looks good except @4.75s into the
screenshot where it's half one bit, half another. But that should be fine.
There's supposed to be lots of redundancy in the protocol so I should be
able to extract it.
I think where it jumps around it's just noise.
On 2 A
The gr-op25 code handles 4FSK. The demod and slicer code might be
expanded to 8FSK.
On 04/02/2018 06:22 AM, Jeff Long wrote:
This looks like an amateur M-FSK signal. You might have luck with fldigi
and save yourself some work. It uses FFTs and then analyzes frequency
shifts. You could do some
This looks like an amateur M-FSK signal. You might have luck with fldigi
and save yourself some work. It uses FFTs and then analyzes frequency
shifts. You could do some of this in GR, but syncing to the signal would
be hard because you would miss a few transitions trying to get synced.
On 04/0
Hi,
Why is the M&M algorithm discouraged?
I use successfully both in FSK and PSK demodulators. It seems to perform fine.
Regards,
Adrian
On April 2, 2018 8:48:00 AM UTC, Thomas Habets wrote:
>Hi.
>
>As an experiment I'm trying to decode an FT8 signal I've captured. I've
>gotten far enough that
Hi Thomas,
This is a very nice demodulation! Congratulations!
Regarding frequency sync: I count roughly 80 bits in your packet. Is there some
synchronization preamble perhaps in the beginning, where the quad demod jumps
around?
Best regards,
Marcus
On 2 April 2018 10:48:00 GMT+02:00, Thomas H
Hi.
As an experiment I'm trying to decode an FT8 signal I've captured. I've
gotten far enough that I can clearly see the packet (
https://blog.habets.se/tmp/ft8_packet.png), but now I want to actually turn
that into bits.
I know it's 8FSK (the above screenshot is quad demod of that), but I have a
20 matches
Mail list logo
