Re: [Discuss-gnuradio] UDP Sink Broadcast

[Mark Gannet]

The make method in udp_sink doesn't allow for broadcast right?

On Mon, Mar 18, 2019 at 1:38 PM Mark Gannet  wrote:

> Hi,
>
> Does anybody know of a way to broadcast to a UDP Sink block?  A unicast
> works fine but setting the destination address to 172.168.255.255 always
> gives a permission denied error even when running as su.  The firewall zone
> for all adapters is set to "trusted."  Is there a way to set an
> SO_BROADCAST flag like you might do when creating a UDP socket from the
> Python socket module?
>
> Thanks,
> Mark
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] UDP Sink Broadcast

[Mark Gannet]

Hi,

Does anybody know of a way to broadcast to a UDP Sink block?  A unicast
works fine but setting the destination address to 172.168.255.255 always
gives a permission denied error even when running as su.  The firewall zone
for all adapters is set to "trusted."  Is there a way to set an
SO_BROADCAST flag like you might do when creating a UDP socket from the
Python socket module?

Thanks,
Mark
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Distance Measurement by Correlation

[CEL]

I don't intimately know the BladeRF driver, but it seems unlikely that
the USRP is way more computationally intense than the BladeRF. Chances
are the BladeRF driver doesn't /show/ the same errors.

Be a bit careful about saving away the data: your storage must be up to
supporting the constant data rate even in a realistic worst-case
scenario – a storage device with high average rate might still have
high variance in write speed, and that might or might not be manageable
with some limited write buffers.

Best regards,
Marcus

On Sun, 2019-03-17 at 22:26 -0700, Jonathan Preheim wrote:
> Thanks for the advice all. It turns out the BladeRF is not transmitting 
> properly in this case. I probably should have figured that out long ago. An 
> equivalent flowgraph (for some reason my original did not work) performed as 
> expected at lower sample rates with a USRP b205.  
> 
> Follow up: It does not seem like GRC plots can keep up with incoming RX data 
> without having overflows from the USRP. I imagine all I can do about this is 
> save to a file and process (i.e. correlate and display) the data later? It 
> seems odd that that was not a problem with the BladeRF that I was aware of. 
> 
> Thanks,
> Jonathan
> 
> On Wed, Feb 27, 2019 at 4:17 PM Qasim Chaudhari  
> wrote:
> > To clarify a confusion in my last email, by "until the point in signal 
> > processing chain where you decimate the signal down to the symbol rate", I 
> > meant the stage just before quantization; otherwise carrier recovery in 
> > BPSK still needs to work with complex samples at symbol rate.
> > 
> > Cheers,
> > Qasim
> > 
> > 
> > On Thu, Feb 28, 2019 at 11:06 AM Qasim Chaudhari 
> >  wrote:
> > > Some pointer that might help you.
> > > 
> > > - No, the samples are not completely real in BPSK until the point in 
> > > signal processing chain where you decimate the signal down to the symbol 
> > > rate. From what I understand your problem, and given that your purpose is 
> > > to find the correlation peak instead of demodulating the data, you'd be 
> > > dealing with both I and Q samples.
> > > 
> > > - Be very careful with conjugation as they bring in both conjugation and 
> > > reversal in the other domain 
> > > (https://dsp.stackexchange.com/questions/23733/conjugation-in-fourier-transform).
> > >  Furthermore, you're correlating it with a clean copy that is stored in 
> > > your system so there is a usual discrimination between cross-correlation 
> > > and auto-correlation, the latter being the operation in which 
> > > conjugations remove the phase/frequency effects and not the former.
> > > 
> > > - Regarding the Costas loop, I usually do not trust the acquisition 
> > > range/acquisition time numbers from simulation to practice, as 
> > > simulations are done at a certain SNR with only one imperfection present. 
> > > Even if everything expected is simulated, the loop starting points cannot 
> > > be carefully controlled due to the unknown incoming phase! In addition, 
> > > acquisition is a highly non-linear operation which strongly depends on 
> > > both the Rx SNR and the loop SNR as well as the shape of the channel 
> > > frequency response. In this particular ranging application, I would 
> > > rather tune the frequency of one USRP receiving a test signal (e.g., 
> > > simple CW and employing a simple PLL) until I get the lock. Then in the 
> > > next experiment, I would initiate my ranging procedure and track small 
> > > changes from there. Also keep in mind that there is a finite acquisition 
> > > time for the loop to settle which might comprise of your entire sequence 
> > > to be correlated. At least it will certainly eat away some part of it.
> > > 
> > > Finally, Marcus' suggestion of starting with the simplest case and seeing 
> > > where your signal deviates from what you expect is probably the best way 
> > > to move forward.
> > > 
> > > Cheers,
> > > Qasim
> > > 
> > > 
> > > On Wed, Feb 27, 2019 at 6:58 PM Jonathan Preheim 
> > >  wrote:
> > > > Hi all,
> > > > 
> > > > Thanks for the responses. Ultimately, we won't be able to share a clock 
> > > > source directly, and I don't have the right cables right now to link 
> > > > them for troubleshooting. Even when I try to use the RF loopback modes 
> > > > though, I do not see a correlation peak. Firmware-based loopback works 
> > > > as expected. I've been trying to model a frequency offset with the 
> > > > Channel Model block, and compensate with the Costas loop block with a 
> > > > little success. But actually doing it on the radios does not work. 
> > > > 
> > > > The Costas loop handles frequency offsets up to 0.05 in simulations 
> > > > with an otherwise ideal channel. The chip rate is 1.25Mchip/s, so 
> > > > that's an offset of about 63kHz. The BladeRF's clock is 38.4MHz 
> > > > accurate to 1 ppm or 38.4Hz. Multiplied up to our carrier frequency of 
> > > > 910MHz, that's an expected accuracy of under 1kHz, so it's reasonable 
> > > > to expect that the 

[Discuss-gnuradio] European GNU Radio Days contribution deadline (March 21st)

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

The European GNU Radio Days contribution deadline is getting close (set to
March 21st). Please consider contributing if you wish to share the results
of your work either as oral presentation, demonstration or tutorial.

The template and submission site are available at 
https://gnuradio-fr-19.sciencesconf.org/
Contributions will be published on the GRCon Proceeding web site at
https://pubs.gnuradio.org

See you there, Jean-Michel

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

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Propsal draft: Block Header Parsing Tool

[Arpit Gupta]

Hello everyone, I am Arpit Gupta, an undergraduate from Indian Institute of
Technology Roorkee, India. I wish to contribute to the project idea: Block
Header Parsing Tool. This link
 is
the draft of my proposal. Kindly review it and give your valuable
suggestions.
I gave my best to incorporate all the suggestions provided to me during the
discussion of this project.
If there's something that I am missing out, please do inform me.
Thanks!

Regards,
Arpit Gupta
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio