Re: GNU Radio web API

[Kevin Reid]

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.

Windows Binaries for 3.8.1.0 Available

[Geof Nieboer]

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

Re: Osmocom Source (frequency deviation)

[Jeff Long]

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)

[Jeff Long]

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]

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)

[Jeff Long]

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]

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)

[Jeff Long]

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
>
>

Osmocom Source (frequency deviation)

[Artur Nogueira]

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: Radar Project - BladeRF2.0

[Doug]

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: Radar Project - BladeRF2.0

[jean-michel.fri...@femto-st.fr]

SDR based RADAR will be discussed at 6:30 PM European time as
announced at https://2020.sdra.io/pages/programme.html

The slides are at http://jmfriedt.free.fr/sdra_radar.pdf

RThe reference on slide 17 explains how to switch LO frequency without
stopping the data stream when using osmosdr. Not sure how it is applicable
to the BladeRF.

JM 

--
JM Friedt, FEMTO-ST Time & Frequency/SENSeOR, 26 rue de l'Epitaphe,
25000 Besancon, France

June 24, 2020 3:04 PM, "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

Re: Radar Project - BladeRF2.0

[Sebastian Müller]

  
Hi Dionisio,
  
  
probably gr-radar [1] is a good starting point for that. Based on Ettus USRP 
though.
  
  
[1]  https://github.com/kit-cel/gr-radar
  
  

  
Mit freundlichen Grüßen/Kind regards
  
Sebastian Müller
  
  
  
On Jun 24 2020, at 3:03 pm, 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 theFrequency 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
>   
>   
 

GNU Radio web API

[Steven Gillies]

Hello everyone,

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

All threads I create are daemon threads, but since the main thread doesn't shut 
down in my software then I guess that's irrelevant while my code is running.

Are there any examples of how to programmatically teardown flowgraphs so that 
they free all resources?

Or ways that I can manually free up resources from outside of the top_block, 
for instance using the uhd library.

Im using GNU Radio 3.7, UHD 3.14 and the USRPs we use are Ettus UHD B210s.

Any help appreciated,


Steven

Re: Calculating SNR of an incoming signal

[Marcus Müller]

Hi Alex,

one's signal is another person's noise... You need to define of what 
nature your signal is, and then you can (often) quite easily build an 
SNR estimator for that specific signal :)


Best regards,
Marcus

On 24/06/2020 14.58, Alex Batts wrote:

Hello,

I am relatively new to GNU Radio and I am trying to calculate the SNR of 
an incoming signal. On the QT Gui frequency display it shows a red line 
and a green line which I take to be the average noise power and average 
signal power of the incoming signal (from my RTL SDR) respectively. Is 
there any way I can utilize in real time the values of these two lines 
to calculate an SNR? If not, is there a way to determine a value at a 
specific frequency/average value over a range of frequencies for this 
calculation?


Thank you in advance,

Alex




smime.p7s
Description: S/MIME Cryptographic Signature

Re: Packet TX and RX on E312

[Cameron Matson]

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: Empty file at File Sink for BPSK mod simulation

[Jeff Long]

... 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: Empty file at File Sink for BPSK mod simulation

[Jeff Long]

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
>

Radar Project - BladeRF2.0

[Dionísio de Carvalho]

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

Calculating SNR of an incoming signal

[Alex Batts]

Hello,

I am relatively new to GNU Radio and I am trying to calculate the SNR of an
incoming signal. On the QT Gui frequency display it shows a red line and a
green line which I take to be the average noise power and average signal
power of the incoming signal (from my RTL SDR) respectively. Is there any
way I can utilize in real time the values of these two lines to calculate
an SNR? If not, is there a way to determine a value at a specific
frequency/average value over a range of frequencies for this calculation?

Thank you in advance,

Alex

Empty file at File Sink for BPSK mod simulation

[Grace Huang]

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