Re: [Discuss-gnuradio] Ettus N210 GMSK 9600

[Tom Golden]

Thanks.  I'm climbing the learning curve. :)

The radio I'm testing isn't AFSK, it's GMSK/FSK 9600.  So I think it may be
scrambled.  I'm sending packets that are 255 bytes contains 0xA5 - and I
have a ruby program that checks starting at every bit for A5, the inverse
of A5, NRZ decode for A5, and NRZI decode for A5.  Regardless of the
corr_est, the MSK Timing Recovery does seem to recovery the timing and bits
for most of the packet which should yield some strings of A5 is the bits.
But I'm just not seeing that.

I did see some references on the web about scrambling for FSK9600 - so
that's the rabbit hole I went down.


On Sat, Mar 26, 2016 at 11:20 AM, Tom McDermott  wrote:

> HI Tom - AX.25 is NRZI coded.   What that means is that the
> encoder toggles the state of a flip flop when the input data is zero
> (i.e. a JK flip flop). The output of that flipflop is the NRZI encoded
> data stream.
>
> AX.25 FM Radio AFSK audio is not scrambled.
> Some 9600 baud FSK (not audio) links may be scrambled.
>
> To un-do the NRZI coding, send the NRZI data into one input of an
> exclusive-or gate and the D input of a D flip flop at the same time.
> The Q-bar output of the flipflop is exclusive-or'ed with the NRZI data
> (XOR the D-in and Q-bar output of the FF).
>
> -- Tom, N5EG
>
>
>
> On Sat, Mar 26, 2016 at 9:13 AM, Tom Golden  wrote:
>
>> Thanks - I'll give it a try.
>>
>>
>> On Sat, Mar 26, 2016 at 10:09 AM, Andy Walls > > wrote:
>>
>>> Hi Tom,
>>>
>>> The corr_est block needs to match against the NRZI encoded symbols, so
>>> yes I used 7 ones for the hdlc flag.
>>>
>>> The HDLC flag has two possible NRZI encodings depending on the initial
>>> state:
>>>
>>>   0110   - HDLC flag byte
>>> 1 0001  - NRZI encoded HDLC flag byte, initial state 1
>>>
>>>   0110  - HDLC flag byte
>>> 0 1110  - NRZI encoded HDLC flag byte, initial state 0
>>>
>>>
>>> So encoding your two byte sequence:
>>>
>>>   0110 0011
>>> 1 0001 01101011
>>> or
>>> 0 1110 10010100
>>>
>>> You should build your corr_est preamble samples based on one of these.
>>>
>>> Regards,
>>> Andy
>>>
>>
>>
>> ___
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Ettus N210 GMSK 9600

[Tom Golden]

Thanks - I'll give it a try.


On Sat, Mar 26, 2016 at 10:09 AM, Andy Walls 
wrote:

> Hi Tom,
>
> The corr_est block needs to match against the NRZI encoded symbols, so yes
> I used 7 ones for the hdlc flag.
>
> The HDLC flag has two possible NRZI encodings depending on the initial
> state:
>
>   0110   - HDLC flag byte
> 1 0001  - NRZI encoded HDLC flag byte, initial state 1
>
>   0110  - HDLC flag byte
> 0 1110  - NRZI encoded HDLC flag byte, initial state 0
>
>
> So encoding your two byte sequence:
>
>   0110 0011
> 1 0001 01101011
> or
> 0 1110 10010100
>
> You should build your corr_est preamble samples based on one of these.
>
> Regards,
> Andy
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Ettus N210 GMSK 9600

[Tom Golden]

I've been staring at the de-modulator and I really think it's correct.
Unfortunately amateur packet radio isn't well documented (at least for me).

I think there's a scambler I'm not taking into account.  Does anyone know
the specifics of this?  Or can point me to how to what the parameters of
the descrambler block mean and/or how to determine their settings (my best
guess is it's a 17-bit LFSR with a polynomial of 1+x^12+x^17)?


On Sat, Mar 26, 2016 at 8:31 AM, Tom Golden  wrote:

> Thanks Andy.  I changed the hdlc_flag_nrzi to:
>
> [0]+[1]*6+[0]+[0,0,1,0,0,0,0,1]
>
> The frame byte is 0x7E and 0x84 (LSB first) is the first address byte.
> I'm not sure if you used 7 ones instead of 6 on purpose.
>
> On Fri, Mar 25, 2016 at 4:25 PM, Andy Walls 
> wrote:
>
>> On Fri, 2016-03-25 at 11:07 -0600, Tom Golden wrote:
>>
>>
>> > AX.25 data is NRZI encoded (so inverse bits and then NRZ).  I hand
>> > calculated the HDLC frame start byte and first few address bytes so
>> > the corr_est only triggers at the start of the packet.
>>
>> I've added NRZI decoding and encoding and adjusted the correlation
>> pattern for the HDLC flag in the attached.
>>
>>
>> >   Seems to trigger but I had to lower the threshold down to .390.
>>
>> Something seems wrong.  Look at how a build the preamble samples in my
>> flowgraph.  Since I use the GMSK Modulator to build the preamble
>> samples, it has a bit of a delay, and I have to discard the first 1.5
>> symbols or so of samples.  (GMSK with L=4).
>>
>> Also note, that unlike PSK, which will correlate to both the normal and
>> inverted preamble (since it's just a 180 phase shift), for FSK the
>> corr_est block will only correlate to the version of the preamble you
>> specify, and not the inverted one (different frequencies don't
>> correlate).
>>
>>
>> >
>> > I have a separate program I'm using to check for the bit pattern I'm
>> > sending (0xA5, 0xA5, ...).  It checks against raw, nrz, and nrzi to
>> > see if the pattern is present.  It's present in 2 bytes and the data
>> > after those 2 bytes is wrong but consistent - which I think points to
>> > a timing issue.
>> >
>> >
>> > I think the fact that I had to reduce the threshold down to 0.390
>> > points to the same issue as the bits not coming out correctly.
>>
>> I'm not sure.  I added the HDLC deframer in the flowgraph to decode the
>> packet bytes for you.  It won't spit out anything though, if the CRC
>> check fails.  You may want to hack the block to output data even when
>> the CRC fails; just to see if things look sane.
>>
>> The HDLC deframer was originally used for AIS, but it will generically
>> deframe any HDLC (hopefully!).
>>
>> -Regards,
>> Andy
>>
>> >
>> > On Fri, Mar 25, 2016 at 10:51 AM, Andy Walls
>> >  wrote:
>> > On Fri, 2016-03-25 at 12:22 -0400, Andy Walls wrote:
>> > > On Fri, 2016-03-25 at 12:00 -0400,
>> > discuss-gnuradio-requ...@gnu.org
>> > > wrote:
>> >
>> > > FWIW, I couldn't get the attached flowgraph (which looks to
>> > correlate to
>> > > the HDLC flag) to crash.  I was probably just lucky.
>> >
>> > I forgot to mention, in the flowgraphs I winged up:
>> >
>> > a) I might have the sense of 0 and 1 symbols reversed.  Right
>> > now I have
>> > 0 symbols as the low frequency and 1 symbols as the high
>> > frequency, but
>> > that guess could be wrong.  (The convention for AFSK systems
>> > is usually
>> > the reverse of what I have, for example.)
>> >
>> > b) I'm assuming the data bits are not differentially encoded
>> > or NRZI
>> > encoded.  That could be wrong.  AIS uses NRZI, for example.
>> >
>> > -Regards,
>> > Andy
>> >
>> >
>> >
>> >
>> >
>>
>>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Ettus N210 GMSK 9600

[Andy Walls]

Hi Tom,

The corr_est block needs to match against the NRZI encoded symbols, so yes I 
used 7 ones for the hdlc flag.

The HDLC flag has two possible NRZI encodings depending on the initial state:

  0110   - HDLC flag byte
1 0001  - NRZI encoded HDLC flag byte, initial state 1

  0110  - HDLC flag byte
0 1110  - NRZI encoded HDLC flag byte, initial state 0


So encoding your two byte sequence:

  0110 0011
1 0001 01101011
or
0 1110 10010100

You should build your corr_est preamble samples based on one of these.

Regards,
Andy

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Ettus N210 GMSK 9600

[Tom Golden]

Thanks Andy.  I changed the hdlc_flag_nrzi to:

[0]+[1]*6+[0]+[0,0,1,0,0,0,0,1]

The frame byte is 0x7E and 0x84 (LSB first) is the first address byte.  I'm
not sure if you used 7 ones instead of 6 on purpose.

On Fri, Mar 25, 2016 at 4:25 PM, Andy Walls 
wrote:

> On Fri, 2016-03-25 at 11:07 -0600, Tom Golden wrote:
>
>
> > AX.25 data is NRZI encoded (so inverse bits and then NRZ).  I hand
> > calculated the HDLC frame start byte and first few address bytes so
> > the corr_est only triggers at the start of the packet.
>
> I've added NRZI decoding and encoding and adjusted the correlation
> pattern for the HDLC flag in the attached.
>
>
> >   Seems to trigger but I had to lower the threshold down to .390.
>
> Something seems wrong.  Look at how a build the preamble samples in my
> flowgraph.  Since I use the GMSK Modulator to build the preamble
> samples, it has a bit of a delay, and I have to discard the first 1.5
> symbols or so of samples.  (GMSK with L=4).
>
> Also note, that unlike PSK, which will correlate to both the normal and
> inverted preamble (since it's just a 180 phase shift), for FSK the
> corr_est block will only correlate to the version of the preamble you
> specify, and not the inverted one (different frequencies don't
> correlate).
>
>
> >
> > I have a separate program I'm using to check for the bit pattern I'm
> > sending (0xA5, 0xA5, ...).  It checks against raw, nrz, and nrzi to
> > see if the pattern is present.  It's present in 2 bytes and the data
> > after those 2 bytes is wrong but consistent - which I think points to
> > a timing issue.
> >
> >
> > I think the fact that I had to reduce the threshold down to 0.390
> > points to the same issue as the bits not coming out correctly.
>
> I'm not sure.  I added the HDLC deframer in the flowgraph to decode the
> packet bytes for you.  It won't spit out anything though, if the CRC
> check fails.  You may want to hack the block to output data even when
> the CRC fails; just to see if things look sane.
>
> The HDLC deframer was originally used for AIS, but it will generically
> deframe any HDLC (hopefully!).
>
> -Regards,
> Andy
>
> >
> > On Fri, Mar 25, 2016 at 10:51 AM, Andy Walls
> >  wrote:
> > On Fri, 2016-03-25 at 12:22 -0400, Andy Walls wrote:
> > > On Fri, 2016-03-25 at 12:00 -0400,
> > discuss-gnuradio-requ...@gnu.org
> > > wrote:
> >
> > > FWIW, I couldn't get the attached flowgraph (which looks to
> > correlate to
> > > the HDLC flag) to crash.  I was probably just lucky.
> >
> > I forgot to mention, in the flowgraphs I winged up:
> >
> > a) I might have the sense of 0 and 1 symbols reversed.  Right
> > now I have
> > 0 symbols as the low frequency and 1 symbols as the high
> > frequency, but
> > that guess could be wrong.  (The convention for AFSK systems
> > is usually
> > the reverse of what I have, for example.)
> >
> > b) I'm assuming the data bits are not differentially encoded
> > or NRZI
> > encoded.  That could be wrong.  AIS uses NRZI, for example.
> >
> > -Regards,
> > Andy
> >
> >
> >
> >
> >
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Ettus N210 GMSK 9600

[Andy Walls]

On Fri, 2016-03-25 at 11:07 -0600, Tom Golden wrote:


> AX.25 data is NRZI encoded (so inverse bits and then NRZ).  I hand
> calculated the HDLC frame start byte and first few address bytes so
> the corr_est only triggers at the start of the packet.

I've added NRZI decoding and encoding and adjusted the correlation
pattern for the HDLC flag in the attached.


>   Seems to trigger but I had to lower the threshold down to .390.

Something seems wrong.  Look at how a build the preamble samples in my
flowgraph.  Since I use the GMSK Modulator to build the preamble
samples, it has a bit of a delay, and I have to discard the first 1.5
symbols or so of samples.  (GMSK with L=4).

Also note, that unlike PSK, which will correlate to both the normal and
inverted preamble (since it's just a 180 phase shift), for FSK the
corr_est block will only correlate to the version of the preamble you
specify, and not the inverted one (different frequencies don't
correlate).


> 
> I have a separate program I'm using to check for the bit pattern I'm
> sending (0xA5, 0xA5, ...).  It checks against raw, nrz, and nrzi to
> see if the pattern is present.  It's present in 2 bytes and the data
> after those 2 bytes is wrong but consistent - which I think points to
> a timing issue.
> 
> 
> I think the fact that I had to reduce the threshold down to 0.390
> points to the same issue as the bits not coming out correctly.

I'm not sure.  I added the HDLC deframer in the flowgraph to decode the
packet bytes for you.  It won't spit out anything though, if the CRC
check fails.  You may want to hack the block to output data even when
the CRC fails; just to see if things look sane.

The HDLC deframer was originally used for AIS, but it will generically
deframe any HDLC (hopefully!).

-Regards,
Andy

> 
> On Fri, Mar 25, 2016 at 10:51 AM, Andy Walls
>  wrote:
> On Fri, 2016-03-25 at 12:22 -0400, Andy Walls wrote:
> > On Fri, 2016-03-25 at 12:00 -0400,
> discuss-gnuradio-requ...@gnu.org
> > wrote:
> 
> > FWIW, I couldn't get the attached flowgraph (which looks to
> correlate to
> > the HDLC flag) to crash.  I was probably just lucky.
> 
> I forgot to mention, in the flowgraphs I winged up:
> 
> a) I might have the sense of 0 and 1 symbols reversed.  Right
> now I have
> 0 symbols as the low frequency and 1 symbols as the high
> frequency, but
> that guess could be wrong.  (The convention for AFSK systems
> is usually
> the reverse of what I have, for example.)
> 
> b) I'm assuming the data bits are not differentially encoded
> or NRZI
> encoded.  That could be wrong.  AIS uses NRZI, for example.
> 
> -Regards,
> Andy
> 
> 
> 
> 
> 



gmsk9600_test2.grc
Description: XML document
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Ettus N210 GMSK 9600

[Tom Golden]

AX.25 data is NRZI encoded (so inverse bits and then NRZ).  I hand
calculated the HDLC frame start byte and first few address bytes so the
corr_est only triggers at the start of the packet.  Seems to trigger but I
had to lower the threshold down to .390.

I have a separate program I'm using to check for the bit pattern I'm
sending (0xA5, 0xA5, ...).  It checks against raw, nrz, and nrzi to see if
the pattern is present.  It's present in 2 bytes and the data after those 2
bytes is wrong but consistent - which I think points to a timing issue.

I think the fact that I had to reduce the threshold down to 0.390 points to
the same issue as the bits not coming out correctly.


On Fri, Mar 25, 2016 at 10:51 AM, Andy Walls 
wrote:

> On Fri, 2016-03-25 at 12:22 -0400, Andy Walls wrote:
> > On Fri, 2016-03-25 at 12:00 -0400, discuss-gnuradio-requ...@gnu.org
> > wrote:
>
> > FWIW, I couldn't get the attached flowgraph (which looks to correlate to
> > the HDLC flag) to crash.  I was probably just lucky.
>
> I forgot to mention, in the flowgraphs I winged up:
>
> a) I might have the sense of 0 and 1 symbols reversed.  Right now I have
> 0 symbols as the low frequency and 1 symbols as the high frequency, but
> that guess could be wrong.  (The convention for AFSK systems is usually
> the reverse of what I have, for example.)
>
> b) I'm assuming the data bits are not differentially encoded or NRZI
> encoded.  That could be wrong.  AIS uses NRZI, for example.
>
> -Regards,
> Andy
>
>
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Ettus N210 GMSK 9600

[Andy Walls]

On Fri, 2016-03-25 at 12:22 -0400, Andy Walls wrote:
> On Fri, 2016-03-25 at 12:00 -0400, discuss-gnuradio-requ...@gnu.org
> wrote:

> FWIW, I couldn't get the attached flowgraph (which looks to correlate to
> the HDLC flag) to crash.  I was probably just lucky.

I forgot to mention, in the flowgraphs I winged up:

a) I might have the sense of 0 and 1 symbols reversed.  Right now I have
0 symbols as the low frequency and 1 symbols as the high frequency, but
that guess could be wrong.  (The convention for AFSK systems is usually
the reverse of what I have, for example.)

b) I'm assuming the data bits are not differentially encoded or NRZI
encoded.  That could be wrong.  AIS uses NRZI, for example.

-Regards,
Andy




___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Ettus N210 GMSK 9600

[Andy Walls]

On Fri, 2016-03-25 at 12:00 -0400, discuss-gnuradio-requ...@gnu.org
wrote:

> I do have that fix in place.  I added the tag_debug for time_est.  I'm
> not
> sure which value causes the error, but I see:
> 

> thread[thread-per-block[17]: ]:
> mmse_fir_interpolator_cc: imu out of bounds.
> 
> 
> --
> Tag Debug: corr_est
> Input Stream: 00
>   Offset: 40221  Source: corr_est_cc0 Key: time_est   Value: 0.0493416
>   Offset: 40231  Source: corr_est_cc0 Key: time_est   Value: -0.022505
>   Offset: 40271  Source: corr_est_cc0 Key: time_est   Value: 0.305939
>   Offset: 40292  Source: corr_est_cc0 Key: time_est   Value: 0.130002
>   Offset: 40302  Source: corr_est_cc0 Key: time_est   Value: -1.17942
And there it is --
:(


--
> Tag Debug: corr_est
> Input Stream: 00
>   Offset: 46763  Source: corr_est_cc0 Key: time_est   Value: 0.0567441
>   Offset: 46773  Source: corr_est_cc0 Key: time_est   Value: -1.31157
> And there is another -
:(



The corr_est block shouldn't be outputing values outside of [-1.0, 1.0].
The msk_timing_recovery block should do the right thing for values
within [-1.0, 1.0] and do something sensible for values outside of that
range.

Right now the msk_timing_recovery block only does the right thing for
values in the range [0.0, 1.0), does the wrong thing (I think) for
values in (-1.0, 0.0), and bombs out for values outside of that range.


So two fixes have to take place:

a) the msk_timing_recovery block needs to handle all time_est values
properly, including garbage values.

b) the corr_est block needs to be fixed to generate time_est values
restricted to the range (-1.0, 1.0) 


I'm booked up until April 4th, so don't wait for fixes from me, if
you're in a hurry.

FWIW, I couldn't get the attached flowgraph (which looks to correlate to
the HDLC flag) to crash.  I was probably just lucky.

-Andy


gmsk9600_test2.grc
Description: XML document
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Ettus N210 GMSK 9600

[Tom Golden]

I do have that fix in place.  I added the tag_debug for time_est.  I'm not
sure which value causes the error, but I see:


--
Tag Debug: corr_est
Input Stream: 00
  Offset: 37840  Source: corr_est_cc0 Key: time_est   Value: 0.363934
  Offset: 37851  Source: corr_est_cc0 Key: time_est   Value: -0.478847
  Offset: 37871  Source: corr_est_cc0 Key: time_est   Value: 0.226898
--

--
Tag Debug: corr_est
Input Stream: 00
  Offset: 38211  Source: corr_est_cc0 Key: time_est   Value: 0.379335
  Offset: 38341  Source: corr_est_cc0 Key: time_est   Value: -0.205535
  Offset: 38351  Source: corr_est_cc0 Key: time_est   Value: 0.129156
--

--
Tag Debug: corr_est
Input Stream: 00
  Offset: 38981  Source: corr_est_cc0 Key: time_est   Value: -0.0236422
--

--
Tag Debug: corr_est
Input Stream: 00
  Offset: 39911  Source: corr_est_cc0 Key: time_est   Value: -0.270991
  Offset: 39921  Source: corr_est_cc0 Key: time_est   Value: -0.381561
--
thread[thread-per-block[17]: ]:
mmse_fir_interpolator_cc: imu out of bounds.


--
Tag Debug: corr_est
Input Stream: 00
  Offset: 40221  Source: corr_est_cc0 Key: time_est   Value: 0.0493416
  Offset: 40231  Source: corr_est_cc0 Key: time_est   Value: -0.022505
  Offset: 40271  Source: corr_est_cc0 Key: time_est   Value: 0.305939
  Offset: 40292  Source: corr_est_cc0 Key: time_est   Value: 0.130002
  Offset: 40302  Source: corr_est_cc0 Key: time_est   Value: -1.17942
  Offset: 40322  Source: corr_est_cc0 Key: time_est   Value: 0.117131
--

--
Tag Debug: corr_est
Input Stream: 00
  Offset: 41311  Source: corr_est_cc0 Key: time_est   Value: 0.338163
--

--
Tag Debug: corr_est
Input Stream: 00
  Offset: 41452  Source: corr_est_cc0 Key: time_est   Value: -0.18281
--

--
Tag Debug: corr_est
Input Stream: 00
  Offset: 41522  Source: corr_est_cc0 Key: time_est   Value: 0.491506
  Offset: 41651  Source: corr_est_cc0 Key: time_est   Value: 0.151281
  Offset: 41942  Source: corr_est_cc0 Key: time_est   Value: 0.0604672
  Offset: 41952  Source: corr_est_cc0 Key: time_est   Value: -0.191828
--

--
Tag Debug: corr_est
Input Stream: 00
  Offset: 42582  Source: corr_est_cc0 Key: time_est   Value: -0.281153
--

--
Tag Debug: corr_est
Input Stream: 00
  Offset: 44901  Source: corr_est_cc0 Key: time_est   Value: -0.495743
  Offset: 44911  Source: corr_est_cc0 Key: time_est   Value: 0.380034
--

--
Tag Debug: corr_est
Input Stream: 00
  Offset: 45742  Source: corr_est_cc0 Key: time_est   Value: -0.123585
  Offset: 46022  Source: corr_est_cc0 Key: time_est   Value: 0.0915709
--

--
Tag Debug: corr_est
Input Stream: 00
  Offset: 46171  Source: corr_est_cc0 Key: time_est   Value: 0.0782069
--

--
Tag Debug: corr_est
Input Stream: 00
  Offset: 46763  Source: corr_est_cc0 Key: time_est   Value: 0.0567441
  Offset: 46773  Source: corr_est_cc0 Key: time_est   Value: -1.31157
  Offset: 46842  Source: corr_est_cc0 Key: time_est   Value: -0.484528
--

--
Tag Debug: corr_est
Input Stream: 00
  Offset: 47372  Source: corr_est_cc0 Key: time_est   Value: -0.388704

Re: [Discuss-gnuradio] Ettus N210 GMSK 9600

[Andy Walls]

  From: 
Tom Golden


Date: 
Thu, 24 Mar 2016 13:07:57 -0600


>Sorry - I was attempting to be courteous to other users.

No worries.  It's just that others can't learn and contribute, if the
conversation goes off list.  Also, I charge for private consulting. ;)

If other users don't like on-topic posts, then I suppose they'll be
unsubscribing shortly anyway.


>I added a Correlation Estimator before the MSK Timing Recover looking
>for 0x7E (the start frame byte for AX.25).  I think it found it (based
>on the image below) - unfortunately when it hits, execution stops with
>the error:


>thread[thread-per-block[9]: ]:
>mmse_fir_interpolator_cc: imu out of bounds.

Ah crud, that bug.

OK, in the MSK timing recovery block, "mu" is an inter-sample distance
in the range [0.0, 1.0), which gets passed to the mmse_fir_interpolator
to interpolate between samples.

The MSK timing recovery block doesn't do enough sanity checking on the
"time_est" tag payload value produced by the corr_est block, so it
screws up its internal value of "mu" and then bombs.

Does your version of gnuradio have this fix in place:
https://github.com/gnuradio/gnuradio/blob/master/gr-digital/lib/msk_timing_recovery_cc_impl.cc#L150
?

If you run the flowgraph again, can you put a tag_debug block on the
output of the corr_est block to dump out the values of the "time_est"
tag.  I'm curious as to what value of "time_est" coming out of the
corr_est block may be tripping up the msk_timing_recovery_block.


-Andy





___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Ettus N210 GMSK 9600

[Andy Walls]

Hi Tom:

On Thu, 2016-03-24 at 08:56 -0600, Tom Golden wrote:
> Feel free to ignore this request - as you've helped me quite a lot.

This is the last one I'll respond to that isn't on list.


> I'm sending packets of N bytes containing repeating  in the
> data.  Using you're model, I tapped off of the binary slicer to save
> the bits to a file.  I think I'm in a good position SNR wise now - but
> I'm not seeing any repeated patterns in the data.  Any additional sage
> wisdom?

Well, unless you pack the bits into bytes, things will be hard to see in
the file.  

Even then, if you don't use blocks to find your preamble and line things
up, then you might see your pattern shifted in the resulting bytes.

>From looking at the data, it looks like you have a preamble that is
something like 

0x00 0x00 .. 0x00 0x55 0x01 0x04 ...

The long stream of 0's could fool the square and sync coarse frequency
sync, so be mindful of that.  You might have to do a smarter, data-aided
coarse frequency sync using your received preamble compared to a
reference preamble instead.

The MSK Timing recovery block isn't converging rapidly enough on the
0x55 to get you the right bits for that part of the preamble.
You should consider using the corr_est block to detect and tag your
preamble, so the MSK timing recovery block gets reset when it sees the
tag and converges rapidly on your preamble.

The frequency deviation is higher than I would expect for GMSK at 9600
baud with a BT of 0.4, which is +/- 2400 Hz max.  Check your modulation
index is 0.5, otherwise you're GFSK instead of GMSK; in case you care
about that.

Regards,
Andy

> 
> 
> Thanks,
> -Tom
> 
> 
> 
> On Wed, Mar 23, 2016 at 6:41 PM, Tom Golden <tgolden...@gmail.com>
> wrote:
> Hi Andy,
> 
> 

> 

> Thanks so much for the link!  I'm digging into the gr-ais code
> - but there's certainly a learning curve there. :)
> 
> 
> Thanks!!
> -Tom
> 
> 
> 
> On Wed, Mar 23, 2016 at 5:28 PM, Andy Walls
> <a...@silverblocksystems.net> wrote:
> 
> >  From:
>     > Tom Golden
>     >   Subject:
> > Re: [Discuss-gnuradio] Ettus N210
> > GMSK 9600
> >  Date:
> > Wed, 23 Mar 2016 13:14:18 -0600
> >
> >
> 
> __
> > Here's my flow-graph along with a snapshot of the
> constellation and
> > FFT.
> >
> >
> > Thanks!!
> > -Tom
> 
> Hi Tom,
> 
> A couple of things:
> 
> a) The polyphase resampler isn't going to work well
> without a filter
> definition in the taps field.
> 
> b) The constellation sink will not display anything
> meaningful without
> sample timing synchronization; it is not useful at its
> current position
> in the flowgraph.  The constellation sink also doesn't
> display anything
> useful for an FSK modulation normally; (G)MSK being an
> exception, if
> treating it like a PSK modulation vs. FSK.
> 
> c) You don't have any coarse or fine frequency
> synchronization.  That
> will cause you major problems, if trying to treat GMSK
> as a PSK
> modulation.  It will cause you minor problems, if
> treating GMSK as an
> FSK modulation.
> 
> d) Timing recovery blocks usually want a signal that
> has peaks (which
> you get by putting the signal through a matched
> filter), and those peaks
> should nominally be scaled to +/- 1.0.  You don't have
> a matched filter
> or an AGC before the Clock Recovery block.
> 
> e) The USRP's 0 dB gain setting is actually the USRP
> inserting the
> maximum attenuation it can (e.g. 37 dB of
> attenuation).  That can kill
> your signal to noise ratio.  

Re: [Discuss-gnuradio] Ettus N210 GMSK 9600

[Marcus D. Leech]

On 03/23/2016 10:08 PM, Dan CaJacob wrote:
Derek is spot on.  0 dB into any USRP is screaming loud.  Most of the 
units are very sensitive, so it's perfectly fine to err on the side of 
too much attenuation to start and dial the gain as you need.  It 
depends on the USRP type, but signals much above -15dB can physically 
damage the hardware if you set the gain too high.
I'd actually said most of this to Tom privately, but forgot to copy the 
list.


It's instructive to consider what kind of "normal" signals one might 
expect to receive on a receiver intended to be connected to an antenna.


Consider your average +70dBm (10kW) FM station.10km away from the 
TX, we expect about 90dB path loss, which means that the
  theoretical power seen by your antenna would be about -20dBm. Perhaps 
a bit more, since the TX antenna won't be strictly isotropic.


At 50km away, that's 100dB of path loss, giving about -30dBm at your 
antenna terminals (ballpark, hand-waving).  Now, a signal of
  -30dBm is actually considered fairly strong, and your typical FM 
receiver will produce a very nice, nearly-noise-free output from

  signals entering your antenna at levels of -30dBm.

The RX inputs of most SDRs (Ettus radio are no exception) are designed 
for the kinds of signal levels that are typical in "connected to
  an antenna" environment.  They are less well suited to "connected to 
a laboratory signal generator", without significant attenuation.


The RF signal levels floating around in a lab are typically much 
"louder" than you might find "on air", so if one is used to lab conditions,
  it may not be obvious that a sensitive receiver designed for "from 
the air" reception would be unhappy in laboratory signal-level

  conditions.  So, keep the levels very modest indeed.




On Wed, Mar 23, 2016 at 9:35 PM Derek Kozel <derek.ko...@ettus.com 
<mailto:derek.ko...@ettus.com>> wrote:


Hello Tom,

The input power to the USRP daughterboard should not be above
-15dBm. I would recommend putting as much attenuation as you have
available inline and raising the gain until just before a timesink
shows the signal clipping, as Andy says having the maximum
attenuation set will be raising your noise figure.

Regards,
Derek


On Wed, Mar 23, 2016 at 4:28 PM, Andy Walls
<a...@silverblocksystems.net <mailto:a...@silverblocksystems.net>>
wrote:


>  From:
    > Tom Golden
>   Subject:
> Re: [Discuss-gnuradio] Ettus N210
> GMSK 9600
>  Date:
> Wed, 23 Mar 2016 13:14:18 -0600
>
>
__
> Here's my flow-graph along with a snapshot of the constellation and
> FFT.
>
>
> Thanks!!
> -Tom

Hi Tom,

A couple of things:

a) The polyphase resampler isn't going to work well without a
filter
definition in the taps field.

b) The constellation sink will not display anything meaningful
without
sample timing synchronization; it is not useful at its current
position
in the flowgraph.  The constellation sink also doesn't display
anything
useful for an FSK modulation normally; (G)MSK being an
exception, if
treating it like a PSK modulation vs. FSK.

c) You don't have any coarse or fine frequency
synchronization.  That
will cause you major problems, if trying to treat GMSK as a PSK
modulation.  It will cause you minor problems, if treating
GMSK as an
FSK modulation.

d) Timing recovery blocks usually want a signal that has peaks
(which
you get by putting the signal through a matched filter), and
those peaks
should nominally be scaled to +/- 1.0.  You don't have a
matched filter
or an AGC before the Clock Recovery block.

e) The USRP's 0 dB gain setting is actually the USRP inserting the
maximum attenuation it can (e.g. 37 dB of attenuation). That
can kill
your signal to noise ratio.  You may want to consider adding
"gain" as
long as the time domain signal doesn't look clipped (sometimes
hard to
tell with FSK).

f) You may wish to look at what Nick Foster's gr-ais does to
demodulate
a 9600 baud GMSK AIS signal.  It will probably give you a nice
starting
point; just ignore the stuff about correlating to a preamble.
https://github.com/bistromath/gr-ais

If you share your datafile somewhere, I might be inspired to
whip a
flowgraph that works on it. :)  But that could rob

Re: [Discuss-gnuradio] Ettus N210 GMSK 9600

[Tom Golden]

Thanks Andy!!  This is great!  The demo data looks good.  Running my data
through it doesn't generate the bits I'm looking for, but I can see the
noise affecting the symbols.  Tomorrow I'll retry with a better signal.

Many many thanks!

Best Regards,
-Tom


On Wed, Mar 23, 2016 at 7:34 PM, Andy Walls <a...@silverblocksystems.net>
wrote:

> On Wed, 2016-03-23 at 18:41 -0600, Tom Golden wrote:
> > Hi Andy,
>
> >
> >
> > Thanks so much for the link!  I'm digging into the gr-ais code - but
> > there's certainly a learning curve there. :)
> >
> >
> > Thanks!!
> > -Tom
>
> Hi Tom,
>
> Here's a GRC that does 9600 baud GMSK demodulation, that I whipped up
> without using your data file.
>
> To run it with the "square and sync" coarse frequency adjustment branch
> in place, you'll need the freqest block from gr-ais, and the attached
> ais_frequest.xml file, since it doesn't exist in gr-ais.  If you know
> you're on freq, you can just disable the blocks in that branch, and
> bypass the multiply that applies the coarse frequency correction.
>
>
> So a fun(?) thing you should notice about this flowgraph's output.  You
> can obviously see the GMSK soft signal before timing recovery is a 4
> level signal, because ISI drags some bits closer to 0 freq deviation.
> But the timing recovery block is outputting 6 levels.  It's getting the
> timing of some of the bits slightly wrong.  That has implications for
> achievable BER for the SNR.
>
> Regards,
> Andy
>
> >
> >
> > On Wed, Mar 23, 2016 at 5:28 PM, Andy Walls
> > <a...@silverblocksystems.net> wrote:
> >
> > >  From:
> > > Tom Golden
> > >   Subject:
> > > Re: [Discuss-gnuradio] Ettus N210
> > > GMSK 9600
> > >  Date:
> > > Wed, 23 Mar 2016 13:14:18 -0600
> > >
> > >
> >
>  __
> > > Here's my flow-graph along with a snapshot of the
> > constellation and
> > > FFT.
> > >
> > >
> > > Thanks!!
> > > -Tom
> >
> > Hi Tom,
> >
> > A couple of things:
> >
> > a) The polyphase resampler isn't going to work well without a
> > filter
> > definition in the taps field.
> >
> > b) The constellation sink will not display anything meaningful
> > without
> > sample timing synchronization; it is not useful at its current
> > position
> > in the flowgraph.  The constellation sink also doesn't display
> > anything
> > useful for an FSK modulation normally; (G)MSK being an
> > exception, if
> > treating it like a PSK modulation vs. FSK.
> >
> > c) You don't have any coarse or fine frequency
> > synchronization.  That
> > will cause you major problems, if trying to treat GMSK as a
> > PSK
> > modulation.  It will cause you minor problems, if treating
> > GMSK as an
> > FSK modulation.
> >
> > d) Timing recovery blocks usually want a signal that has peaks
> > (which
> > you get by putting the signal through a matched filter), and
> > those peaks
> > should nominally be scaled to +/- 1.0.  You don't have a
> > matched filter
> > or an AGC before the Clock Recovery block.
> >
> > e) The USRP's 0 dB gain setting is actually the USRP inserting
> > the
> > maximum attenuation it can (e.g. 37 dB of attenuation).  That
> > can kill
> > your signal to noise ratio.  You may want to consider adding
> > "gain" as
> > long as the time domain signal doesn't look clipped (sometimes
> > hard to
> > tell with FSK).
> >
> > f) You may wish to look at what Nick Foster's gr-ais does to
> > demodulate
> > a 9600 baud GMSK AIS signal.  It will probably give you a nice
> > starting
> > point; just ignore the stuff about correlating to a preamble.
> > https://github.com/bistromath/gr-ais
> >
> > If you share your datafile somewhere, I might be inspired to
> > whip a
> > flowgraph that works on it. :)  But that coul

Re: [Discuss-gnuradio] Ettus N210 GMSK 9600

[Dan CaJacob]

Derek is spot on.  0 dB into any USRP is screaming loud.  Most of the units
are very sensitive, so it's perfectly fine to err on the side of too much
attenuation to start and dial the gain as you need.  It depends on the USRP
type, but signals much above -15dB can physically damage the hardware if
you set the gain too high.

On Wed, Mar 23, 2016 at 9:35 PM Derek Kozel <derek.ko...@ettus.com> wrote:

> Hello Tom,
>
> The input power to the USRP daughterboard should not be above -15dBm. I
> would recommend putting as much attenuation as you have available inline
> and raising the gain until just before a timesink shows the signal
> clipping, as Andy says having the maximum attenuation set will be raising
> your noise figure.
>
> Regards,
> Derek
>
>
> On Wed, Mar 23, 2016 at 4:28 PM, Andy Walls <a...@silverblocksystems.net>
> wrote:
>
>>
>> >  From:
>> > Tom Golden
>> >   Subject:
>> > Re: [Discuss-gnuradio] Ettus N210
>> > GMSK 9600
>> >  Date:
>> > Wed, 23 Mar 2016 13:14:18 -0600
>> >
>> > __
>> > Here's my flow-graph along with a snapshot of the constellation and
>> > FFT.
>> >
>> >
>> > Thanks!!
>> > -Tom
>>
>> Hi Tom,
>>
>> A couple of things:
>>
>> a) The polyphase resampler isn't going to work well without a filter
>> definition in the taps field.
>>
>> b) The constellation sink will not display anything meaningful without
>> sample timing synchronization; it is not useful at its current position
>> in the flowgraph.  The constellation sink also doesn't display anything
>> useful for an FSK modulation normally; (G)MSK being an exception, if
>> treating it like a PSK modulation vs. FSK.
>>
>> c) You don't have any coarse or fine frequency synchronization.  That
>> will cause you major problems, if trying to treat GMSK as a PSK
>> modulation.  It will cause you minor problems, if treating GMSK as an
>> FSK modulation.
>>
>> d) Timing recovery blocks usually want a signal that has peaks (which
>> you get by putting the signal through a matched filter), and those peaks
>> should nominally be scaled to +/- 1.0.  You don't have a matched filter
>> or an AGC before the Clock Recovery block.
>>
>> e) The USRP's 0 dB gain setting is actually the USRP inserting the
>> maximum attenuation it can (e.g. 37 dB of attenuation).  That can kill
>> your signal to noise ratio.  You may want to consider adding "gain" as
>> long as the time domain signal doesn't look clipped (sometimes hard to
>> tell with FSK).
>>
>> f) You may wish to look at what Nick Foster's gr-ais does to demodulate
>> a 9600 baud GMSK AIS signal.  It will probably give you a nice starting
>> point; just ignore the stuff about correlating to a preamble.
>> https://github.com/bistromath/gr-ais
>>
>> If you share your datafile somewhere, I might be inspired to whip a
>> flowgraph that works on it. :)  But that could rob you of the learning
>> process.
>>
>> Regards,
>> Andy
>>
>> >
>> > On Wed, Mar 23, 2016 at 1:01 PM, Marcus D. Leech <address@hidden>
>> > wrote:
>> > On 03/23/2016 02:48 PM, Tom Golden wrote:
>> > Hi,
>> >
>> > I'm a novice gnu radio user.  I'm using gnuradio with
>> > an Ettus N210 cabled to a modem transmitting GMSK
>> > 9600bps.  This is just for a test to verify the modem
>> > transmit bits.
>> >
>> > I'm having issues with resampling.  The N210 clock
>> > can't be set to a multiple of 9600, so I'm attempting
>> > to resample. I've tried various mechanisms but the
>> > output after resampling to 96000 is too noisy to
>> > successfully decode bits.  I've tried the GMSK demod
>> > block as well as the combination of Quadrature
>> > Demod->Clock Recovery MM->Binary Slicer - and neither
>> > works.
>> >
>> > I've also played with the Polyphase clock sync but I
>> > don't see any noticeable difference. Can anyone
>> > recommend a solution?
>> >
>> > Thanks!!
>> > -Tom
>> >
>> > For a first step, it would be useful for you to share your
>> > flow-graph with the list.
>>
>>
>>
>> ___
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
-- 
Very Respectfully,

Dan CaJacob
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Ettus N210 GMSK 9600

[Andy Walls]

On Wed, 2016-03-23 at 18:41 -0600, Tom Golden wrote:
> Hi Andy,

> 
> 
> Thanks so much for the link!  I'm digging into the gr-ais code - but
> there's certainly a learning curve there. :)
> 
> 
> Thanks!!
> -Tom

Hi Tom,

Here's a GRC that does 9600 baud GMSK demodulation, that I whipped up
without using your data file.

To run it with the "square and sync" coarse frequency adjustment branch
in place, you'll need the freqest block from gr-ais, and the attached
ais_frequest.xml file, since it doesn't exist in gr-ais.  If you know
you're on freq, you can just disable the blocks in that branch, and
bypass the multiply that applies the coarse frequency correction.


So a fun(?) thing you should notice about this flowgraph's output.  You
can obviously see the GMSK soft signal before timing recovery is a 4
level signal, because ISI drags some bits closer to 0 freq deviation.
But the timing recovery block is outputting 6 levels.  It's getting the
timing of some of the bits slightly wrong.  That has implications for
achievable BER for the SNR.

Regards,
Andy

> 
> 
> On Wed, Mar 23, 2016 at 5:28 PM, Andy Walls
> <a...@silverblocksystems.net> wrote:
> 
> >  From:
> > Tom Golden
>     >   Subject:
> > Re: [Discuss-gnuradio] Ettus N210
> > GMSK 9600
> >  Date:
> > Wed, 23 Mar 2016 13:14:18 -0600
> >
> >
> __
> > Here's my flow-graph along with a snapshot of the
> constellation and
> > FFT.
> >
> >
> > Thanks!!
> > -Tom
> 
> Hi Tom,
> 
> A couple of things:
> 
> a) The polyphase resampler isn't going to work well without a
> filter
> definition in the taps field.
> 
> b) The constellation sink will not display anything meaningful
> without
> sample timing synchronization; it is not useful at its current
> position
> in the flowgraph.  The constellation sink also doesn't display
> anything
> useful for an FSK modulation normally; (G)MSK being an
> exception, if
> treating it like a PSK modulation vs. FSK.
> 
> c) You don't have any coarse or fine frequency
> synchronization.  That
> will cause you major problems, if trying to treat GMSK as a
> PSK
> modulation.  It will cause you minor problems, if treating
> GMSK as an
> FSK modulation.
> 
> d) Timing recovery blocks usually want a signal that has peaks
> (which
> you get by putting the signal through a matched filter), and
> those peaks
> should nominally be scaled to +/- 1.0.  You don't have a
> matched filter
> or an AGC before the Clock Recovery block.
> 
> e) The USRP's 0 dB gain setting is actually the USRP inserting
> the
> maximum attenuation it can (e.g. 37 dB of attenuation).  That
> can kill
> your signal to noise ratio.  You may want to consider adding
> "gain" as
> long as the time domain signal doesn't look clipped (sometimes
> hard to
> tell with FSK).
> 
> f) You may wish to look at what Nick Foster's gr-ais does to
> demodulate
> a 9600 baud GMSK AIS signal.  It will probably give you a nice
> starting
> point; just ignore the stuff about correlating to a preamble.
> https://github.com/bistromath/gr-ais
> 
> If you share your datafile somewhere, I might be inspired to
> whip a
> flowgraph that works on it. :)  But that could rob you of the
> learning
> process.
> 
> Regards,
> Andy
> 
> >
> > On Wed, Mar 23, 2016 at 1:01 PM, Marcus D. Leech
> <address@hidden>
> > wrote:
> > On 03/23/2016 02:48 PM, Tom Golden wrote:
> > Hi,
> >
> > I'm a novice gnu radio user.  I'm using
> gnuradio with
> > an Ettus N210 cabled to a modem transmitting
> GMSK
> > 9600bps.  This is just for a test to verify
> the modem
> > transmit bits.
> >
> >

Re: [Discuss-gnuradio] Ettus N210 GMSK 9600

[Derek Kozel]

Hello Tom,

The input power to the USRP daughterboard should not be above -15dBm. I
would recommend putting as much attenuation as you have available inline
and raising the gain until just before a timesink shows the signal
clipping, as Andy says having the maximum attenuation set will be raising
your noise figure.

Regards,
Derek


On Wed, Mar 23, 2016 at 4:28 PM, Andy Walls <a...@silverblocksystems.net>
wrote:

>
> >  From:
> > Tom Golden
> >       Subject:
> > Re: [Discuss-gnuradio] Ettus N210
> > GMSK 9600
> >  Date:
> > Wed, 23 Mar 2016 13:14:18 -0600
> >
> > __
> > Here's my flow-graph along with a snapshot of the constellation and
> > FFT.
> >
> >
> > Thanks!!
> > -Tom
>
> Hi Tom,
>
> A couple of things:
>
> a) The polyphase resampler isn't going to work well without a filter
> definition in the taps field.
>
> b) The constellation sink will not display anything meaningful without
> sample timing synchronization; it is not useful at its current position
> in the flowgraph.  The constellation sink also doesn't display anything
> useful for an FSK modulation normally; (G)MSK being an exception, if
> treating it like a PSK modulation vs. FSK.
>
> c) You don't have any coarse or fine frequency synchronization.  That
> will cause you major problems, if trying to treat GMSK as a PSK
> modulation.  It will cause you minor problems, if treating GMSK as an
> FSK modulation.
>
> d) Timing recovery blocks usually want a signal that has peaks (which
> you get by putting the signal through a matched filter), and those peaks
> should nominally be scaled to +/- 1.0.  You don't have a matched filter
> or an AGC before the Clock Recovery block.
>
> e) The USRP's 0 dB gain setting is actually the USRP inserting the
> maximum attenuation it can (e.g. 37 dB of attenuation).  That can kill
> your signal to noise ratio.  You may want to consider adding "gain" as
> long as the time domain signal doesn't look clipped (sometimes hard to
> tell with FSK).
>
> f) You may wish to look at what Nick Foster's gr-ais does to demodulate
> a 9600 baud GMSK AIS signal.  It will probably give you a nice starting
> point; just ignore the stuff about correlating to a preamble.
> https://github.com/bistromath/gr-ais
>
> If you share your datafile somewhere, I might be inspired to whip a
> flowgraph that works on it. :)  But that could rob you of the learning
> process.
>
> Regards,
> Andy
>
> >
> > On Wed, Mar 23, 2016 at 1:01 PM, Marcus D. Leech <address@hidden>
> > wrote:
> > On 03/23/2016 02:48 PM, Tom Golden wrote:
> > Hi,
> >
> > I'm a novice gnu radio user.  I'm using gnuradio with
> > an Ettus N210 cabled to a modem transmitting GMSK
> > 9600bps.  This is just for a test to verify the modem
> > transmit bits.
> >
> > I'm having issues with resampling.  The N210 clock
> > can't be set to a multiple of 9600, so I'm attempting
> > to resample. I've tried various mechanisms but the
> > output after resampling to 96000 is too noisy to
> > successfully decode bits.  I've tried the GMSK demod
> > block as well as the combination of Quadrature
> > Demod->Clock Recovery MM->Binary Slicer - and neither
> > works.
> >
> > I've also played with the Polyphase clock sync but I
> > don't see any noticeable difference. Can anyone
> > recommend a solution?
> >
> > Thanks!!
> > -Tom
> >
> > For a first step, it would be useful for you to share your
> > flow-graph with the list.
>
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Ettus N210 GMSK 9600

[Andy Walls]

>  From: 
> Tom Golden
>   Subject: 
> Re: [Discuss-gnuradio] Ettus N210
> GMSK 9600
>  Date: 
> Wed, 23 Mar 2016 13:14:18 -0600
> 
> __
> Here's my flow-graph along with a snapshot of the constellation and
> FFT.
> 
> 
> Thanks!!
> -Tom

Hi Tom,

A couple of things:

a) The polyphase resampler isn't going to work well without a filter
definition in the taps field.

b) The constellation sink will not display anything meaningful without
sample timing synchronization; it is not useful at its current position
in the flowgraph.  The constellation sink also doesn't display anything
useful for an FSK modulation normally; (G)MSK being an exception, if
treating it like a PSK modulation vs. FSK.

c) You don't have any coarse or fine frequency synchronization.  That
will cause you major problems, if trying to treat GMSK as a PSK
modulation.  It will cause you minor problems, if treating GMSK as an
FSK modulation.

d) Timing recovery blocks usually want a signal that has peaks (which
you get by putting the signal through a matched filter), and those peaks
should nominally be scaled to +/- 1.0.  You don't have a matched filter
or an AGC before the Clock Recovery block.

e) The USRP's 0 dB gain setting is actually the USRP inserting the
maximum attenuation it can (e.g. 37 dB of attenuation).  That can kill
your signal to noise ratio.  You may want to consider adding "gain" as
long as the time domain signal doesn't look clipped (sometimes hard to
tell with FSK).

f) You may wish to look at what Nick Foster's gr-ais does to demodulate
a 9600 baud GMSK AIS signal.  It will probably give you a nice starting
point; just ignore the stuff about correlating to a preamble.
https://github.com/bistromath/gr-ais

If you share your datafile somewhere, I might be inspired to whip a
flowgraph that works on it. :)  But that could rob you of the learning
process.

Regards,
Andy

> 
> On Wed, Mar 23, 2016 at 1:01 PM, Marcus D. Leech <address@hidden>
> wrote:
> On 03/23/2016 02:48 PM, Tom Golden wrote:
> Hi,
> 
> I'm a novice gnu radio user.  I'm using gnuradio with
> an Ettus N210 cabled to a modem transmitting GMSK
> 9600bps.  This is just for a test to verify the modem
> transmit bits.
> 
> I'm having issues with resampling.  The N210 clock
> can't be set to a multiple of 9600, so I'm attempting
> to resample. I've tried various mechanisms but the
> output after resampling to 96000 is too noisy to
> successfully decode bits.  I've tried the GMSK demod
> block as well as the combination of Quadrature
> Demod->Clock Recovery MM->Binary Slicer - and neither
> works.
> 
> I've also played with the Polyphase clock sync but I
> don't see any noticeable difference. Can anyone
> recommend a solution?
> 
> Thanks!!
> -Tom
> 
> For a first step, it would be useful for you to share your
> flow-graph with the list.



___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Ettus N210 GMSK 9600

[Tom Golden]

The modem's output is ~30dBm and I have ~30dB of attenuation.  I figured
that the FFT is showing a lot of power, so the gain wasn't necessary.

Thanks for the idea.  Implementing a LPF in front of the resampler doesn't
seem to make a difference though.




On Wed, Mar 23, 2016 at 1:29 PM, Marcus D. Leech  wrote:

> On 03/23/2016 03:14 PM, Tom Golden wrote:
>
> Here's my flow-graph along with a snapshot of the constellation and FFT.
>
> Thanks!!
> -Tom
>
> What output level is the RF modem producing?  Are you using attenuators
> between it and the RF input of the USRP?
>
> I note that you have the RF gain on your capture set to 0.
>
> Also, I don't recall whether the polyphase resampler requires that the
> input already be Nyquist-limited before it gets resampled.
>   I know some of the other resamplers do that, otherwise, you get aliases
> in your output passband.
>
> Since you're looking at a 9600BPS signal, you should probably have sampled
> this at 250ksps--the lowest rate possible with the N210--
>   that makes filtering later less computationally intensive.
>
>
>
>
> On Wed, Mar 23, 2016 at 1:01 PM, Marcus D. Leech 
> wrote:
>
>> On 03/23/2016 02:48 PM, Tom Golden wrote:
>>
>>> Hi,
>>>
>>> I'm a novice gnu radio user.  I'm using gnuradio with an Ettus N210
>>> cabled to a modem transmitting GMSK 9600bps.  This is just for a test to
>>> verify the modem transmit bits.
>>>
>>> I'm having issues with resampling.  The N210 clock can't be set to a
>>> multiple of 9600, so I'm attempting to resample. I've tried various
>>> mechanisms but the output after resampling to 96000 is too noisy to
>>> successfully decode bits.  I've tried the GMSK demod block as well as the
>>> combination of Quadrature Demod->Clock Recovery MM->Binary Slicer - and
>>> neither works.
>>>
>>> I've also played with the Polyphase clock sync but I don't see any
>>> noticeable difference. Can anyone recommend a solution?
>>>
>>> Thanks!!
>>> -Tom
>>>
>>> For a first step, it would be useful for you to share your flow-graph
>> with the list.
>>
>>
>>
>>
>> ___
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>
>
>
> ___
> Discuss-gnuradio mailing 
> listDiscuss-gnuradio@gnu.orghttps://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Ettus N210 GMSK 9600

[Marcus D. Leech]

On 03/23/2016 03:14 PM, Tom Golden wrote:

Here's my flow-graph along with a snapshot of the constellation and FFT.

Thanks!!
-Tom
What output level is the RF modem producing?  Are you using attenuators 
between it and the RF input of the USRP?


I note that you have the RF gain on your capture set to 0.

Also, I don't recall whether the polyphase resampler requires that the 
input already be Nyquist-limited before it gets resampled.
  I know some of the other resamplers do that, otherwise, you get 
aliases in your output passband.


Since you're looking at a 9600BPS signal, you should probably have 
sampled this at 250ksps--the lowest rate possible with the N210--

  that makes filtering later less computationally intensive.





On Wed, Mar 23, 2016 at 1:01 PM, Marcus D. Leech > wrote:


On 03/23/2016 02:48 PM, Tom Golden wrote:

Hi,

I'm a novice gnu radio user.  I'm using gnuradio with an Ettus
N210 cabled to a modem transmitting GMSK 9600bps.  This is
just for a test to verify the modem transmit bits.

I'm having issues with resampling.  The N210 clock can't be
set to a multiple of 9600, so I'm attempting to resample. I've
tried various mechanisms but the output after resampling to
96000 is too noisy to successfully decode bits.  I've tried
the GMSK demod block as well as the combination of Quadrature
Demod->Clock Recovery MM->Binary Slicer - and neither works.

I've also played with the Polyphase clock sync but I don't see
any noticeable difference. Can anyone recommend a solution?

Thanks!!
-Tom

For a first step, it would be useful for you to share your
flow-graph with the list.




___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org 
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio




___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Ettus N210 GMSK 9600

[Tom Golden]

Here's my flow-graph along with a snapshot of the constellation and FFT.

Thanks!!
-Tom


On Wed, Mar 23, 2016 at 1:01 PM, Marcus D. Leech  wrote:

> On 03/23/2016 02:48 PM, Tom Golden wrote:
>
>> Hi,
>>
>> I'm a novice gnu radio user.  I'm using gnuradio with an Ettus N210
>> cabled to a modem transmitting GMSK 9600bps.  This is just for a test to
>> verify the modem transmit bits.
>>
>> I'm having issues with resampling.  The N210 clock can't be set to a
>> multiple of 9600, so I'm attempting to resample. I've tried various
>> mechanisms but the output after resampling to 96000 is too noisy to
>> successfully decode bits.  I've tried the GMSK demod block as well as the
>> combination of Quadrature Demod->Clock Recovery MM->Binary Slicer - and
>> neither works.
>>
>> I've also played with the Polyphase clock sync but I don't see any
>> noticeable difference. Can anyone recommend a solution?
>>
>> Thanks!!
>> -Tom
>>
>> For a first step, it would be useful for you to share your flow-graph
> with the list.
>
>
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>


test.grc
Description: application/gnuradio-grc
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Ettus N210 GMSK 9600

[Marcus D. Leech]

On 03/23/2016 02:48 PM, Tom Golden wrote:

Hi,

I'm a novice gnu radio user.  I'm using gnuradio with an Ettus N210 
cabled to a modem transmitting GMSK 9600bps.  This is just for a test 
to verify the modem transmit bits.


I'm having issues with resampling.  The N210 clock can't be set to a 
multiple of 9600, so I'm attempting to resample. I've tried various 
mechanisms but the output after resampling to 96000 is too noisy to 
successfully decode bits.  I've tried the GMSK demod block as well as 
the combination of Quadrature Demod->Clock Recovery MM->Binary Slicer 
- and neither works.


I've also played with the Polyphase clock sync but I don't see any 
noticeable difference. Can anyone recommend a solution?


Thanks!!
-Tom

For a first step, it would be useful for you to share your flow-graph 
with the list.





___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Ettus N210 GMSK 9600

[Tom Golden]

Hi,

I'm a novice gnu radio user.  I'm using gnuradio with an Ettus N210 cabled
to a modem transmitting GMSK 9600bps.  This is just for a test to verify
the modem transmit bits.

I'm having issues with resampling.  The N210 clock can't be set to a
multiple of 9600, so I'm attempting to resample.  I've tried various
mechanisms but the output after resampling to 96000 is too noisy to
successfully decode bits.  I've tried the GMSK demod block as well as the
combination of Quadrature Demod->Clock Recovery MM->Binary Slicer - and
neither works.

I've also played with the Polyphase clock sync but I don't see any
noticeable difference. Can anyone recommend a solution?

Thanks!!
-Tom
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio