Re: Pail of Milky Way Horn Radio Telescope

[Gisle Vanem]

Glen Langston wrote:


Comments and improvements welcomed.

Data are all obtained using Gnuradio designs available from the DSPIRA web site.
https://github.com/WVURAIL/gr-radio_astro


Tried building it on Win-10 using MSVC/clang-cl.
But it fails on the use of 'clock_gettime()', 'CLOCK_REALTIME' etc.

--
--gv

Channel State Information of OFDM in gnuradio

[Hamed Al-Zubi]

Dears, 

I am doing some analysis on channel state information of OFDM signals. I used 
GNURadion rx_ofdm.grc (gnuradio/gr-digital/examples/ofdm at main · 
gnuradio/gnuradio) for signal transmission and reception through a channel 
model block. Then, the CSI has been extracted using Tag debug block.  
After that, I used matlab to plot the phase of pilot signals from csi. When I 
set the noise voltage on the channel block to zero, the phase of each pilot 
signal is constant. However, when I set the noise voltage to 100m, the phases 
of the pilot signals vary over time as shown in Fig. (phase_pilot). I used a 
moving average filter to mitigate the noise impact on the pilot phase. The 
results were better, but still there is a phase drop as shown in Fig. 
(phase_pilot_filter).
As I read, the phase should be constant as long as the environment is static. 
So, why there is a phase drop? how that can be fixed?

Thanks,HZ

 

| 
| 
| 
|  |  |

 |

 |
| 
|  | 
gnuradio/gr-digital/examples/ofdm at main · gnuradio/gnuradio

GNU Radio – the Free and Open Software Radio Ecosystem - 
gnuradio/gr-digital/examples/ofdm at main · gnuradio/gn...
 |

 |

 |

Re: QAM constellation script

[Marcus Müller]

Hi George,

that's a multiplicative voice scrambler!

The pre-Second World war voice scrambler system "SIGSALY" [1] was kind 
of similar;
just that the scrambling sequence came out of a noisy vacuum tube, not 
Python's random.random(), and that the combination method was taking 
samples and adding them modulo 6, instead of multiplying the phase 
(which is inherently modulo 2π).


So, that should work quite nicely for spreading; it's not as great for 
the secretive purposes the (later) Allies developed the original scramblers:


1. We're re-using the same 10240 length sequence as scrambling signal –
   that's very fine for the spreading, but from a cryptographic point
   of view, if the secrecy of a message depended on an eavesdropper not
   knowing the sequence, not great, because it's easy with a bit of
   statistics to recover an approximative spreading sequence.
2. Since the bandwidth of the scrambled signal is much higher than the
   unscrambled message signal, an envelope detector on the whole
   bandwidth can probably (I didn't try) recover a pretty intelligible
   version of the audio signal (in the end, if the power of the audio
   signal is low, due to the multiplications, so is the power of the
   signal you transmit; it's kind of similar to AM, but instead of
   modulating a carrier, we modulate a white noise source). Of course,
   knowing the spreading sequence (i.e., knowing how to seed
   random.seed()) gives a large processing gain and thus much better
   SNR at the receiver's output than plain power detection.

But you're no trying to send secret messages – you're just trying to use 
a wide band of spectrum, and for that, your solution works fine, if your 
synchronization between transmitter and receiver is good enough in time 
and frequency.


There's a bit of a hurdle there: No two oscillators are /exactly/ the 
same, and there's also things like Doppler – so you need to use your 
preamble (fh==False case) to not only know at which time you need to 
start your random multiplication, but also to know by how many Hertz 
your receiver is tuned off the "correct" frequency. If your receiver 
doesn't have the exact same frequency as the transmitter, you see that 
by a frequency shift in the baseband, so a multiplication with an exp(2j 
· π · f_error · t), and that means that the phase of every sample gets 
shifted by an additional f_error/f_sample more, and the receiver might 
no longer work. To combat that, you need frequency recovery (which could 
very nicely be done on a preamble, it's just not inherently trivial to 
do it with a chirp), and because your receiver's oscillator might still 
drift over time, maybe adding a pilot tone every so and so many seconds 
might help.


In practice, what you'd probably do is take your idea and change a few 
things about it. I'll illustrate the design process with sensible 
example values below. Sensible in the sense that all the things are 
available technologies in the open source space, and not too hard to get 
to work on normal hardware:


It seems you're directly modulating analog audio. Instead, since ca the 
1980s, you'd usually use a voice encoder / decoder pair (i.e., a 
vocoder) to transform the voice into bits, then add error correction to 
them, then spread these – that's a lot easier, and you get the chance to 
use the energy you transmit for the bandwidth the "useful" information 
in your voice actually has, and the energy necessary to make it have the 
least error in the presence of noise, instead of having to transport the 
full audio bandwidth! Then, you could design a system to use the simple 
Direct-Sequence Spread Spectrum (DSSS) method.


DSSS is rather easy: you take a transmit symbol, and repeat it by a 
spreading factor F, and then flip the sign of the symbols ("chips") 
according to a fixed pseudorandom bit sequence that receiver and 
transmitter both share. You send the signal with the full sample rate, 
meaning that you increase the bandwidth by F (that's the spreading). At 
the receiver, you flip in the same manner, "unflipping" the original 
flips, so you just get the noisy original repeated symbols. You add up F 
of them, which gives you F times the amplitude of the original signal.
Because you scale the signal amplitude by F, you get F² times the signal 
power. Noise is uncorrelated to itself, so the amplitudes don't add up 
linearly – the noise variance and hence the power does. So, noise power 
increases  with F, signal power with F², so SNR increases with F.


1. your audio bitstream has a bit rate b. You typically find that by
   listening to a few examples of audio encoders until one has the
   quality you need and nice low bitrate.
   /Example:/ b = 2.4 kb/s (model assumption: voice codec at 2.4 kb/s
   (e.g. codec2[6], or LPCnet)
2. your transmission allows for a certain number of bit errors until it
   gets ugly, so you define a maximum acceptable Bit-Error Rate (BER)
   /Example/: e = 10⁻⁵
3. you choose a class of 

Re: Channel State Information of OFDM in gnuradio

[Marcus Müller]

Hi Hamed,

so, estimating anything from noise will be noisy if the estimation has 
something to do with the estimated entity. (Compare, especially, the 
Cramér-Rao Lower Bound: you can't bias-free estimate with zero error in 
a noisy reception.) So, is it right if I assume that you measured or 
calculated the SNR at your receiver (don't know from the top of my head 
what SNR a noise stddev of 0.1 translates to, and the estimator variance 
is unreasonably high in that scenario?


Best regards,
Marcus

On 5/3/23 16:01, Hamed Al-Zubi wrote:

Dears,

I am doing some analysis on channel state information of OFDM signals.
I used GNURadion rx_ofdm.grc (gnuradio/gr-digital/examples/ofdm at 
main · gnuradio/gnuradio 
) 
for signal transmission and reception through a channel model block. 
Then, the CSI has been extracted using Tag debug block.
After that, I used matlab to plot the phase of pilot signals from csi. 
When I set the noise voltage on the channel block to zero, the phase 
of each pilot signal is constant. However, when I set the noise 
voltage to 100m, the phases of the pilot signals vary over time as 
shown in Fig. (phase_pilot). I used a moving average filter to 
mitigate the noise impact on the pilot phase. The results were better, 
but still there is a phase drop as shown in Fig. (phase_pilot_filter).
As I read, the phase should be constant as long as the environment is 
static. So, why there is a phase drop? how that can be fixed?


Thanks,
HZ








gnuradio/gr-digital/examples/ofdm at main · gnuradio/gnuradio

GNU Radio – the Free and Open Software Radio Ecosystem - 
gnuradio/gr-digital/examples/ofdm at main · gnuradio/gn...

Getting GPS data into stream

[Fabian Schwartau]

Hi everyone,

I am trying to record some data from an SDR and would like to sync/tag 
the data with the current gps position from gpsd. I am kind of stuck and 
don't know how a possible solution for that might look like in grc.
I have a python function that gets the current position as a tuple, but 
how do I get this into my data stream, which I would like to write to a 
CSV file or similar?
I am not asking for a solution of my problem, just point me in the right 
direction ;)


Best,
Fabian

Re: Getting GPS data into stream

[Marcus Müller]

Hi Fabian,

I'd write a block that copies a stream in- to output. It might query 
gpsd every time the work() function is called, or have a FIFO into which 
data from gspd is being pushed by a separate thread (or by reading from  
a socket or however gspd works, I must admit I'm not sure).


You then take that info, and encode the long, lat, uncertainty as 
(double, double, double) PMT tuple. You then use add_item_tag to add 
that PMT to the first sample in your output buffer.


You'd feed the result into a metadata file sink block: That saves things 
in a serialized format ready for retrieval.


Best,
Marcus

On 5/3/23 19:52, Fabian Schwartau wrote:

Hi everyone,

I am trying to record some data from an SDR and would like to sync/tag 
the data with the current gps position from gpsd. I am kind of stuck 
and don't know how a possible solution for that might look like in grc.
I have a python function that gets the current position as a tuple, 
but how do I get this into my data stream, which I would like to write 
to a CSV file or similar?
I am not asking for a solution of my problem, just point me in the 
right direction ;)


Best,
Fabian

Re: Getting GPS data into stream

[Fabian Schwartau]

Hi Marcus,

wow, a lot to read... I am about to do this all manually without gnuradio ;)
Thanks a lot,
Fabian

Am 03.05.23 um 20:04 schrieb Marcus Müller:

Hi Fabian,

I'd write a block that copies a stream in- to output. It might query 
gpsd every time the work() function is called, or have a FIFO into which 
data from gspd is being pushed by a separate thread (or by reading from 
a socket or however gspd works, I must admit I'm not sure).


You then take that info, and encode the long, lat, uncertainty as 
(double, double, double) PMT tuple. You then use add_item_tag to add 
that PMT to the first sample in your output buffer.


You'd feed the result into a metadata file sink block: That saves things 
in a serialized format ready for retrieval.


Best,
Marcus

On 5/3/23 19:52, Fabian Schwartau wrote:

Hi everyone,

I am trying to record some data from an SDR and would like to sync/tag 
the data with the current gps position from gpsd. I am kind of stuck 
and don't know how a possible solution for that might look like in grc.
I have a python function that gets the current position as a tuple, 
but how do I get this into my data stream, which I would like to write 
to a CSV file or similar?
I am not asking for a solution of my problem, just point me in the 
right direction ;)


Best,
Fabian

Re: Getting GPS data into stream

[Marcus D. Leech]

On 03/05/2023 14:04, Marcus Müller wrote:

Hi Fabian,

I'd write a block that copies a stream in- to output. It might query 
gpsd every time the work() function is called, or have a FIFO into 
which data from gspd is being pushed by a separate thread (or by 
reading from  a socket or however gspd works, I must admit I'm not sure).


You then take that info, and encode the long, lat, uncertainty as 
(double, double, double) PMT tuple. You then use add_item_tag to add 
that PMT to the first sample in your output buffer.


You'd feed the result into a metadata file sink block: That saves 
things in a serialized format ready for retrieval.


Best,
Marcus

On 5/3/23 19:52, Fabian Schwartau wrote:

Hi everyone,

I am trying to record some data from an SDR and would like to 
sync/tag the data with the current gps position from gpsd. I am kind 
of stuck and don't know how a possible solution for that might look 
like in grc.
I have a python function that gets the current position as a tuple, 
but how do I get this into my data stream, which I would like to 
write to a CSV file or similar?
I am not asking for a solution of my problem, just point me in the 
right direction ;)


Best,
Fabian




Quite apart from the GPSD-specific stuff, it would be useful to have a 
kind of "annotated formatted data" file sink for low-rate
  data (like scientific data, etc) which supports CSV outputs, and has 
some way of ordering any tags that come in with the
  data and formatting them appropriately, but still be reasonably 
"generic"  (in that the block doesn't really *know* anything
  about the tags, and can be told how to format them).  Maybe *in 
addition* you could pass the block a series of methods to

  call at some configurable cadence.

This somewhat overlaps with what SigMF tries to do, but this is 
formatted data, inherently low-rate, with formatted

  annotations.

I nearly always end up doing this in a custom way for my applications, 
but having a generic block would be cool, and not
  hard to do.   Could be entirely in Python, since we're talking "low 
rate" (like perhaps a few per second at most).

Re: Getting GPS data into stream

[Fabian Schwartau]

OK, I think I found an easier way (at least for me), without having to 
write my own module - never done that.
I used the "Tags Strobe" block in combination with the "Python Module" 
for my gps_get_position() function.
Anyway, where can I find a definition of the format of the "Tagged File 
Sink"? I need to read this with antoher program, without gnuradio, but 
in python.


Best,
Fabian

Am 03.05.23 um 20:04 schrieb Marcus Müller:

Hi Fabian,

I'd write a block that copies a stream in- to output. It might query 
gpsd every time the work() function is called, or have a FIFO into which 
data from gspd is being pushed by a separate thread (or by reading from 
a socket or however gspd works, I must admit I'm not sure).


You then take that info, and encode the long, lat, uncertainty as 
(double, double, double) PMT tuple. You then use add_item_tag to add 
that PMT to the first sample in your output buffer.


You'd feed the result into a metadata file sink block: That saves things 
in a serialized format ready for retrieval.


Best,
Marcus

On 5/3/23 19:52, Fabian Schwartau wrote:

Hi everyone,

I am trying to record some data from an SDR and would like to sync/tag 
the data with the current gps position from gpsd. I am kind of stuck 
and don't know how a possible solution for that might look like in grc.
I have a python function that gets the current position as a tuple, 
but how do I get this into my data stream, which I would like to write 
to a CSV file or similar?
I am not asking for a solution of my problem, just point me in the 
right direction ;)


Best,
Fabian

Re: Getting GPS data into stream

[Fabian Schwartau]

Sorry, forget it. Wrong sink...

Am 03.05.23 um 20:52 schrieb Fabian Schwartau:
OK, I think I found an easier way (at least for me), without having to 
write my own module - never done that.
I used the "Tags Strobe" block in combination with the "Python Module" 
for my gps_get_position() function.
Anyway, where can I find a definition of the format of the "Tagged File 
Sink"? I need to read this with antoher program, without gnuradio, but 
in python.


Best,
Fabian

Am 03.05.23 um 20:04 schrieb Marcus Müller:

Hi Fabian,

I'd write a block that copies a stream in- to output. It might query 
gpsd every time the work() function is called, or have a FIFO into 
which data from gspd is being pushed by a separate thread (or by 
reading from a socket or however gspd works, I must admit I'm not sure).


You then take that info, and encode the long, lat, uncertainty as 
(double, double, double) PMT tuple. You then use add_item_tag to add 
that PMT to the first sample in your output buffer.


You'd feed the result into a metadata file sink block: That saves 
things in a serialized format ready for retrieval.


Best,
Marcus

On 5/3/23 19:52, Fabian Schwartau wrote:

Hi everyone,

I am trying to record some data from an SDR and would like to 
sync/tag the data with the current gps position from gpsd. I am kind 
of stuck and don't know how a possible solution for that might look 
like in grc.
I have a python function that gets the current position as a tuple, 
but how do I get this into my data stream, which I would like to 
write to a CSV file or similar?
I am not asking for a solution of my problem, just point me in the 
right direction ;)


Best,
Fabian

Re: Getting GPS data into stream

[Marcus D. Leech]

On 03/05/2023 14:59, Fabian Schwartau wrote:

Sorry, forget it. Wrong sink...

You probably want:

https://wiki.gnuradio.org/index.php/File_Meta_Sink


Am 03.05.23 um 20:52 schrieb Fabian Schwartau:
OK, I think I found an easier way (at least for me), without having 
to write my own module - never done that.
I used the "Tags Strobe" block in combination with the "Python 
Module" for my gps_get_position() function.
Anyway, where can I find a definition of the format of the "Tagged 
File Sink"? I need to read this with antoher program, without 
gnuradio, but in python.


Best,
Fabian

Am 03.05.23 um 20:04 schrieb Marcus Müller:

Hi Fabian,

I'd write a block that copies a stream in- to output. It might query 
gpsd every time the work() function is called, or have a FIFO into 
which data from gspd is being pushed by a separate thread (or by 
reading from a socket or however gspd works, I must admit I'm not 
sure).


You then take that info, and encode the long, lat, uncertainty as 
(double, double, double) PMT tuple. You then use add_item_tag to add 
that PMT to the first sample in your output buffer.


You'd feed the result into a metadata file sink block: That saves 
things in a serialized format ready for retrieval.


Best,
Marcus

On 5/3/23 19:52, Fabian Schwartau wrote:

Hi everyone,

I am trying to record some data from an SDR and would like to 
sync/tag the data with the current gps position from gpsd. I am 
kind of stuck and don't know how a possible solution for that might 
look like in grc.
I have a python function that gets the current position as a tuple, 
but how do I get this into my data stream, which I would like to 
write to a CSV file or similar?
I am not asking for a solution of my problem, just point me in the 
right direction ;)


Best,
Fabian

Re: Getting GPS data into stream

[Fabian Schwartau]

Exactly, and there are some nice examples in the documentation :)
Thanks a lot!

Am 03.05.23 um 21:01 schrieb Marcus D. Leech:

On 03/05/2023 14:59, Fabian Schwartau wrote:

Sorry, forget it. Wrong sink...

You probably want:

https://wiki.gnuradio.org/index.php/File_Meta_Sink


Am 03.05.23 um 20:52 schrieb Fabian Schwartau:
OK, I think I found an easier way (at least for me), without having 
to write my own module - never done that.
I used the "Tags Strobe" block in combination with the "Python 
Module" for my gps_get_position() function.
Anyway, where can I find a definition of the format of the "Tagged 
File Sink"? I need to read this with antoher program, without 
gnuradio, but in python.


Best,
Fabian

Am 03.05.23 um 20:04 schrieb Marcus Müller:

Hi Fabian,

I'd write a block that copies a stream in- to output. It might query 
gpsd every time the work() function is called, or have a FIFO into 
which data from gspd is being pushed by a separate thread (or by 
reading from a socket or however gspd works, I must admit I'm not 
sure).


You then take that info, and encode the long, lat, uncertainty as 
(double, double, double) PMT tuple. You then use add_item_tag to add 
that PMT to the first sample in your output buffer.


You'd feed the result into a metadata file sink block: That saves 
things in a serialized format ready for retrieval.


Best,
Marcus

On 5/3/23 19:52, Fabian Schwartau wrote:

Hi everyone,

I am trying to record some data from an SDR and would like to 
sync/tag the data with the current gps position from gpsd. I am 
kind of stuck and don't know how a possible solution for that might 
look like in grc.
I have a python function that gets the current position as a tuple, 
but how do I get this into my data stream, which I would like to 
write to a CSV file or similar?
I am not asking for a solution of my problem, just point me in the 
right direction ;)


Best,
Fabian

Re: Getting GPS data into stream

[Marcus Müller]

Hey Marcus,
Quite apart from the GPSD-specific stuff, it would be useful to have a kind of "annotated 
formatted data" file sink for low-rate
   data (like scientific data, etc) which supports CSV outputs, and has some way of 
ordering any tags that come in with the
   data and formatting them appropriately, but still be reasonably "generic"  (in that the 
block doesn't really *know* anything
   about the tags, and can be told how to format them).  Maybe *in addition* you could 
pass the block a series of methods to

   call at some configurable cadence.


HDF5, maybe? I think Haystack had something in that direction…



This somewhat overlaps with what SigMF tries to do, but this is formatted data, inherently 
low-rate, with formatted

   annotations.

I nearly always end up doing this in a custom way for my applications, but having a 
generic block would be cool, and not
   hard to do.   Could be entirely in Python, since we're talking "low rate" (like perhaps 
a few per second at most).


Do agree, but really don't like CSV, too underspecified a format, too many ways that comes 
back to bite you (aside from a thousand SDR users writing emails that their PC can't keep 
up with writing a few MS/s of CSV…)


How important is plain-textness in your applications?

Best,
Marcus

Re: Getting GPS data into stream

[Marcus D. Leech]

On 03/05/2023 16:51, Marcus Müller wrote:


Do agree, but really don't like CSV, too underspecified a format, too 
many ways that comes back to bite you (aside from a thousand SDR users 
writing emails that their PC can't keep up with writing a few MS/s of 
CSV…)
I like CSV because you can hand your data files to someone who doesn't 
have a complete suite of astrophysics tools, and they

  can slurp it into Excel and play with it.



How important is plain-textness in your applications?
I (and many others in my community) tend to throw ad-hoc tools at data 
from ad-hoc experiments.  In the past, I used a lot
  of AWK to post-process data, and these days, I use a lot of 
Python.    Text-based formats lend themselves well to this kind
  of processing.  Rates are quite low, typically.  Like logging an 
integrated power spectrum a few times a minute, for example.


There are other observing modes where text-based formats aren't quite so 
obvious--like pulsar observations, where filterbank
  outputs might be recorded at 10s of kHz, and then post-processed with 
any of a number of pulsar tools.


In all of this, part of the "science" is extracted in "real-time" and 
part in post-processing.





Best,
Marcus