Accessing Flowgraph Buffers

[aponplugins]

I'm attempting to run my UHD SDR through a simple flowgraph continuously, and I want to access the data coming through such that it is constantly updating. This way I can make a custom live-plot in a local window with plotters. I've tried using the vector sink as an output, but this won't update unless the flowgraph is finite. I've also attempted to create custom Block which will send an output message with the Vec of data to plot, but am unable to get it to work. I've tried to use a Block that owns and updates a Window, but I can't safely send it across threads. I'm trying to avoid using WASM if that's possible.

let ns = 128;

let mut fg = Flowgraph::new();

let src = SourceBuilder::new()
    .frequency(100000000.0)
    .sample_rate(1000000.0)
    .build()?;

let sink = VectorSink::new(4096);

connect!(fg, src > sink);

Runtime::new().run(fg);

let vec_sink = fg
    .kernel::<VectorSink<Complex32>>(sink)
    .unwrap();

let my_live_updating_vector = vec_sink.items()

update_fft_plot(my_live_updating_vector);

Essentially I'm wondering if there's a way to have my_live_updating_vector be continuously populated by the flowgraph output.

[bastibl]

The vector sink is not make for live updates. You can pipe the samples into a websocket and display on the web frontend (https://twitter.com/bastibl/status/1476552866336813056) or you a simple Python script to plot live (https://twitter.com/bastibl/status/1625528632587304962),

Or you pipe the samples into a TCP or ZMQ Sink and use, for example, GNU Radio to plot.

[aponplugins]

Thanks! I just got a ZMQ socket sink to work and live-plotted with matplotlib in Python. Unfortunately, the websocket sink was not working well with matplotlib for me as it didn't like being outside the main thread. ZMQ is working well but it's super slow on the read side. To fix this I tried looking into increasing the buffer size through the config.toml and the size setting on the ZMQ sink. However, I can't get it to pump out more than 4096 samples. Am I supposed to pass the config.toml as a CL argument or something? I have the buffer and queue size set to 32768.

[bastibl]

Can you please share the code. The websocket worked fine for me. Also when you don't need really high performance, the ZMQ link shouldn't be an issue. So I'm not sure what you mean with "super slow". Also, a complex float is 8 byte. So if the buffer is 32k byte, it will fit 4k complex floats. You can configure the buffer size through environment variables or config.toml files in the working directory or in your users config directory, but that's not the problem.

[aponplugins]

For the websocket code I was just running the spectrum example with the python code from the linked tweet. Matplotlib would work fine for a few .recv() calls and then suddenly stop plotting, even though it seemed as though the socket was still receiving information and matplotlib was not blocking. I tried throttling and removing the asynchonous python code but had the same issue. For the ZMQ socket I just replaced the websocket sink with a TCP sink and the python websocket with a zmq socket. Matplotlib worked fine but the recv() took a long time for 1 Msps. Even after the flowgraph was long done sending to TCP, python was still pulling buffers out of the socket.

[aponplugins]

Also, sort of unrelated, but I am also trying to figure out how to schedule things simultaneously. I've made a triggering block that responds to messages and either receives or transmits by allowing buffers to pass through it. However, I can't trigger on a microsecond level. I am trying to have my SDR receive and transmit at the exact same time in a scheduled manner. I saw that there were a few scheduler modules in futuresdr but was unable to find too much discussion on them. Is there any way to do this?

[bastibl]

Can you please share some code to understand how you tried to do this. Async messages do not have strict timing out-of-the-box, but ms-timing should be easily possible. How to do tighter timing depends on your application.

[etschneider]

If I understand what you are trying to do, you are going to need to add sample counters to your "triggered" blocks and use that value in your (timed) trigger condition. Your transmit block will need to send a continuous zero stream when not triggered to maintain the proper sample count.

Technically you could use transmit timestamps for burst transmissions if your radio hardware that supports it, but the current Soapy blocks don't do that yet. It is on my short list.

You could do one-shot timed tx/rx using the timed start Soapy feature (if your radio supports it), which is implemented. But I'm assuming that you are looking for repeated trigger events.

[aponplugins]

Yes that's exactly what I'm trying to do, having timestamps associated with buffer samples would be the ideal solution. Unfortunately it is a lot of code to include my implemented blocks but I can attach the flowgraph if you're still interested. Currently, I do have proper millisecond level timing with asynchronous events but I would probably need <microsecond level timing without timestamps. I'm relatively new to SDR at this level, but if there's anything I can do to help out with timestamps in the Soapy blocks let me know. In terms of hardware I'm currently working with a few different USRP SDRs.

[etschneider]

Seeing code would help.

Are you specifying the trigger time in your message to the block? Or are you expecting the the message to be processed by your block in the same microsecond that you send it? If the later, that's not going to happen. The signals are buffered and processed in relatively large chunks for performance reasons.

AFAIK UHD doesn't support timed rx bursts. You could do it with a (custom) RFNoC block, but that is another beast all together.

If you want to be able to extract a window of samples at a precise time from an rx channel, you are still going to need to use sample counting inside an rx block. You could also use stream tags to mark the trigger sample, but that just pushes the problem to an upstream block.

Since the block work() function is provided a (relatively large) vector of samples every time it is called, and the sample you want will very likely be in the middle of the vector, there needs to be logic in the block handle receiving the desired starting sample at any position in the sample vector.