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"? Thank you, Mario ‐‐‐‐‐‐‐ 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 > pipes/blocks: > > 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 > writing. > > Thank you. > > > Discuss-gnuradio mailing list > > Discussfirstname.lastname@example.org > > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio _______________________________________________ Discuss-gnuradio mailing list Discussemail@example.com https://lists.gnu.org/mailman/listinfo/discuss-gnuradio