Re: Modulation technique for sliding correlator channel sounder
Thanks, I'll check them out. On Thu, May 28, 2020, 12:36 AM Marcus D Leech wrote: > While there are lots of folks on this list who can probably answer your > question, your question is actually a much more general question about > signals, channels, and DSP and only really tangentially about GNU Radio per > se. > > There’s a few online signal processing forums that might be able to help > if you can’t find an answer here. > > Www.dsprelated.com > Www.complextoreal.com > > And the pointers in the gnuradio.org website on external resources. > > Sent from my iPhone > > > On May 27, 2020, at 6:24 PM, AKINYELE ITAMAKINDE < > aitamaki...@abuad.edu.ng> wrote: > > > > > > Good day to you, > > I am working on propagation channel measurement using a sliding > correlator channel sounder flowgraph for Tx and Rx. The sliding correlator > channel sounder flowgraphs I've gotten so far from internet search have no > modulation technique. Does that show it does not require modulation > technique? If yes, why? > > Thanks. > > Akinyele >
Re: Which guarantees, if any, do messages provide?
Hi Sylvain, That was very useful, thanks. I did some more experiments meanwhile and they seem to confirm what you are saying: Messages come in at pretty much random times and in big bursts (despite in order). For example, the messages of "Message Strobe" every 100ms (which is a very long interval) arrive in bursts of three every 300ms. So I think these messages are pretty much useless except for simple, nontime critical things. I ended up building a "Message-to-Tag" block. It queues incoming messages and inserts them as tags at predictable intervals. That works well. However, now I have a stream of zeros (the block doesn't output any data except tags) with a tag attached to a zero once every tens of thousands of samples. Feels pretty wasteful. Is there really no better way? Thanks, Lukas > Gesendet: Freitag, 22. Mai 2020 um 03:45 Uhr > Von: "Sylvain Munaut" <246...@gmail.com> > An: "Lukas Haase" > Cc: "discuss-gnuradio@gnu.org" > Betreff: Re: Which guarantees, if any, do messages provide? > > Hi, > > > For example, I use "Message Strobe" to create a message every 10ms. A > > custom blocks creates a pulse when the message is received (it does so by > > putting the message into a std::queue in the message handler and retrieving > > it in the work function). > > When I trigger on one pulse and zoom out, I ideally would see one pulse > > exactly every 100ms. However, the pulses jump around (i.e., the period > > always changes). > > Yeah, that's why they're called asynchronous messages. > > > > 1.) What is the typical latency of messages? > > Too dependent on too many factors to provide any meaningful answer. > They're not artificially delayed ... so "as fast as possible" is the > only thing I can say. > > > > 2.) Related, what is typically the maximum speed for sending messages? Is > > sending messages at >1kHz (i.e., "Message Strobe" with interval <1ms) > > meaningful? > > As fast as you can process them. > I've had bursts decoder use message for decoded bursts and that was > for sure reaching 1k packet per second. > > I thought there was a back pressure mechanism to block senders if the > queue was too long, but I can't find it in the code :/ So if there > really isn't any, be careful of your memory footprint could grow > without bounds. > > > > 3.) Are there any "guarantees" on maximum/minimum delay? (for example, I > > read that the message handler is guaranteed to be executed when work() is > > not. Is an upper bound of delay (in samples) given by the worst case > > execution of the work function, i.e. the size of the output buffer?) > > None whatsoever. > > > > 4.) Can I be sure that all messages are received or does gnuradio silently > > drop messages under certain conditions? > > It won't drop messages. > > > > 5.) Are messages always received in correct order? > > Yes > > > Cheers, > > Sylvain >
Re: Modulation technique for sliding correlator channel sounder
While there are lots of folks on this list who can probably answer your question, your question is actually a much more general question about signals, channels, and DSP and only really tangentially about GNU Radio per se. There’s a few online signal processing forums that might be able to help if you can’t find an answer here. Www.dsprelated.com Www.complextoreal.com And the pointers in the gnuradio.org website on external resources. Sent from my iPhone > On May 27, 2020, at 6:24 PM, AKINYELE ITAMAKINDE > wrote: > > > Good day to you, > I am working on propagation channel measurement using a sliding correlator > channel sounder flowgraph for Tx and Rx. The sliding correlator channel > sounder flowgraphs I've gotten so far from internet search have no modulation > technique. Does that show it does not require modulation technique? If yes, > why? > Thanks. > Akinyele
Modulation technique for sliding correlator channel sounder
Good day to you, I am working on propagation channel measurement using a sliding correlator channel sounder flowgraph for Tx and Rx. The sliding correlator channel sounder flowgraphs I've gotten so far from internet search have no modulation technique. Does that show it does not require modulation technique? If yes, why? Thanks. Akinyele
Fwd: OTA Encoding/Decoding with Ettus SDR & GNURadio
Here is a cleaner updated flowchart from my previous question: https://imgur.com/1uuqT9J (I removed lines running behind blocks - Thanks Marcus for the tip) -Roman -- Forwarded message - From: Roman A Sandler Date: Wed, May 27, 2020 at 10:31 AM Subject: OTA Encoding/Decoding with Ettus SDR & GNURadio To: Cc: Hi, I am trying to do over-the-air (OTA) encoding and decoding using GNURadio and an Ettus SDR. I used a basic flowgraph (shown at https://imgur.com/a/P846OSe) which I know can correctly decode the encoded signal w/ 0 BER in simulation (w/o/ the SDR blocks). However, using the SDR sink/source blocks, I can no longer recover the correct bits. Here is how the visualized recovered data looks like: https://imgur.com/a/Z5JfvjS. As you can see I am unable to recover the original encoded bits. So my questions are: 1) What am I doing wrong? 2) Are there any articles/tutorials which discuss how to encode/decode w/ GNURadio & Ettus SDR? Thanks, Roman
OTA Encoding/Decoding with Ettus SDR & GNURadio
Hi, I am trying to do over-the-air (OTA) encoding and decoding using GNURadio and an Ettus SDR. I used a basic flowgraph (shown at https://imgur.com/a/P846OSe) which I know can correctly decode the encoded signal w/ 0 BER in simulation (w/o/ the SDR blocks). However, using the SDR sink/source blocks, I can no longer recover the correct bits. Here is how the visualized recovered data looks like: https://imgur.com/a/Z5JfvjS. As you can see I am unable to recover the original encoded bits. So my questions are: 1) What am I doing wrong? 2) Are there any articles/tutorials which discuss how to encode/decode w/ GNURadio & Ettus SDR? Thanks, Roman
Re: Finding performance issues
Hi John, which version of GNU Radio are you using? Also: for this receiver, you're not using the long-deprecated Packet Decoder / Encoder Blocks, are you? Best regards, Marcus On 5/26/20 9:29 PM, John Langworthy wrote: Hello, I am working on a fairly simple GMSK receiver that needs to run on a Raspberry Pi 4. Its dropping some large packets and I suspect a performance bottleneck somewhere. It runs perfectly on a desktop. I think CtrlPort Monitor will help me find it and I’ve tried to build gnuradio with support for it, unsuccessfully at the moment. I am surprised that I am having so much difficulty with CtrlPort Monitor, perhaps its not heavily used and hence maintained. What is the normal workflow for moving from desktop top to embedded, finding performance issues and determining how much CPU/timing headroom is left? Thanks John
