Ok, I believe I have made up my mind. Since that I'm looking at a packetised
burst transmission system, the best way I have to remove latency from the
system is to flush the buffers in the gnuradio flowgraphs.
I can do this easily on the receiver side: once that I finish receiving my RF
data and I sent the IF samples down the pipe to gnuradio to process, I can just
add however many padding bytes are needed to have GR finish processing the
actual RF samples I care about. Packet synchronisation is going to take care of
discarding the padding/flushing bytes. Latency is then going to depend on my
CPU speed. That's good enough.
On the transmission side though, things are slightly more complicated. I could
send the same packet continuously and from the flowgraph output, sample 2 or 3
times the (known) packet length. This will ensure I have a IF modulated version
of at least 1 or 2 copies of the same packet. This is not perfect, but it
should be good enough.
Are they any blocks I could use to better synchronise the data input on my
transmitter flowgraph to its RF modulated output? For example, would the meta
file sink/source blocks help me with this? Can I use them to tell me "those
many input bytes are responsible for those many modulated bytes"?
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On April 5, 2018 10:41 PM, Mario Rossi <windti...@protonmail.com> wrote:
> Hello list!
> I'm using named pipes to stream data that I want modulated to gnuradio and
> I'm receiving modulated samples back using the same named pipes method. I
> then forward the modulated samples to a SDR via some low latency C
> implementation I wrote and perform the same operations in reverse at the
> receiving end.
> I'm for now experimenting with a simple FSK modulator/demodulator running at
> 50 kbaud/s, with 20 samples per symbol and 16 bytes (128 symbols) packet
> sizes. By embedding a timestamp in the packets before sending them I'm
> measuring an end to end latency ranging from 50 to 250 milliseconds (with a
> lot of jitter).
> This should mean that I have at least 300-1500 KB worth of buffers in my
> application (this was calculated using the data rate of the input/output
> data, it would be a much bigger number if I considered the modulated signal).
> My understanding is that most of the latency is coming from my input/output
> pipes/sinks, as once the signal is modulated each byte of my data in/out
> becomes 8 (bits per byte) * 20 (samples per symbol), so that each gnuradio
> block working with the modulated signal, in a worst case scenario where 4096
> samples are processed at the time, only corresponds to 25 bytes worth of
> buffered, unmodulated data at any given time (4096/(8*20)). Since that my
> buffer is at least 100 times that and I don't have 100 blocks, that shouldn't
> be the issue.
> Now on to my ideas on how to decrease latency for the input/output
> 1. Add padding bytes after the packet before sending it to the pipe/input
> file source block. Add a block after the file source dropping those padding
> bytes, that would probably require writing a custom block but should
> effectively eliminate any latency due to pipes and the file source block. A
> similar method can be used for the file sink block.
> 2. Use gr-eventstream to implement some version of the above. Not sure if
> this would be of any use though, I haven't spent much reading about it.
> 3. Hack the input/output sink blocks to (for example) allow a maximum output
> buffer lower than 4096 (I'm met with an error when I try to set the output
> buffer of my file source block to anything less than that).
> 4. Same as the first idea, but don't drop the padding bytes/data. Instead
> leave the blocks running with junk at the end, so that the output will be
> what you want and junk there after. This isn't a problem at the receiver
> because of how packet synchronisation works, but you would need to somehow
> know what's going on with your output IF pipe in your transmitter stream.
> This would also get rid of all the buffers/latency from all of gnuradio.
> Any other ideas, or suggestions on what is the most feasible path?
> I hope this email isn't too confusing, I know I don't have a gift for
> Thank you.
> Discuss-gnuradio mailing list
Discuss-gnuradio mailing list