2-clock problem, Osmocom Source & Freq Offset, ALSA buffer etc

[Da Fy]

Hi All,

Sorry for the longish post. I have a receiver using an RPi4 & an RTL-SDR
dongle that outputs audio via the analogue jack- I'd like a low cost
solution. I need the time delay through the system to be constant & the
2-clock problem means it won't be.

I can make the phase difference between transmitter modulating signal & the
SDR audio output & make it increase or decrease over time by adjusting the
Frequency Offset of the Osmocom source. I'm not sure exactly what this is
doing but seems to tweek the sample clock. Anyone have any info on this?

If there is a way to get access to the ALSA buffer pointers using a Python
OOT block? Then I may be able to work on the average difference to adjust
the Osmocom frequency offset to get a constant phase. It would be
interesting to try but ultimately, I will probably need to hold the delay
more precisely. But, the control loop can be slow as the drift is very slow.

A hardware solution could be to create a clock for the RTL-SDR that's
locked to the RPi clock. Anyone attempted anything like this or have any
comments on the viability. I would assume all clocks on the RPI are
generated from the 19.2MHz crystal; the audio 48kHz is 1/400 of this so I'd
hope it was locked.

Thanks for the help, Dave

Re: Empty file at File Sink for BPSK mod&demod simulation

[Grace Huang]

Hi Jeff,

Thank you for the replies.

Do you mean that the sample rate for RRC taps should be 32 instead of
nfilts? I've set nfilts as a variable with the value of 32.

Regarding the deprecated packet encoder block, I've searched up a bit but
could not find much information on replacing the block. Came across this:
https://dsp.stackexchange.com/questions/56163/gnu-radio-packet-encoder-decoder-unwanted-bytes-added-to-the-transmitted-str
but I downloaded the binary installers for GNURadio on windows and can't
find the example flowgraphs stated. Is there any way to access these flow
graphs or any examples on going about doing the encoding and decoding?

Thank you.
Grace

On Wed, Jun 24, 2020 at 9:19 PM Jeff Long  wrote:

> ... and the packet encoder block has been removed "after long deprecation"
> according to the Changelog.
>
> On Wed, Jun 24, 2020 at 9:10 AM Jeff Long  wrote:
>
>> The RRC taps have a sample rate of 32 and the grc file shows samp_rate
>> set to nfilts.
>>
>> On Wed, Jun 24, 2020 at 6:38 AM Grace Huang 
>> wrote:
>>
>>> Hi all,
>>>
>>> I'm trying to pass a text file through with a simulated channel model
>>> modulated with BPSK. I'm having an issue with not getting any data written
>>> on to the text file at the file sink.
>>>
>>> I passed a txt file in with file source block, followed by packet
>>> encoder then modulate it with BPSK before passing through the channel
>>> model. After that, I used polyphase clock sync, CMA equalizer and costa
>>> loop to minimise frequency, noise and time offset and distortion. Finally I
>>> proceeded to use constellation decoder, differential decoder, unpack K
>>> bits and packet decoder before passing it to file sink.
>>>
>>> The exact flow graph can be found on GitHub here:
>>> https://github.com/wei1006/HAB
>>>
>>> Are there steps that I've missed out or done wrongly?
>>>
>>> Please advise
>>>
>>> Thank you,
>>>
>>> Grace
>>>
>>

Re: GNU Radio web API

[Steven Gillies]

Thanks Kevin,

It's good to know what I am trying to do is possible in practice.

I guess I was hoping for some sort of signal I could send that would be 
received by all of the OOT modules in the flowgraph as I think part of the 
problem is that I have a blocking call to accept a socket connection. It was 
when I tried to change this to a non-blocking call that I realised I didn't 
know how to let the loop know to exit (by setting self.is_running=False). I 
tried setting it in __del__(self) but it seems this is never executed.

In the end through some tinkering I've found that if I start the top_block 
inside multiprocessing.Process and terminate when I'm done then this seems to 
release all of the resources as you describe. Its not as elegant as I would 
have hoped but at least it works for now and I can revisit it if I've time.

For some reason, although it works fine in development, when I deploy it for 
production (inside Docker container) the process will not terminate, and if I 
try to join() then it hangs forever. To solve this I added a timeout and if the 
process is still alive I kill it.

All in all a bit of a hack, but I've got to start somewhere.

Cheers,


Steven

From: Kevin Reid 
Sent: 25 June 2020 04:34
To: Steven Gillies 
Cc: Discuss-gnuradio@gnu.org 
Subject: Re: GNU Radio web API

On Wed, Jun 24, 2020 at 8:04 AM Steven Gillies 
mailto:stevengill...@outlook.com>> wrote:
I am trying to build a web API to start and stop flowgraphs remotely and 
autonomously.

I am having trouble gracefully shutting down one flowgraph and moving on to the 
next.

My preferred way implement the services is by running top_block.start() from my 
main thread and allowing it to start its own thread. To shut it down I then 
call top_block.stop() followed by top_block.wait(). The threads appear to shut 
down gracefully but when I try to run another flowgraph (either the same 
flowgraph again or a different one) I start to get errors.

The two error types I get are either;

  1.  that the second flowgraph cannot find the USRP device because it is being 
held by the first ($ uhd_find_devices also returns 'No Devices Found' until I 
exit the main thread at which point it finds my B210 again), or
  2.  that a socket that the second wants to bind to is in use by the first

In my experience (I wrote ShinySDR, which is 
also a web remote control system), the cause of these problems is that 
references to the old blocks still exist. There is unfortunately no standard 
way to tell a block to free the resources it is using, other than ensuring it 
is "deleted" by dropping all references to it. Therefore, you need to ensure 
that your Python code does not have any variables or attributes referring to 
the old top block or the individual blocks, before you construct the new blocks.

That said, you may want to try the alternative of keeping the UHD, socket, etc. 
blocks around and reusing them, and only changing what they're connected to. 
(That's what ShinySDR currently does, though with different blocks.) Basically, 
use disconnect() as well as connect() to change your flow graph's connectivity 
while it's stopped so that it suits the new purpose. You might encounter some 
misbehavior here too, though; this is not a frequently used and well-tested 
part of GNU Radio's capabilities.

Re: Radar Project - BladeRF2.0

[Dionísio de Carvalho]

Good morning,

Thanks for all the information.

Regards

Dionísio


On Wed, Jun 24, 2020, 15:10 Doug  wrote:

>
>
> On 6/24/2020 9:03 AM, Dionísio de Carvalho wrote:
> > hi everybody
> > This is my fisrt message here. I am pretty new in the SDR world.
> >
> > I am intended to develop a Radar with BladeRF2.0 from Nuand.
> > Is anybody in this boat?
> >
> > I have some start questions that I will be grateful for any help:
> >
> > - How can I sweep the  Frequency at osmocom-sink?  any idea?
> > - How can I figure out the TX power?  I am trying to measure an antenna
> > S21 parameter!
> >
> > thanks for any help
> >
> > Att
> >
> > Dionisio Carvalho
> > Sao Paulo University - Brazil
>
> It is not easy to get a valid measurement of antenna gain or radiated
> power. It is easier to design the antenna according to a published
> formula (i.e., plans) and use the gain figures provided by the
> originator. Be careful to observe whether the gain figure is in
> reference to isotropic or to a dipole. A dipole has 2.1dB greater gain
> than isotropic.
>
> (An isotropic radiator is a theoretical point-source that radiates
> in all directions--all points along a sphere surrounding it.
> Professional antenna engineers use the isotropic source as a
> reference point; radio amateurs tend to use a dipole as their reference
> value.)
>
> Now, measure the power out of your transmitter, with an appropriate
> power meter--a lab meter for power levels up to about 10mW (+10dBm) or
> a Bird or other higher-power meter for levels greater than +10dBm.
> (A lab meter can be used with suitable fixed attenuators of known
> value. Be careful not to overload the lab meter!)
> Then calculate the effective radiated power: RF power from the
> transmitter times the gain of the antenna. Use the same measurement
> units (db, dbm, Watts, numerical gain or dB gain, etc.) to find the
> ERP--effective radiated power.
>
> Values in dB or dBm are ADDED, not multiplied!
>
> --doug, WA2SAY, retired RF engineer
>
>

Re: Osmocom Source (frequency deviation)

[Artur Nogueira]

Yes, you're right: 2000 samples is too much. I made measurements with
different numbers of samples (2, 500 and 2000) because I was afraid a very
slow number (e.g. 2) could cause aliasing in the base-band.
Regarding the offset, it is indeed constant and for experimentation.
I had not realized before this correction field on the Osmocom block - I'll
take a look at it; thanks.
What I'm trying to do is to apply a mixer tuned to the offset frequency
after the Osmocom Source block. The result seems to be ok:

Without the frequency correction:
[image: image.png]

With the frequency correction:
[image: image.png]

Do you think this is reasonable?

Em qua., 24 de jun. de 2020 às 18:32, Jeff Long 
escreveu:

> By the way, 2000 samples per symbol is kind of high. It's usually
> something like 4.
>
> Also, if the frequency offset is constant and this is just for
> experimentation, you can use a frequency translating filter, or possibly
> the frequency correction field on the osmocomm blocks (can't remember if
> it's passed through to the hackrf code).
>
> On Wed, Jun 24, 2020 at 5:21 PM Jeff Long  wrote:
>
>> Depending on the bandwidth of your signal, that could be a lot of offset,
>> and you might need a PLL to do frequency correction. That's 130 ppm, which
>> is a little more than you should see between two HackRFs.
>>
>> On Wed, Jun 24, 2020 at 5:13 PM Artur Nogueira 
>> wrote:
>>
>>> Thanks a lot.
>>> I'll read the block specifications.
>>> And yes, the offset is small (120 kHz).
>>>
>>> Em qua., 24 de jun. de 2020 às 17:53, Jeff Long 
>>> escreveu:
>>>
 Assuming the difference is small enough, this is a normal RX problem
 that a GMSK demod should be able to handle. The labels on your frequency
 plot do not say what the offset is, but hint that it is small. Take a look
 at gmsk.py
 
  to
 see how it's handled in the built-in demod.

 On Wed, Jun 24, 2020 at 4:10 PM Artur Nogueira 
 wrote:

> Hi Jeff,
>
> Thanks for the feedback.
> I'm using GNU Radio Version 3.7.13.5 and two Great Scott Gadgets
> HackRF units for the transmission/reception.
> My workflow looks like this:
>
> [image: image.png]
>
> Do you usually use any artifact to compensate for this frequency shift?
> I'm afraid this could affect demodulation and therefore the BER.
>
> Best regards,
> Artur
>
>
> Em qua., 24 de jun. de 2020 às 16:31, Jeff Long 
> escreveu:
>
>> Artur,
>>
>> You haven't mentioned what software you are using, how you have it
>> configured, or what your flowgraph looks like.
>>
>> If you are using two SDRs and the frequency difference is a few kHz,
>> then that is just oscillator differences.
>>
>> On Wed, Jun 24, 2020 at 3:12 PM Artur Nogueira 
>> wrote:
>>
>>> Hi everyone,
>>>
>>> I'm comparing the spectra of a pair of transmitted/received GMSK
>>> signals (carrier frequency = 923 MHz).
>>> As expected, there is a certain channel attenuation.
>>> Nevertheless, there is this frequency deviation at the Osmocom
>>> Source output:
>>> [image: image.png]
>>>
>>> I suppose this is something related to the receiver hardware.
>>> Do you have a suggestion on how to compensate for this effect at a
>>> software level?
>>>
>>> Best regards,
>>> Artur
>>>
>>>

Re: Osmocom Source (frequency deviation)

[Artur Nogueira]

Just one more comment: there is an additional low-pass filter when I use
the mixer. The goal is to eliminate one of the frequencies resulting from
this process (i.e. 2 x f_offset).

Em qui., 25 de jun. de 2020 às 10:35, Artur Nogueira 
escreveu:

> Yes, you're right: 2000 samples is too much. I made measurements with
> different numbers of samples (2, 500 and 2000) because I was afraid a very
> slow number (e.g. 2) could cause aliasing in the base-band.
> Regarding the offset, it is indeed constant and for experimentation.
> I had not realized before this correction field on the Osmocom block -
> I'll take a look at it; thanks.
> What I'm trying to do is to apply a mixer tuned to the offset frequency
> after the Osmocom Source block. The result seems to be ok:
>
> Without the frequency correction:
> [image: image.png]
>
> With the frequency correction:
> [image: image.png]
>
> Do you think this is reasonable?
>
> Em qua., 24 de jun. de 2020 às 18:32, Jeff Long 
> escreveu:
>
>> By the way, 2000 samples per symbol is kind of high. It's usually
>> something like 4.
>>
>> Also, if the frequency offset is constant and this is just for
>> experimentation, you can use a frequency translating filter, or possibly
>> the frequency correction field on the osmocomm blocks (can't remember if
>> it's passed through to the hackrf code).
>>
>> On Wed, Jun 24, 2020 at 5:21 PM Jeff Long  wrote:
>>
>>> Depending on the bandwidth of your signal, that could be a lot of
>>> offset, and you might need a PLL to do frequency correction. That's 130
>>> ppm, which is a little more than you should see between two HackRFs.
>>>
>>> On Wed, Jun 24, 2020 at 5:13 PM Artur Nogueira 
>>> wrote:
>>>
 Thanks a lot.
 I'll read the block specifications.
 And yes, the offset is small (120 kHz).

 Em qua., 24 de jun. de 2020 às 17:53, Jeff Long 
 escreveu:

> Assuming the difference is small enough, this is a normal RX problem
> that a GMSK demod should be able to handle. The labels on your frequency
> plot do not say what the offset is, but hint that it is small. Take a look
> at gmsk.py
> 
>  to
> see how it's handled in the built-in demod.
>
> On Wed, Jun 24, 2020 at 4:10 PM Artur Nogueira 
> wrote:
>
>> Hi Jeff,
>>
>> Thanks for the feedback.
>> I'm using GNU Radio Version 3.7.13.5 and two Great Scott Gadgets
>> HackRF units for the transmission/reception.
>> My workflow looks like this:
>>
>> [image: image.png]
>>
>> Do you usually use any artifact to compensate for this frequency
>> shift?
>> I'm afraid this could affect demodulation and therefore the BER.
>>
>> Best regards,
>> Artur
>>
>>
>> Em qua., 24 de jun. de 2020 às 16:31, Jeff Long 
>> escreveu:
>>
>>> Artur,
>>>
>>> You haven't mentioned what software you are using, how you have it
>>> configured, or what your flowgraph looks like.
>>>
>>> If you are using two SDRs and the frequency difference is a few kHz,
>>> then that is just oscillator differences.
>>>
>>> On Wed, Jun 24, 2020 at 3:12 PM Artur Nogueira <
>>> artur.no...@gmail.com> wrote:
>>>
 Hi everyone,

 I'm comparing the spectra of a pair of transmitted/received GMSK
 signals (carrier frequency = 923 MHz).
 As expected, there is a certain channel attenuation.
 Nevertheless, there is this frequency deviation at the Osmocom
 Source output:
 [image: image.png]

 I suppose this is something related to the receiver hardware.
 Do you have a suggestion on how to compensate for this effect at a
 software level?

 Best regards,
 Artur

Re: Packet TX and RX on E312

[Cameron Matson]

I moved my setup from e312s to n310s so that I could run the flowgraphs
with the gui blocks to help with debugging.  It looks like the phase is off
at the RX as the constellation gui from the USRP (the one before the Packet
Rx block) is rotating.  I'm able to adjust the magnitude of the IQ data by
playing with the tx and rx gain, but I can't get the phase to lock.

What are some of the knobs I can turn to help the Packet Rx block detect
the signal given the phase offset?

Thanks,
Cameron


On Wed, Jun 24, 2020 at 8:53 AM Cameron Matson  wrote:

> Marcus,
> Thanks for that information, maybe I'll look more into the FPGA.
>
> As for the other problem I agree, it's probably setup.  The radios are
> "connected" via antennae.  Both USRPs have VERT900 antennae to the TRX
> terminals.
>
> I've run other experiments successfully transmitting data from one to the
> other.  For example I've used the (deprecated I know) Packet
> Encoder/Decoder block to send a file from one to the other.  But nothing
> since I started using the Packet TX/RX hier blocks.
>
> Cameron
>
>
> On Tue, Jun 23, 2020, 2:14 PM Marcus D. Leech 
> wrote:
>
>> On 06/23/2020 01:17 PM, Cameron Matson wrote:
>>
>> I've tried from 125K to 16M (which if I request anything higher is what
>> the device seems to cap it at).  The lower sample rates on the RX side
>> actually do solve the O problem, which I guess makes sense, but the tG and
>> U are still there on the TX side, and no packets seem to be decoded.
>>
>> Cameron
>>
>> The CPU on the E310 is a dual-core ARM9 CPU clocked at 866MHz.  That
>> means that it can't move very many samples (particularly full-duplex)
>>   per second for a "complex" signal flow that involves
>> modulaton/demodulation.  When doing pretty-much *nothing* to the samples,
>> the interface
>>   can move a few Msps.  That goes down quickly as you actually have to do
>> anything to the samples.  The E310 has a larger FPGA, and the
>>   "marketted use case" is to do most processing in the FPGA.
>>
>> Now, as to why, at lower rates, you cannot decode, that's a debugging
>> exercise perhaps not related, per se, to the E310, but just
>>   the experimental setup.
>>
>> How are the two radios "connected" -- via antennae or a cable?  If cable,
>> make sure you have plenty of attenuation in-line (30-40dB),
>>   otherwise you risk damage to the receiver at worst, and at best,
>> driving the receive chain into non-linearity, producing distortions and
>>   unwanted mixing products within the first gain stage(s).
>>
>>
>>
>> On Tue, Jun 23, 2020 at 12:03 PM Marcus D Leech 
>> wrote:
>>
>>> What sample rate ranges have you tried?
>>>
>>> Sent from my iPhone
>>>
>>> On Jun 23, 2020, at 12:57 PM, Cameron Matson 
>>> wrote:
>>>
>>> 
>>> Hello all,
>>>
>>> I'm new to gnuradio and SDR so I hope there isn't something obvious I'm
>>> missing.  I'm trying to get a packet based system set up.  I'm using
>>> gnuradio 3.7 and UHD 3.14 that I cross compiled and loaded onto two E312s.
>>>
>>> I'm trying to use the uhd_packet_tx and uhd_packet_rx examples as a
>>> staring point.  I made the necessary modifications to run it as a non-gui
>>> flowgraph, but left all the variables untouched.  Both the flow graphs run,
>>> but:
>>>
>>>- the Tx flow graph shows an initial tG flag and then a  U flag
>>>after every burst (which I understand has something to do with tag 
>>> offsets
>>>mismatching https://github.com/gnuradio/gnuradio/issues/1976)
>>>- The Rx flow graph immediately starts outputing O flags, and no
>>>packets are recieved.
>>>
>>> I've tried playing around with the frequency and sampling rates without
>>> much success.
>>>
>>> Any help on where to start would be greatly appreciated.
>>>
>>> Thanks,
>>> Cameron
>>>
>>>
>>

Re: Windows Binaries for 3.8.1.0 Available

[Marcus Müller]

Hi Geof,

wow, thanks!

Looking forward to your Python3 builds, too! :)

Cheers,
Marcus

On 25/06/2020 00.46, Geof Nieboer wrote:

All,

Windows installers have been updated for GR 3.8.1.0 and are out of 
"beta" status.  This can be installed side-by-side with the 3.7 versions 
(but not other 3.8 versions)


Download it here 
: 



*Expect this to be the final release that will include Python 2.7. *

Issues Fixed:

-    Errant AVX2 instructions removed

The following versions were updated (to include necessary changes in 
build scripts to accommodate upstream changes):


  * GNURadio -> 3.8.1.0
  * volk -> 2.3
  * UHD -> 3.15
  * scipy -> 1.2.2
  * boost -> 1.66.0
  * openssl -> 1.0.2r
  * gqrx -> 2.12.1





smime.p7s
Description: S/MIME Cryptographic Signature

Re: Calculating SNR of an incoming signal

[Marcus Müller]

Hi Alex,

can you make sure to reply to the mailing list, not just me alone? 
Others usually take interest in discussion, too :)


Well, then it's easy.

Total signal power is simply the average magnitude square of your 
received signal
You just need to subtract the power of the tone (that's its squared 
amplitude) and get the noise power.


Divide these two, and you get SNR.

However, since this is the description of a Radar that assumes its 
targets are stationary, you'd probably use a PLL to remove the noise 
bandwidth drastically, so not quite sure that kind of SNR measurement is 
extremely useful for realistic system comparison!


Best regards,
Marcus
On 24/06/2020 16.58, Alex Batts wrote:

Hello,

__ __

The incoming signal is going to be a specific tone, probably around 5.8 
GHz. I am going to be using it for radar range detection. My SDR will 
just passively receive the reflected signal off of the object and use 
the SNR in the range calculation.


__ __

Thank you,

__ __

Alex

__ __





smime.p7s
Description: S/MIME Cryptographic Signature

Re: Empty file at File Sink for BPSK mod&demod simulation

[Marcus Müller]

You're trying to run a flow graph designed for a different version of 
GNU Radio.

Use the examples that came with your version of GNU Radio.

Better still: update to a current GNU Radio (3.8.1.0) and run the 
examples from that.


On 25/06/2020 13.06, Grace Huang wrote:

Hi,

I managed to get the gnuradio example flowgraphs. However I'm getting 
the following parser error when opening it: Start tag expected, '<' not 
found


A snipshot of the error is attached.

May I know if there is any way to solve this issue?

Thank you,
Grace

On Thu, Jun 25, 2020 at 6:42 PM Grace Huang > wrote:


Hi Jeff,

Thank you for the replies.

Do you mean that the sample rate for RRC taps should be 32 instead
of nfilts? I've set nfilts as a variable with the value of 32.

Regarding the deprecated packet encoder block, I've searched up a
bit but could not find much information on replacing the block. Came
across this:

https://dsp.stackexchange.com/questions/56163/gnu-radio-packet-encoder-decoder-unwanted-bytes-added-to-the-transmitted-str
but I downloaded the binary installers for GNURadio on windows and
can't find the example flowgraphs stated. Is there any way to access
these flow graphs or any examples on going about doing the encoding
and decoding?

Thank you.
Grace

On Wed, Jun 24, 2020 at 9:19 PM Jeff Long mailto:willco...@gmail.com>> wrote:

... and the packet encoder block has been removed "after long
deprecation" according to the Changelog.

On Wed, Jun 24, 2020 at 9:10 AM Jeff Long mailto:willco...@gmail.com>> wrote:

The RRC taps have a sample rate of 32 and the grc file shows
samp_rate set to nfilts.

On Wed, Jun 24, 2020 at 6:38 AM Grace Huang
mailto:gracehuang1...@gmail.com>>
wrote:

Hi all,

I'm trying to pass a text file through with a simulated
channel model modulated with BPSK. I'm having an issue
with not getting any data written on to the text file at
the file sink.

I passed a txt file in with file source block, followed
by packet encoder then modulate it with BPSK before
passing through the channel model. After that, I used
polyphase clock sync, CMA equalizer and costa loop to
minimise frequency, noise and time offset and
distortion. Finally I proceeded to use constellation
decoder, differential decoder, unpack K bits and packet
decoder before passing it to file sink.

The exact flow graph can be found on GitHub here:
https://github.com/wei1006/HAB

Are there steps that I've missed out or done wrongly?

Please advise

Thank you,

Grace





smime.p7s
Description: S/MIME Cryptographic Signature

Re: GNU Radio web API

[Marcus Müller]

Hi Kevin,

you're kind of right:

On 25/06/2020 05.34, Kevin Reid wrote:
There is unfortunately 
no standard way to tell a block to free the resources it is using, other 
than ensuring it is "deleted" by dropping all references to it. 


Well, technically, when a flow graph is finished running, the stop() 
methods are called for that very reason. But then you can't reconnect.


We never thought about the proper semantics for that function. IMHO, we 
would have needed a "prepare for reconfiguration" state. And, we would 
have needed an explicitly defined state machine to begin with to not end 
up in a million different states...


Therefore, you need to ensure that your Python code does not have any 
variables or attributes referring to the old top block or the individual 
blocks, before you construct the new blocks.


Even then, Python garbage collection is non-deterministic, I think .

That said, you may want to try the alternative of keeping the UHD, 
socket, etc. blocks around and reusing them, and only changing what 
they're connected to. (That's what ShinySDR currently does, though with 
different blocks.) Basically, use disconnect() as well as connect() to 
change your flow graph's connectivity while it's stopped so that it 
suits the new purpose. You might encounter some misbehavior here too, 
though; this is not a frequently used and well-tested part of GNU 
Radio's capabilities.


Absolutely true, sadly.
Fun fact, there's now multiple research institutions spending 
braingrease on this, hopefully we'll find a solution to this whole 
problem soon.


Best regards,
Marcus



smime.p7s
Description: S/MIME Cryptographic Signature

Re: GNU Radio web API

[Marcus Müller]

Such a thing exists: all blocks have a "system" message port!

On 25/06/2020 13.40, Steven Gillies wrote:

Thanks Kevin,

It's good to know what I am trying to do is possible in practice.

I guess I was hoping for some sort of signal I could send that would be 
received by all of the OOT modules in the flowgraph as I think part of 
the problem is that I have a blocking call to accept a socket 
connection. It was when I tried to change this to a non-blocking call 
that I realised I didn't know how to let the loop know to exit (by 
setting self.is_running=False). I tried setting it in __del__(self) but 
it seems this is never executed.


In the end through some tinkering I've found that if I start the 
top_block inside multiprocessing.Process and terminate when I'm done 
then this seems to release all of the resources as you describe. Its not 
as elegant as I would have hoped but at least it works for now and I can 
revisit it if I've time.


For some reason, although it works fine in development, when I deploy it 
for production (inside Docker container) the process will not terminate, 
and if I try to join() then it hangs forever. To solve this I added a 
timeout and if the process is still alive I kill it.


All in all a bit of a hack, but I've got to start somewhere.

Cheers,


Steven

*From:* Kevin Reid 
*Sent:* 25 June 2020 04:34
*To:* Steven Gillies 
*Cc:* Discuss-gnuradio@gnu.org 
*Subject:* Re: GNU Radio web API
On Wed, Jun 24, 2020 at 8:04 AM Steven Gillies 
mailto:stevengill...@outlook.com>> wrote:


I am trying to build a web API to start and stop flowgraphs remotely
and autonomously.

I am having trouble gracefully shutting down one flowgraph and
moving on to the next.

My preferred way implement the services is by running
top_block.start() from my main thread and allowing it to start its
own thread. To shut it down I then call top_block.stop() followed by
top_block.wait(). The threads appear to shut down gracefully but
when I try to run another flowgraph (either the same flowgraph again
or a different one) I start to get errors.

The two error types I get are either;

 1. that the second flowgraph cannot find the USRP device because it
is being held by the first ($ uhd_find_devices also returns 'No
Devices Found' until I exit the main thread at which point it
finds my B210 again), or
 2. that a socket that the second wants to bind to is in use by the
first

In my experience (I wrote ShinySDR , 
which is also a web remote control system), the cause of these problems 
is that references to the old blocks still exist. There is unfortunately 
no standard way to tell a block to free the resources it is using, other 
than ensuring it is "deleted" by dropping all references to it. 
Therefore, you need to ensure that your Python code does not have any 
variables or attributes referring to the old top block or the individual 
blocks, before you construct the new blocks.


That said, you may want to try the alternative of keeping the UHD, 
socket, etc. blocks around and reusing them, and only changing what 
they're connected to. (That's what ShinySDR currently does, though with 
different blocks.) Basically, use disconnect() as well as connect() to 
change your flow graph's connectivity while it's stopped so that it 
suits the new purpose. You might encounter some misbehavior here too, 
though; this is not a frequently used and well-tested part of GNU 
Radio's capabilities.




smime.p7s
Description: S/MIME Cryptographic Signature

Re: Calculating SNR of an incoming signal

[Alex Batts]

Sorry, I'm new to the mailing list as well.

How would you recommend isolating the tone power? A band pass filter
wouldn't work at that frequency since there isn't an SDR that can sample
that high. Would that be where the Phase Locked Loop comes into play?

Thank you for your help to this point,

Alex

On Thu, Jun 25, 2020 at 1:41 PM Marcus Müller  wrote:

> Hi Alex,
>
> can you make sure to reply to the mailing list, not just me alone?
> Others usually take interest in discussion, too :)
>
> Well, then it's easy.
>
> Total signal power is simply the average magnitude square of your
> received signal
> You just need to subtract the power of the tone (that's its squared
> amplitude) and get the noise power.
>
> Divide these two, and you get SNR.
>
> However, since this is the description of a Radar that assumes its
> targets are stationary, you'd probably use a PLL to remove the noise
> bandwidth drastically, so not quite sure that kind of SNR measurement is
> extremely useful for realistic system comparison!
>
> Best regards,
> Marcus
> On 24/06/2020 16.58, Alex Batts wrote:
> > Hello,
> >
> > __ __
> >
> > The incoming signal is going to be a specific tone, probably around 5.8
> > GHz. I am going to be using it for radar range detection. My SDR will
> > just passively receive the reflected signal off of the object and use
> > the SNR in the range calculation.
> >
> > __ __
> >
> > Thank you,
> >
> > __ __
> >
> > Alex
> >
> > __ __
> >
>
>

Re: Calculating SNR of an incoming signal

[Marcus Müller]

But you're sampling something, or else you couldn't process this in GNU 
Radio. So, I'm a bit confused about what you're actually doing.



On 25/06/2020 20.48, Alex Batts wrote:

Sorry, I'm new to the mailing list as well.

How would you recommend isolating the tone power? A band pass filter 
wouldn't work at that frequency since there isn't an SDR that can sample 
that high. Would that be where the Phase Locked Loop comes into play?


Thank you for your help to this point,

Alex

On Thu, Jun 25, 2020 at 1:41 PM Marcus Müller > wrote:


Hi Alex,

can you make sure to reply to the mailing list, not just me alone?
Others usually take interest in discussion, too :)

Well, then it's easy.

Total signal power is simply the average magnitude square of your
received signal
You just need to subtract the power of the tone (that's its squared
amplitude) and get the noise power.

Divide these two, and you get SNR.

However, since this is the description of a Radar that assumes its
targets are stationary, you'd probably use a PLL to remove the noise
bandwidth drastically, so not quite sure that kind of SNR
measurement is
extremely useful for realistic system comparison!

Best regards,
Marcus
On 24/06/2020 16.58, Alex Batts wrote:
 > Hello,
 >
 > __ __
 >
 > The incoming signal is going to be a specific tone, probably
around 5.8
 > GHz. I am going to be using it for radar range detection. My SDR
will
 > just passively receive the reflected signal off of the object and
use
 > the SNR in the range calculation.
 >
 > __ __
 >
 > Thank you,
 >
 > __ __
 >
 > Alex
 >
 > __ __
 >





smime.p7s
Description: S/MIME Cryptographic Signature

Re: Calculating SNR of an incoming signal

[Alex Batts]

I'm sampling an incoming signal, but only around 2 MSps.

I need the signal power to noise power ratio at the receiver as part of my
range calculation. So I would need to be able to distinguish between the
power of the tone vs the power of the surrounding noise and use those two
numerical values in an equation to calculate the range. This is why I
referenced the green and red lines on the qt gui freq. display, this would
seem to give me signal strength in dB.

On Thu, Jun 25, 2020 at 2:51 PM Marcus Müller  wrote:

> But you're sampling something, or else you couldn't process this in GNU
> Radio. So, I'm a bit confused about what you're actually doing.
>
>
> On 25/06/2020 20.48, Alex Batts wrote:
> > Sorry, I'm new to the mailing list as well.
> >
> > How would you recommend isolating the tone power? A band pass filter
> > wouldn't work at that frequency since there isn't an SDR that can sample
> > that high. Would that be where the Phase Locked Loop comes into play?
> >
> > Thank you for your help to this point,
> >
> > Alex
> >
> > On Thu, Jun 25, 2020 at 1:41 PM Marcus Müller  > > wrote:
> >
> > Hi Alex,
> >
> > can you make sure to reply to the mailing list, not just me alone?
> > Others usually take interest in discussion, too :)
> >
> > Well, then it's easy.
> >
> > Total signal power is simply the average magnitude square of your
> > received signal
> > You just need to subtract the power of the tone (that's its squared
> > amplitude) and get the noise power.
> >
> > Divide these two, and you get SNR.
> >
> > However, since this is the description of a Radar that assumes its
> > targets are stationary, you'd probably use a PLL to remove the noise
> > bandwidth drastically, so not quite sure that kind of SNR
> > measurement is
> > extremely useful for realistic system comparison!
> >
> > Best regards,
> > Marcus
> > On 24/06/2020 16.58, Alex Batts wrote:
> >  > Hello,
> >  >
> >  > __ __
> >  >
> >  > The incoming signal is going to be a specific tone, probably
> > around 5.8
> >  > GHz. I am going to be using it for radar range detection. My SDR
> > will
> >  > just passively receive the reflected signal off of the object and
> > use
> >  > the SNR in the range calculation.
> >  >
> >  > __ __
> >  >
> >  > Thank you,
> >  >
> >  > __ __
> >  >
> >  > Alex
> >  >
> >  > __ __
> >  >
> >
>
>

Re: Calculating SNR of an incoming signal

[Marcus Müller]

Hi Alex,

On 25/06/2020 21.00, Alex Batts wrote:

I'm sampling an incoming signal, but only around 2 MSps.



and that's fine! that's the *equivalent* baseband, it has all the same 
information as the RF signal.


I need the signal power to noise power ratio at the receiver as part of 
my range calculation. 


Yes, but you'd always want to do that "signal to noise" only in the 
bandwidth that actually contains your tone; the rest will just contain 
more noise, interferers... to make your measurement worse.


So I would need to be able to distinguish between 
the power of the tone vs the power of the surrounding noise and use 
those two numerical values in an equation to calculate the range. 


You need to define "surrounding"! Your signal doesn't get worse by 
applying a filter that only selects your tone and as little else as 
possible. So you should do that – it makes your SNR better. Hence, your 
Signal power estimate gets more reliable (which you definitely want).


(that also highlights why I have a bit of doubt on your measurement 
methodology – if your SNR depends on receiver bandwidth, then how much 
does it actually tell you about the range, unless you specify the 
bandwidth alongside with it?)


Think about it: we typically assume noise to be white, i.e. to have 
identical power spectral density all over the spectrum, e.g. -170 dBm/Hz.


Now, if your receiver bandwidth is set to 2 MHz (because that's what 
your SDR is probably configured to filter out if you ask for 2 MS/s), 
then you get twice as much noise power than if you set the sampling rate 
to 1 MS/s.


It's the same thing that I always let students figure out by themselves 
the first time they use the lab spectrum analyzer:

Feed a 2 GHz -60 dBm tone into the spectrum analyzer.
Set the resolution bandwidth of the spectrum analyzer to 1 MHz, and tell 
me what the SNR is. Now set the resolution bandwidth to 300 kHz and tell 
me again.
You get as much "N" in your SNR as you let through your system. In the 
case of the spectrum analyzer, every point on the display is the power 
in 1 MHz (or 300 kHz) of filter. In the case of your Qt plot, it's the 
power in a FFT bin. There's (f_sample)/(FFT length) bandwidth to each 
bin; so your graphical analysis hinges on the setting of sample rate and 
FFT length (also, on window choice and labeling, and software 
convention). Proportionally!


It's really hard to define "SNR" for 0-bandwidth, i.e. a single tone 
(having a single tone, actually, gets tricky physically, but there's a 
lot of people who could tell you more about oscillators than I could).


If you'd be fair, the only choice for the noise filter bandwidth would 
be 0 Hz, because if you chose any wider, you always get more noise. But 
in 0 Hz, there's actually 0 noise power! So, that doesn't work.


Instead, you need to define SNR exactly on the bandwidth your detection 
system will have to use. That's a design parameter you haven't mentioned 
so far!


This 
is why I referenced the green and red lines on the qt gui freq. display, 
this would seem to give me signal strength in dB.


Hopefully, above explained how much these lines depend on your 
configuration and aren't "SNR".


Cheers,
Marcus



smime.p7s
Description: S/MIME Cryptographic Signature

Re: Custom Header Format object in OOT module

[Alex Roberts]

Think I finally found the answer to my problem in this old thread:
https://lists.gnu.org/archive/html/discuss-gnuradio/2015-07/msg00618.html

On Fri, May 29, 2020 at 12:18 PM Alex Roberts  wrote:

> Any one have thoughts on this? Haven't been able to to get it working yet.
>
> On Thu, May 21, 2020 at 4:56 PM Alex Roberts  wrote:
>
>> I’m trying to define my own customer header format object by inheriting
>> from header_format_base but when i try to use it I get the following errors
>> depending:
>>
>> If just instantiating without namespace
>> value “header_format_custom” can not be evaluated: name
>> “header_format_custom” is not defined.
>>
>> if instantiating with OOT modules namespace
>>
>> ‘oot.header_format_custom’ cannot be evaluated:
>> module object had no attribute ‘header_format_custom’
>>
>> Tried creating a variable block for grc similar to the Default Header Fmt
>> Obj. block
>>
>> I’d rather keep this in an OOT namespace than modify a local gr-digital.
>>
>>
>>

Re: Calculating SNR of an incoming signal

[Alex Batts]

The effective noise bandwidth is part of the calculation. I'm using the
radar range equation.

My purpose for including the bandwidth in my response was that any time I
try to use a filter with a frequency greater than my sampling rate/2 I get
an error returned. I agree that ideally I would use a band-pass filter with
very narrow cutoffs to best capture the signal in its entirety, however, I
can't because the frequency I'm trying to set my filter at is more than
half my sampling rate, giving me an error. Maybe there is something askew
with that error and it's something else, but it returns saying 0 < fa <=
sampling_rate/2

On Thu, Jun 25, 2020 at 3:27 PM Marcus Müller  wrote:

> Hi Alex,
>
> On 25/06/2020 21.00, Alex Batts wrote:
> > I'm sampling an incoming signal, but only around 2 MSps.
> >
>
> and that's fine! that's the *equivalent* baseband, it has all the same
> information as the RF signal.
>
> > I need the signal power to noise power ratio at the receiver as part of
> > my range calculation.
>
> Yes, but you'd always want to do that "signal to noise" only in the
> bandwidth that actually contains your tone; the rest will just contain
> more noise, interferers... to make your measurement worse.
>
> > So I would need to be able to distinguish between
> > the power of the tone vs the power of the surrounding noise and use
> > those two numerical values in an equation to calculate the range.
>
> You need to define "surrounding"! Your signal doesn't get worse by
> applying a filter that only selects your tone and as little else as
> possible. So you should do that – it makes your SNR better. Hence, your
> Signal power estimate gets more reliable (which you definitely want).
>
> (that also highlights why I have a bit of doubt on your measurement
> methodology – if your SNR depends on receiver bandwidth, then how much
> does it actually tell you about the range, unless you specify the
> bandwidth alongside with it?)
>
> Think about it: we typically assume noise to be white, i.e. to have
> identical power spectral density all over the spectrum, e.g. -170 dBm/Hz.
>
> Now, if your receiver bandwidth is set to 2 MHz (because that's what
> your SDR is probably configured to filter out if you ask for 2 MS/s),
> then you get twice as much noise power than if you set the sampling rate
> to 1 MS/s.
>
> It's the same thing that I always let students figure out by themselves
> the first time they use the lab spectrum analyzer:
> Feed a 2 GHz -60 dBm tone into the spectrum analyzer.
> Set the resolution bandwidth of the spectrum analyzer to 1 MHz, and tell
> me what the SNR is. Now set the resolution bandwidth to 300 kHz and tell
> me again.
> You get as much "N" in your SNR as you let through your system. In the
> case of the spectrum analyzer, every point on the display is the power
> in 1 MHz (or 300 kHz) of filter. In the case of your Qt plot, it's the
> power in a FFT bin. There's (f_sample)/(FFT length) bandwidth to each
> bin; so your graphical analysis hinges on the setting of sample rate and
> FFT length (also, on window choice and labeling, and software
> convention). Proportionally!
>
> It's really hard to define "SNR" for 0-bandwidth, i.e. a single tone
> (having a single tone, actually, gets tricky physically, but there's a
> lot of people who could tell you more about oscillators than I could).
>
> If you'd be fair, the only choice for the noise filter bandwidth would
> be 0 Hz, because if you chose any wider, you always get more noise. But
> in 0 Hz, there's actually 0 noise power! So, that doesn't work.
>
> Instead, you need to define SNR exactly on the bandwidth your detection
> system will have to use. That's a design parameter you haven't mentioned
> so far!
>
> > This
> > is why I referenced the green and red lines on the qt gui freq. display,
> > this would seem to give me signal strength in dB.
>
> Hopefully, above explained how much these lines depend on your
> configuration and aren't "SNR".
>
> Cheers,
> Marcus
>
>

Re: GNU Radio web API

[Steven Gillies]

Example?


> On 25 Jun 2020, at 18:55, Marcus Müller  wrote:
> 
> Such a thing exists: all blocks have a "system" message port!
> 
>> On 25/06/2020 13.40, Steven Gillies wrote:
>> Thanks Kevin,
>> It's good to know what I am trying to do is possible in practice.
>> I guess I was hoping for some sort of signal I could send that would be 
>> received by all of the OOT modules in the flowgraph as I think part of the 
>> problem is that I have a blocking call to accept a socket connection. It was 
>> when I tried to change this to a non-blocking call that I realised I didn't 
>> know how to let the loop know to exit (by setting self.is_running=False). I 
>> tried setting it in __del__(self) but it seems this is never executed.
>> In the end through some tinkering I've found that if I start the top_block 
>> inside multiprocessing.Process and terminate when I'm done then this seems 
>> to release all of the resources as you describe. Its not as elegant as I 
>> would have hoped but at least it works for now and I can revisit it if I've 
>> time.
>> For some reason, although it works fine in development, when I deploy it for 
>> production (inside Docker container) the process will not terminate, and if 
>> I try to join() then it hangs forever. To solve this I added a timeout and 
>> if the process is still alive I kill it.
>> All in all a bit of a hack, but I've got to start somewhere.
>> Cheers,
>> Steven
>> 
>> *From:* Kevin Reid 
>> *Sent:* 25 June 2020 04:34
>> *To:* Steven Gillies 
>> *Cc:* Discuss-gnuradio@gnu.org 
>> *Subject:* Re: GNU Radio web API
>> On Wed, Jun 24, 2020 at 8:04 AM Steven Gillies > > wrote:
>>I am trying to build a web API to start and stop flowgraphs remotely
>>and autonomously.
>>I am having trouble gracefully shutting down one flowgraph and
>>moving on to the next.
>>My preferred way implement the services is by running
>>top_block.start() from my main thread and allowing it to start its
>>own thread. To shut it down I then call top_block.stop() followed by
>>top_block.wait(). The threads appear to shut down gracefully but
>>when I try to run another flowgraph (either the same flowgraph again
>>or a different one) I start to get errors.
>>The two error types I get are either;
>> 1. that the second flowgraph cannot find the USRP device because it
>>is being held by the first ($ uhd_find_devices also returns 'No
>>Devices Found' until I exit the main thread at which point it
>>finds my B210 again), or
>> 2. that a socket that the second wants to bind to is in use by the
>>first
>> In my experience (I wrote ShinySDR , which is 
>> also a web remote control system), the cause of these problems is that 
>> references to the old blocks still exist. There is unfortunately no standard 
>> way to tell a block to free the resources it is using, other than ensuring 
>> it is "deleted" by dropping all references to it. Therefore, you need to 
>> ensure that your Python code does not have any variables or attributes 
>> referring to the old top block or the individual blocks, before you 
>> construct the new blocks.
>> That said, you may want to try the alternative of keeping the UHD, socket, 
>> etc. blocks around and reusing them, and only changing what they're 
>> connected to. (That's what ShinySDR currently does, though with different 
>> blocks.) Basically, use disconnect() as well as connect() to change your 
>> flow graph's connectivity while it's stopped so that it suits the new 
>> purpose. You might encounter some misbehavior here too, though; this is not 
>> a frequently used and well-tested part of GNU Radio's capabilities.
> 

Re: Packet TX and RX on E312

[Marcus D. Leech]

On 06/25/2020 12:44 PM, Cameron Matson wrote:
I moved my setup from e312s to n310s so that I could run the 
flowgraphs with the gui blocks to help with debugging.  It looks like 
the phase is off at the RX as the constellation gui from the USRP (the 
one before the Packet Rx block) is rotating.  I'm able to adjust the 
magnitude of the IQ data by playing with the tx and rx gain, but I 
can't get the phase to lock.


What are some of the knobs I can turn to help the Packet Rx block 
detect the signal given the phase offset?


Thanks,
Cameron
So an independent RX and TX will NOT be operating on exactly the same 
frequency.  This means that for many types of phase-sensitive
  modulation, the RX needs to track the phase rotation caused by the 
(small) frequency difference.  This is just standard modem

  design, and you'll need to look at carrier-tracking with PLLs, etc.

There are a plethora of folks on here more adept than I at suggesting 
which PLL approaches to take, but suffice it to say, any modem RX design

  that doesn't include some kind of PLL-based tracking is "born flawed".

Re: [USRP-users] 2021 IEEE Aerospace Conference

[Alex Humberstone]

Any update?

Would like to see the program for past conferences...



On Fri, 19 Jun 2020 at 22:44, Alex Humberstone 
wrote:

> Eugene, the conference looks interesting. Where can we find the program
> for past years to get a feel for the conference? I didn't see this on the
> website. Thanks.
>
>
> On Fri, 19 Jun 2020 at 17:02, Eugene Grayver via USRP-users <
> usrp-us...@lists.ettus.com> wrote:
>
>> Hello,
>>
>>
>>
>> I am chairing the Software Defined and Cognitive Radio session at the
>> upcoming IEEE Aerospace Conference (http://www.aeroconf.org).  This
>> large conference will take place March 6-13, 2021 in Big Sky, Montana.
>> The conference provides a world-class technical program and provides
>> excellent opportunities for both networking and recreation. This is one
>> of the few conferences where SDR can be put in the context of a complete
>> system and can be applied to new missions and concepts of operations.
>>
>>
>>
>> Last year there were a few papers dealing with application of
>> machine/deep learning to radio design.  I hope to see even more next year!
>>
>> Abstracts are due soon, but I can take them a bit later as well, while
>> the full paper is due end of October.  This session will focus on flexible
>> radio architectures, including the use of GPPs, GPUs,  and FPGAs.
>> Reports of existing systems and testbeds are of significant interest.
>> This year I’d like to introduce work related to machine learning as applied
>> to wireless communications.
>>
>>
>>
>> *Please forward this to your colleagues working in the areas of SDR and
>> cognitive radio.*
>>
>>
>> Regards,
>>
>> Eugene.
>>
>>
>> ___
>> USRP-users mailing list
>> usrp-us...@lists.ettus.com
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>
>
> --
> Sincerely,
> Alex-M-Humberstone
> PhD Student
> Klipsch School of Electrical Engineering
> New Mexico State University
> Las Cruces, New Mexico
>
>

-- 
Sincerely,
Alex-M-Humberstone
PhD Student
Klipsch School of Electrical Engineering
New Mexico State University
Las Cruces, New Mexico

Re: GNU Radio web API

[Kevin Reid]

On Thu, Jun 25, 2020 at 10:47 AM Marcus Müller  wrote:

> On 25/06/2020 05.34, Kevin Reid wrote:
> > There is unfortunately
> > no standard way to tell a block to free the resources it is using, other
> > than ensuring it is "deleted" by dropping all references to it.
>
> Well, technically, when a flow graph is finished running, the stop()
> methods are called for that very reason. But then you can't reconnect.
>

Yes. There is no distinction offered between "stop, for later restart" and
"stop permanently", for those blocks where it matters, except that in
practice the destructor is used to implement the latter. Arguably in most
cases it would be acceptable to reopen a file/device upon stop() followed
by start(), but that would introduce latency and also change semantics for
e.g. a network socket.


> We never thought about the proper semantics for that function. IMHO, we
> would have needed a "prepare for reconfiguration" state. And, we would
> have needed an explicitly defined state machine to begin with to not end
> up in a million different states...
>

The first idea that comes to mind is precisely defining a set of states
with transitions that are strictly linear, not branching:
"freshly-created/explicitly-disposed" ↔ "explicitly stopped" ↔
"reconfiguring" ↔ "running". That way you need up to three pairs of
setup/teardown operations but no more than that, and they can be understood
pairwise.

GR blocks currently have two such bidirectional state transitions which fit
this form: the C++ constructor and destructor, and the start() and stop()
methods. The work would be to separate the 'block object is initialized'
state from the 'external resources are held' state.


> > Therefore, you need to ensure that your Python code does not have any
> > variables or attributes referring to the old top block or the individual
> > blocks, before you construct the new blocks.
>
> Even then, Python garbage collection is non-deterministic, I think .
>

Only if a given object has participated in a cycle; if not, it's reference
counting that deletes promptly. Ensuring this can be a bit of a mess in a
program with callbacks, though, so this is among the reasons I'd like to
see explicit life-cycle controls for GR blocks.

Re: Symbol timing estimator block and CPM modulations

[Andy Walls]

Recommend reading
 
https://www.gnuradio.org/grcon/grcon17/presentations/symbol_clock_recovery_and_improved_symbol_synchronization_blocks/Andy-Walls-Samples-to-Digital-Symbols.pdf

Yeah, the MSK TED selections for the symbol sync block expect the constant 
envelope FSK waveform on the input.  Demodulation from FSK to baseband pulses 
should happen after the symbol sync block.

Re: Problems with the GNU WiFi and the USRP B210

[Marcus D. Leech]

On 06/25/2020 07:21 PM, Silvio Cardero wrote:


Please open and read the document

​

signature_658765992



Silvio Cardero

Chief Scientist

520.247.7275 (cell)

Web www.ed2corp.com 

Email Silvio@ed2corp _.com_

7636 N. Oracle Road

Tucson, Az. 85704

Same-box loopback without considerable attenuation in the coax is not 
healthy for the receiver (worst case), and best-case will cause

  non-linear operation of the receiver gain chain.

Most SDRs are designed so that their receivers can be used directly "on 
the air", and so have receiver gain stages that are optimized for
  that application.  That means that they will be horribly non-linear 
when presented with the high power levels produced by a typical

  transmitter.