Re: Communication using Packets

[Barry Duggan]

Hi Evgeny,



Recently I wrote a tutorial on 
https://wiki.gnuradio.org/index.php/Packet_Communications which should give you 
a basic understanding. Be sure to study the Prerequisites first! I did find 
that the examples did not work "out of the box".



Good luck.

---

Barry Duggan KV4FV

https://github.com/duggabe




On  Tue, 2 Nov 2021 18:12:10 +0200, Evgeny Hahamovich wrote:



Hi all, 

 

I am interested to learn how to use the Packet Communications concept, and 

hope to get your advice. I am trying to start with some QPSK or something 

similar, based on the packet_tx & packet_rx examples, but getting lost 

along the way... 

 

Can you maybe guide me to something basic I can use to start? Getting 

totally lost with this :( 

Especially with all the header parameters I should set up... 

 

 

Thank you, 

Evgeny

Re: Demodulating slow phase-modulated data

[Patrick Sathyanathan]

Hi Philip,

Converting real valued signal to I-Q is a simple transformation:


  1.  Pick an LO frequency, F_lo,  greater than 200Hz, the signal bandwidth
  2.  Pick a sample interval, deltaT, smaller than 1/(2*F_lo)
  3.  Generate I-Q digital local oscillator signal: [cos(2*pi*F_lo*i*deltaT), 
j*sin(2*pi*F_lo*i*deltaT] for i depending of the length of your sampling 
interval, i*deltaT
  4.  Multiply each real valued signal value, s, from your WAV file, by each of 
the above LO values to generate the I-O signal

Then use whatever I-Q signal processing you to to process the samples.

Note that there is nothing to be gained by performing the above transformation. 
Unless you have some existing I-Q processing code, you might be better off 
analyzing the real valued signal.

Good luck,

--Patrick


From: Discuss-gnuradio  on 
behalf of Philip Pemberton 
Sent: Wednesday, November 3, 2021 9:28 AM
To: discuss-gnuradio@gnu.org 
Subject: Demodulating slow phase-modulated data

Hi all,

I'm working on a project to reverse-engineer the data format used by an old 
navigation system called Datatrak. I've got a project page on my website about 
it: https://www.philpem.me.uk/datatrak/start

The data is sent by phase-modulating a ~133kHz or ~146kHz (longwave) carrier at 
a very slow rate -- the modulating wave is sinusoidal, either 37.5Hz or 50Hz 
depending on the part of the signal being sent. The signal bandwidth is about 
200Hz.

I've been given some single-channel WAV format recordings from LW SDR 
receivers, 44100Hz sample rate, with a LO frequency of 128kHz. Sadly they're 
not I-Q recordings. I'd like to try and demodulate the signals in these 
recordings to recover the 64 bits of "Goldcode" synchronisation code (from the 
Trigger slot) and the 128 bits of Clock signal (from the Clock slot). I already 
know what the Goldcode value should be.

Can anyone suggest a way I could do this with Gnuradio/GRC or some other tool?

I figure I need to convert the WAV file into a complex (I-Q) signal, mix the 
signal of interest down to baseband, then filter it with a 200Hz bandpass 
filter. I'm not sure what I need to do after that to recover the modulating 
phase signal.

Thanks,
--
Phil.
phil...@philpem.me.uk (preferred)
phil...@gmail.com (alternate)
http://www.philpem.me.uk/

Re: Demodulating slow phase-modulated data

[Daniel Estévez]

El 3/11/21 a las 17:28, Philip Pemberton escribió:

Hi all,

I'm working on a project to reverse-engineer the data format used by an 
old navigation system called Datatrak. I've got a project page on my 
website about it: https://www.philpem.me.uk/datatrak/start 



The data is sent by phase-modulating a ~133kHz or ~146kHz (longwave) 
carrier at a very slow rate -- the modulating wave is sinusoidal, either 
37.5Hz or 50Hz depending on the part of the signal being sent. The 
signal bandwidth is about 200Hz.


I've been given some single-channel WAV format recordings from LW SDR 
receivers, 44100Hz sample rate, with a LO frequency of 128kHz. Sadly 
they're not I-Q recordings. I'd like to try and demodulate the signals 
in these recordings to recover the 64 bits of "Goldcode" synchronisation 
code (from the Trigger slot) and the 128 bits of Clock signal (from the 
Clock slot). I already know what the Goldcode value should be.


Can anyone suggest a way I could do this with Gnuradio/GRC or some other 
tool?


I figure I need to convert the WAV file into a complex (I-Q) signal, mix 
the signal of interest down to baseband, then filter it with a 200Hz 
bandpass filter. I'm not sure what I need to do after that to recover 
the modulating phase signal.


Hi Philip,

Downconverting to baseband and low-pass filtering seems a good start. 
What to do next depends on the specifics of the modulation. I didn't 
understand what you mean by


"
the modulating wave is sinusoidal, either
37.5Hz or 50Hz depending on the part of the signal being sent
"

Do you perhaps mean that the carrier is amplitude or phase modulated 
with an FSK signal that uses tones of 37.5 Hz and 50 Hz to encoded the bits?


I'm not at all sure if that's what you mean, and it doesn't seem a very 
conventional modulation scheme, so perhaps it's something else. I don't 
know anything about Datatrak.


Best,
Daniel.



OpenPGP_signature
Description: OpenPGP digital signature

Demodulating slow phase-modulated data

[Philip Pemberton]

Hi all,

I'm working on a project to reverse-engineer the data format used by an old
navigation system called Datatrak. I've got a project page on my website
about it: https://www.philpem.me.uk/datatrak/start

The data is sent by phase-modulating a ~133kHz or ~146kHz (longwave)
carrier at a very slow rate -- the modulating wave is sinusoidal, either
37.5Hz or 50Hz depending on the part of the signal being sent. The signal
bandwidth is about 200Hz.

I've been given some single-channel WAV format recordings from LW SDR
receivers, 44100Hz sample rate, with a LO frequency of 128kHz. Sadly
they're not I-Q recordings. I'd like to try and demodulate the signals in
these recordings to recover the 64 bits of "Goldcode" synchronisation code
(from the Trigger slot) and the 128 bits of Clock signal (from the Clock
slot). I already know what the Goldcode value should be.

Can anyone suggest a way I could do this with Gnuradio/GRC or some other
tool?

I figure I need to convert the WAV file into a complex (I-Q) signal, mix
the signal of interest down to baseband, then filter it with a 200Hz
bandpass filter. I'm not sure what I need to do after that to recover the
modulating phase signal.

Thanks,
-- 
Phil.
phil...@philpem.me.uk (preferred)
phil...@gmail.com (alternate)
http://www.philpem.me.uk/

Re: ImportError

[Mario Moran]

I see, Thank you for the information. Also, after all this time, it finally
works. Again thank you for all of your help. I was struggling with this for
weeks and now I got it. I have learned a lot from this experience. Have a
great day.

On Wed, Nov 3, 2021 at 1:27 AM Vasil Velichkov 
wrote:

> Hi Mario,
>
> On 02/11/2021 21.17, Mario Moran wrote:
> > It is not working but it is a different error now.
> > Here it is:
> > Traceback (most recent call last):
> >   File "/home/mariom/gr-tutorial/build/top_block.py", line 191, in
> 
> > main()
> >   File "/home/mariom/gr-tutorial/build/top_block.py", line 167, in main
> > tb = top_block_cls()
> >   File "/home/mariom/gr-tutorial/build/top_block.py", line 130, in
> __init__
> > self.digital_chunks_to_symbols_xx_0 =
> > digital.chunks_to_symbols_bc(1+1j, 1-1j, -1+1j, -1-1j, 1)
> > TypeError: make() takes from 1 to 2 positional arguments but 5 were given
> >
> > I have my block, Chunks to Symbols, set up like this:
> > inputtype: byte
> > Output type: complex
> > symbol table: 1+1j, 1-1j, -1+1j, -1-1j
>
> You are missing the square brackets here, it should be: [1+1j, 1-1j,
> -1+1j, -1-1j]
>
> > dimensions: 1
> > num ports 1
> >
> > From the tutorial the flowgraph, Here
> > <
> https://wiki.gnuradio.org/index.php/Guided_Tutorial_GNU_Radio_in_C%2B%2B>,
> > it seems that the imaginary numbers are represented as 'j's instead of
> 'i's
> > so I used 'j's was that correct or may I be missing a factor to make it
> > work?
>
> In Electronics 'i' is used to represent current and hence they use 'j' to
> represent iota. Python adheres to this same convention, see
> https://stackoverflow.com/a/24812657/2315085
>
> Regards,
> Vasil
>

Re: MIMO with LimeSDR

[Evgeny Hahamovich]

Thanks Dave, read your previous post, indeed this is something similar to
what I did.
Eventually I found the problem... I am used to LimeSDR having an automatic
channel selection (L/W/H), and it appears that for channel B, you actually
need to select one on your own :) After doing so, it works well!

Now I just need to figure out what to do with those two parallel streams :)
Saw a nice lecture from the last conference by Matt Ettus:
https://youtu.be/Qx8uFhumgGM?t=26826
Will try to follow that and see how it goes.





On Tue, Nov 2, 2021 at 7:56 PM Dave Miller 
wrote:

> Hi Evgeny,
>
> A few months ago, I had I believe a similar situation with the
> LimeSDR-mini you describe below and show in your attached spectrum plots.
> Although not a MIMO configuration.
>
> For me the solution was to not use the gnu radio in-tree modulation blocks
> in gnuradio version 3.8 with the LimeSDR sink block.  I used my own
> modulator blocks for BPSK and later QPSK with the LimeSDR block.  I sent a
> square wave pulse shape baseband signal to the input of the LimeSDR-mini.
>
> The full discussion and solution for this work-around with flowgraphs and
> spectrum plots is on a Lime Myriad RF site thread in August that I
> established to get some input from the Lime Microsystems folks:
> "LimeSDR-Mini GR-3.8 Block Transmit Distortion"
>
> Regards,
> Dave
>
>
>
>
> -- Forwarded message -
> From: Evgeny Hahamovich
> Date: Thu, Oct 28, 2021 at 11:57 AM
> Subject: MIMO with LimeSDR
> To: 
>
>
> Hi all,
>
> I am interested in checking the MIMO (well, actually it's SIMO for now)
> work mode for my LimeSDR with GNURadio (v.3.8.3.1). Getting into the MIMO
> mode was simple by setting RxChannel = A+B, but I got stuck just after
> this...
>
> In the attached screenshots you can see the spectrum and constellations I
> got for QPSK. As you can see, one of the channels offers terrible
> performance :( Have you encountered something similar? This is strange to
> me, I didn't expect such a major difference between the 2 channels
> performance. Maybe I'm doing something wrong...
>
> Also, can you advise on some blocks I can use for 2 antenas detection to
> improve performance or point me to some documentation or examples for using
> this mode?
>
> Thank you,
> Evgeny
>


-- 
Thank you,
Evgeny Hahamovich

Cell: +972-55-6633583
Biomedical Imaging and Sensing Laboratory

Technion - Israel Institute of Technology

Re: USRP N210 growing latencies

[Fabien PELLET]

Hi Marcus,

How to increase the size on the buffer at the output of the USRP source ?

Improve my flowgraph : maybe possible but I already did some improvment 
? I cascade 3 Xlating FIR filter with growing decimation (5, 10, 25) and 
already try to limitate the number of taps. I have to work with a 
12,5Msps source, make my duties at 10ksps and then output to the sink at 
200Ksps (the lowest value of the USRP). I tried XLating FFT filter but 
it was worst.


Thanks for your help,

Regards,

Fabien, F4CTZ.

Le 31/10/2021 à 13:03, Marcus Müller a écrit :

Hi Fabien,

risking sounding a bit cliché: Well, you need to fix your bug. The underflow 
should not be
happening!

An easy solution, if this is just a manner of occasionally insufficient, but
on-the-medium-term more-than-sufficient processing speed, a larger buffer 
between the USRP
source and the next block, maybe?

Maybe we can otherwise help you improve the performance of your application :) 
Just let us
know!

Best regards,
Marcus

On 30.10.21 00:20, Fabien PELLET wrote:

Hi,

Thanks for the answer.

At the moment, it seems that catching the underflow message and then 
lock/unlock the
flowgraph permits to reset the buffers and is enough for my application to get 
reasonnable
and not growing forever latencies. I don't if someone know a better way like a 
C++ method
that could do that more "elegantly".

If I need more predictible latencies in the futur, indeed, I will try to use 
tags as you
suggest.

Regards,

Fabien, F4CTZ.

Le 27/10/2021 à 17:02, Sylvain Munaut a écrit :

Hi,



OK I understand that. But is there any solution which permits to reset that 
growing
propagation delay ? How to reset the flowgraph buffers without killing the 
application
and restart it ? Is there any method that permits to purge and resync buffers 
of the
flowgraph ?

The USRP supports timestamps for RX and TX.
So you get tags for when data was received / is supposed to be transmitted.
Using a custom block to modify the RX tags into TX tags ( to change
the RX timestamps to TX timestamps a bit into the future ), you should
be able to achieve a constant controlled latency.

Cheers,

  Sylvain

Too many data packets cause the number of sent and received to be different?

[????????]

HI,

Recently I am conducting some ofdm experiments, using the example 
ofdm_tx/rx.grc and two USRPB210s, but I found that when the number of data 
packets I send is small (about ten or less), I can receive at the receiving end 
To the same number of packets. But when I increase the number of sent packets 
to about a few hundred, the number of received packets will be less than the 
number of sent packets, but occasionally their numbers will be equal. At first 
I thought it was caused by the too short sending and receiving time, but when I 
increased the sending and receiving time, occasionally the number of the two 
could be the same. Most of the time it was different. I didn??t know what 
caused this. What is the cause of the phenomenon? Is it a USRP sampling 
problem? How should I ensure that the number of data packets sent is the same 
as the number of received data packets each time? Is it really because of the 
time of sending and receiving? 

Sincerely

rx.pdf
Description: Binary data


tx.pdf
Description: Binary data

Re: ImportError

[Vasil Velichkov]

Hi Mario,

On 02/11/2021 21.17, Mario Moran wrote:
> It is not working but it is a different error now.
> Here it is:
> Traceback (most recent call last):
>   File "/home/mariom/gr-tutorial/build/top_block.py", line 191, in 
> main()
>   File "/home/mariom/gr-tutorial/build/top_block.py", line 167, in main
> tb = top_block_cls()
>   File "/home/mariom/gr-tutorial/build/top_block.py", line 130, in __init__
> self.digital_chunks_to_symbols_xx_0 =
> digital.chunks_to_symbols_bc(1+1j, 1-1j, -1+1j, -1-1j, 1)
> TypeError: make() takes from 1 to 2 positional arguments but 5 were given
> 
> I have my block, Chunks to Symbols, set up like this:
> inputtype: byte
> Output type: complex
> symbol table: 1+1j, 1-1j, -1+1j, -1-1j

You are missing the square brackets here, it should be: [1+1j, 1-1j, -1+1j, 
-1-1j]

> dimensions: 1
> num ports 1
> 
> From the tutorial the flowgraph, Here
> ,
> it seems that the imaginary numbers are represented as 'j's instead of 'i's
> so I used 'j's was that correct or may I be missing a factor to make it
> work?

In Electronics 'i' is used to represent current and hence they use 'j' to 
represent iota. Python adheres to this same convention, see 
https://stackoverflow.com/a/24812657/2315085

Regards,
Vasil