Re: Encode and modulate a test message on GNU Radio 3.8

[Rodrigo Ruiz]

Hello, I have been studying about this for a few days.

I've got some questions.

First, I have thought about how I should get it done.

I have doubts about how to convert the raw file to symbols. Any advice?

After getting the raw file into symbols, I thought of multiplying this with
a signal source to get the waveform with my data (Correct me if I am wrong).

But after this, I don't know if I have to filter the signal before sending
it with the LimeSDR or I have to do more things.

Hope you can guide me.

El mié, 14 jul 2021 a las 13:25, Rodrigo Ruiz ()
escribió:

> Okay Marcus, I thought it would appear on the mailing list as well, my bad.
>
> I am starting to understand how my program is supposed to work.
>
> Binary file --> Symbols --> Waveforms
>
> I have no idea on which blocks do this kind of conversions. Still, I don't
> have the theoretical basis to understand this.
>
> I will focus on understanding how this works, and then look for the blocks
> I need.
>
> Best regards,
> Rodrigo
>
> El mié, 14 jul 2021 a las 13:13, Marcus Müller ()
> escribió:
>
>> Hi Rodrigo,
>>
>> please always have the mailing list in CC: (or directly reply to the
>> mailing list), so
>> that the others see you didn't get lost :)
>>
>> On 14.07.21 13:06, Rodrigo Ruiz wrote:
>> > I will try to explain myself a bit better. I want to send a file using
>> the LimeSDR, but
>> > first I need to use a NRZ codification or something similar and
>> modulate it.
>>
>> "Or something similar": yes, you'll need to do something different. NRZ
>> solves zero
>> problems, and doesn't yield a waveform that can sensibly transmitted and
>> then later
>> received on its own. This is a bit like you saying "I want to design a
>> car, with a sturdy
>> shaft where I affix the oxes that draw it":
>> you're mixing technology that only applies to wired communication with
>> those for wireless
>> communication. Sure, your car can have oxes, but these oxes will not be
>> drawing the car,
>> because then it would not be a car. Your car would probably be better
>> without the oxes,
>> and something else instead.
>>
>> > After this, I will configure the LimeSDR Tx block to transmit that file
>> to a certain
>> > frequency.
>>
>> Ah but an SDR doesn't transmit "files", it transmits discrete-time
>> waveform samples. Your
>> GNU Radio flowgraph's job is to transform the data in the file into
>> symbols, these into
>> waveforms, and *then* they can be transmitted.
>>
>> > Then with another LimeSDR, the idea is to do the opposite process to
>> get the
>> > original file.
>>
>> Exactly, so the flow graph at the receiver needs to take the waveform it
>> gets from the
>> limesdr (which has absolutely no idea of what kind of transmission you
>> have), and analyze
>> it such that it sees the symbols that your transmitter put into a
>> waveform, and gets the
>> data bits they corresponded to!
>>
>> > I will keep studying and let you know about my progress.
>>
>> Great!
>> Best regards,
>> Marcus
>>
>

RE: File metadata rx_time scaled 4x

[Chadwick, Andrew]

So, I understand a bit more about what is happening here, although not yet sure 
how to fix the value in the file header - any advice welcome.

The problem seems to arise because I am receiving and then interleaving two 
channels (I'm using a B210). If I receive one channel only, the header rx_time 
is always as expected. But if I receive two channels, the header rx_time 
depends on the USRP sample rate:

At 1 MHz, 2 MHz, 4 MHz: rx_time is 2x the correct value
At 8 MHz (the rate I want to use): rx_time is 4x the correct value
At 16 MHz: rx_time is correct!

I realised I was using the same sample rate value in the File Meta Sink block 
as in the USRP block, and thought this might be my error - i.e. I need to 
either double the sample rate or perhaps set the relative rate to 2, to account 
for the interleaving - but changing either of these does not seem to have an 
effect on rx_time (should it?).

I then also noticed that, when interleaving 2 channels and depending on the 
sample rate, I get an extra couple of messages about setting of clock rates. 
Master clock rate selection is automatic and on setting up the USRP, I always 
start with:

[INFO][B200] Asking for clock rate 16.00 MHz...
[INFO][B200] Actually got clock rate 16.00 MHz.
[INFO][B200] Asking for clock rate 32.00 MHz...
[INFO][B200] Actually got clock rate 32.00 MHz.

I then get some extra debug output of my own, relating to setting of the USRP 
time, then a message about setting the minimum output buffer on block 2 (the 
USRP being block 1) - after which point there is no more setting of USRP 
parameters in my top_block.

But if sample rate is 4 MHz or less, I now get an extra:

[INFO][B200] Asking for clock rate 16.00 MHz...
[INFO][B200] Actually got clock rate 16.00 MHz.

Or if sample rate is 8 MHz:

[INFO][B200] Asking for clock rate 8.00 MHz...
[INFO][B200] Actually got clock rate 8.00 MHz.

And if sample rate is 16 MHz - nothing!

The actual sample rate i.e. amount of data recorded seems fine but the 32->16 
or 32->8 change in clock rate clearly corresponds to my erroneous rx_time, so I 
guess the number of ticks that reaches the File Meta Sink has been scaled 
somehow.

Can anyone clarify why there is some extra negotiation of clock rate going on 
here, and how I should account for it? It does look like the effect is to scale 
rx_time by exactly 2x or 4x, so I could of course account for that in 
post-processing - but I would rather have a correct value in the file header to 
avoid confusion.

Thanks for any suggestions.

Andy


Roke Manor Research Limited, Romsey, Hampshire, SO51 0ZN, United Kingdom.Part 
of the Chemring Group. 
Registered in England & Wales. Registered No: 00267550
http://www.roke.co.uk
___
The information contained in this e-mail and any attachments is proprietary to 
Roke Manor Research Limited and 
must not be passed to any third party without permission. This communication is 
for information only and shall 
not create or change any contractual relationship.

From: Chadwick, Andrew
Sent: 16 July 2021 21:02
To: discuss-gnuradio@gnu.org
Subject: File metadata rx_time scaled 4x

Hello list,

I want to record UTC-timestamped USRP data, and I've created a flowgraph using 
the file meta sink. I set the USRP time via set_time_now (in the final version 
this will become set_time_next_pps) before the file sink is created, and 
reading back immediately using get_time_now returns the same time. The files 
contain all the inline header fields... but the rx_time appears to be 
consistently 4 times the true value!

Example 1:
USRP time set to 1626425142 seconds after epoch -> 07/16/21 08:45:42
get_time_now returns 1626425142 seconds
In the file header 'rx_time' is followed by: 0c 00 00 00 02 0b 00 00 00 01 83 
c5 1c d9 04 ...
0x000183c51cd9 = 6505700569 full secs

Example 2:
USRP time set to 1626439661 seconds after epoch -> 07/16/21 12:47:41
get_time_now returns 1626439661 seconds
File header 'rx_time' is followed by: 0c 00 00 00 02 0b 00 00 00 01 83 c5 ff b5 
04 ...
0x000183c5ffb5 = 6505758645 full secs

Example 3:
USRP time set to 100 seconds exactly
get_time_now returns 100 seconds
File header 'rx_time' is followed by: 0c 00 00 00 02 0b 00 00 00 00 00 00 01 91 
04 ...
0x0191 = 401 full secs

It looks like the fractional seconds part is affected in the same way - 
inserting, say,  a 0.1 sec sleep after setting the USRP time results in 
approximately 0.4 sec additional delay in rx_time.

Can anyone explain this!? All other header values come out as expected. I'm 
using Gnuradio version 3.7.13.5 with UHD 3.15.0.

Thanks,
Andy

Transmission and Reception samples synchronously in GNURadio

[Armin Ghani]

Dear Community

I've been trying to transmit samples while trying to receive RX samples 
at the same frequency which the delay between TX and RX samples suppose 
to be predictable aka fixed value .


In the UHD host code examples there are two example source files where 
one transmits TX samples in specific time in future, the other does this 
in RX side.


I am pretty aware how timing commands works but since I've been 
developing my system in GRC environment, I prefer to do it in GRC.


When I put USRP sink and source blocks in the flowgraph, and try to 
transmit 1ms tone signal every 1 second, the delay which TX samples will 
be in RX samples are fixed during one run but variable randomly when I 
run it for multiple times.


I'm looking for a trick in GRC to synchronize USRP sink and source 
blocks where I'd like to be sure when transmitting TX signals (assuming 
at the same frequency reception), I'll have those samples in the RX 
stream which is delayed equal to end-to-end propagation delay of USRPs.


If you have any tips/tricks to do it in GRC, I'll be more than thankfull.

Regards.
--

Armin Ghani

Research Engineer | Communication Systems Division (CSD)

agh...@cttc.es | +34 93 645 29 08 (2143)

Centre Tecnològic de Telecomunicacions de Catalunya (CTTC)

Av. Carl Friedrich Gauss, 7 - Edifici B4 - PMT

08860 - Castelldefels (Barcelona, Spain)

www.cttc.cat

Error

[Vincenzo Mone]

Please anybody can help me?

When I run a grc file I get this:

 

 

<<< Welcome to GNU Radio Companion 3.8.2.0 >>>

 

Block paths:

/usr/share/gnuradio/grc/blocks

/usr/local/share/gnuradio/grc/blocks

 

Loading: "/media/enzo/B038BD3C38BD0280/GRC/Sat_FalconSat-3_IK8OZV.grc"

>>> Done

 

Generating: '/media/enzo/B038BD3C38BD0280/GRC/Falconsat_3.py'

 

Executing: /usr/bin/python3 -u
/media/enzo/B038BD3C38BD0280/GRC/Falconsat_3.py

 

Warning: failed to XInitThreads()

Warning: Ignoring XDG_SESSION_TYPE=wayland on Gnome. Use
QT_QPA_PLATFORM=wayland to run on Wayland anyway.

 

 

Please how to avoid the warnings

Thanks

 

 

73 de Enzo IK8OZV
EasyLog 5 BetaTester
EasyLog PDA BetaTester
WinBollet BetaTester
D.C.I. CheckPoint Regione Campania
Skype: ik8ozv8520




  *

  **   GSM  +39 328 7110193  **

  * SMS  +39 328 7110193*

  *

 

Location of configuration files when installing to custom prefix

[wan]

Hello,

According to the following wiki page (
https://wiki.gnuradio.org/index.php/Configuration_Files), gr configuration
files should be located in ${prefix}/etc/gnuradio/conf.d. However, after I
set the cmake flag -DCMAKE_INSTALL_PREFIX = ${prefix},   I notice that
-DGR_PREFDIR=/usr/local/etc/gnuradio/conf.d.

Should I manually set -DGR_PREFDIR= ${prefix}/etc/gnuradio/conf.d? If so,
it would be good to update the wiki to let people know to set this flag.

Regards,

Wan

Re: Location of configuration files when installing to custom prefix

[Ron Economos]

Works okay here. What does gnuradio-config-info --prefsdir say?

Ron

On 7/19/21 12:53 PM, wan wrote:

Hello,

According to the following wiki page 
(https://wiki.gnuradio.org/index.php/Configuration_Files 
), gr 
configuration files should be located in 
${prefix}/etc/gnuradio/conf.d. However, after I set the cmake flag 
-DCMAKE_INSTALL_PREFIX = ${prefix},   I notice that 
-DGR_PREFDIR=/usr/local/etc/gnuradio/conf.d.


Should I manually set -DGR_PREFDIR= ${prefix}/etc/gnuradio/conf.d? If 
so, it would be good to update the wiki to let people know to set this 
flag.


Regards,

Wan

Re: Location of configuration files when installing to custom prefix

[Ron Economos]

That's weird. I am not setting -DGR_PREFDIR.

Ron

On 7/19/21 3:46 PM, wan wrote:

Hi Ron,

I didnt change the -DGR_PREFDIR flag, so for me it says

$ gnuradio-config-info  --prefsdir
/usr/local/etc/gnuradio/conf.d

Did you have to change that flag explicitly for your config file to be 
located in the prefix directory?




On Mon, 19 Jul 2021 at 17:22, Ron Economos > wrote:


Works okay here. What does gnuradio-config-info --prefsdir say?

Ron

On 7/19/21 12:53 PM, wan wrote:
> Hello,
>
> According to the following wiki page
> (https://wiki.gnuradio.org/index.php/Configuration_Files

> >), gr
> configuration files should be located in
> ${prefix}/etc/gnuradio/conf.d. However, after I set the cmake flag
> -DCMAKE_INSTALL_PREFIX = ${prefix},   I notice that
> -DGR_PREFDIR=/usr/local/etc/gnuradio/conf.d.
>
> Should I manually set -DGR_PREFDIR=
${prefix}/etc/gnuradio/conf.d? If
> so, it would be good to update the wiki to let people know to
set this
> flag.
>
> Regards,
>
> Wan

Re: Location of configuration files when installing to custom prefix

[wan]

Hi Ron,

I didnt change the -DGR_PREFDIR flag, so for me it says

$ gnuradio-config-info  --prefsdir
/usr/local/etc/gnuradio/conf.d

Did you have to change that flag explicitly for your config file to be
located in the prefix directory?



On Mon, 19 Jul 2021 at 17:22, Ron Economos  wrote:

> Works okay here. What does gnuradio-config-info --prefsdir say?
>
> Ron
>
> On 7/19/21 12:53 PM, wan wrote:
> > Hello,
> >
> > According to the following wiki page
> > (https://wiki.gnuradio.org/index.php/Configuration_Files
> > ), gr
> > configuration files should be located in
> > ${prefix}/etc/gnuradio/conf.d. However, after I set the cmake flag
> > -DCMAKE_INSTALL_PREFIX = ${prefix},   I notice that
> > -DGR_PREFDIR=/usr/local/etc/gnuradio/conf.d.
> >
> > Should I manually set -DGR_PREFDIR= ${prefix}/etc/gnuradio/conf.d? If
> > so, it would be good to update the wiki to let people know to set this
> > flag.
> >
> > Regards,
> >
> > Wan
>
>

Re: Location of configuration files when installing to custom prefix

[Ron Economos]

Should be set correctly here:

https://github.com/gnuradio/gnuradio/blob/master/CMakeLists.txt#L250

Ron

On 7/19/21 3:52 PM, Ron Economos wrote:


That's weird. I am not setting -DGR_PREFDIR.

Ron

On 7/19/21 3:46 PM, wan wrote:

Hi Ron,

I didnt change the -DGR_PREFDIR flag, so for me it says

$ gnuradio-config-info  --prefsdir
/usr/local/etc/gnuradio/conf.d

Did you have to change that flag explicitly for your config file to 
be located in the prefix directory?




On Mon, 19 Jul 2021 at 17:22, Ron Economos > wrote:


Works okay here. What does gnuradio-config-info --prefsdir say?

Ron

On 7/19/21 12:53 PM, wan wrote:
> Hello,
>
> According to the following wiki page
> (https://wiki.gnuradio.org/index.php/Configuration_Files

> >), gr
> configuration files should be located in
> ${prefix}/etc/gnuradio/conf.d. However, after I set the cmake flag
> -DCMAKE_INSTALL_PREFIX = ${prefix},   I notice that
> -DGR_PREFDIR=/usr/local/etc/gnuradio/conf.d.
>
> Should I manually set -DGR_PREFDIR=
${prefix}/etc/gnuradio/conf.d? If
> so, it would be good to update the wiki to let people know to
set this
> flag.
>
> Regards,
>
> Wan