Request/Ideas for Blocks

[bastibl]

We have nearly no blocks at the moment. Let's collect which blocks you're missing most or what fancy blocks you'd like to see.

• Audio Source/Sink (see AudioSource & AudioSink #4)
• ZeroMQ Source/Sink (see ZeroMQ PubSink & SubSource #3)

[loic-fejoz]

In my view, we should add all blocks for minimal AM & FM transmission, including rpitx sink so as to transmit with a Raspberry. While I know it is not that good, it would be useful for testing purpose of satellites decoding and CubeSat design. The other idea is to be able to run some packet decoding as WASM (more probably wasmer.io for me) from WAV files.

• AddConst, MultiplyConst
• Add, Multiply
• Repeat (?)
• SignalSource
• Complex to Mag, Complex to Float
• Automatic Gain Control
• Low Pass Filter, Band Pass Filter,
• Frequency Xlating FIR Filter
• Squelch
• Delay
• Throttle
• WAV file Source/Sink

PS: But maybe RPITxSink could be in another dedicated crate. Or see with RustEmbeded if we can do it with in a more agnostic board way.

[F5OEO]

Would be happy to help if any plan to have a rpitx sink :)

[loic-fejoz]

I guess @F5OEO one should first create a crate that wrap librpitx, right? Probably with the help of Bingen if it works on your C++...

[bastibl]

An RPITx Sink with a simple example ported to rust (e.g., FM) would be awesome :-)

[mryndzionek]

Hello,
First of all great project! I was experimenting with similar async/stream bases frameworks for SDR and DSP in general.
Here are my two projects:

• composable-sdr - written in Haskell, uses streamly at its core
• dsp-experiments - written in C, but uses libdill for async/coroutines and multi-tail ring buffer from libwebsockets

Both use FFI to call into SoapySDR, liquid-dsp and RTAudio for specific processing blocks. My question is would it be acceptable in FutureSDR, or do you envision having everything (most?) written in Rust?

[bastibl]

Glad you came across the project! And great references, I'll have a closer look.

I think adding blocks for non-trivial DSP (for example from liquiddsp) would be perfectly fine. As already hinted in a comment to your PR, I'd leave the FFI and high-level Rust bindings in a separate crate and feature-gate the blocks that use these bindings. This way, there shouldn't be any downside, if someone doesn't want this dependency (for example, because it complicates the build), it can just be disabled through the feature flag.

[LongHairedHacker]

After some experimenting with porting my APT-decoder to FutureSDR I'd like to add two more blocks to the whishlist:

• Upsampler
• Downsampler
• Alternatively: Rational Resampler (Combination of up and downsampler)

The upsampler case is simple, it can be done by simply repeating input samples.
(E.g. for a times 4 upsampling, just repeat every input sample 4 times)
I've already implemented a prototype here.
It's a prototype because I'm not 100% confident if it handles finite input stream correctly (especially setting io.finished at the right time).
Coming from gnuradio I might have made some incorrect assumptions on how blocks should behave.

The downsampler can be quite simple as well.
The most basic approach is to drop samples. So if I downsample by 4, the block only copies the first sample to the output, drops the subsequent 3 and then copies the fifth sample to the output again.
That approach works well, assuming there is a suitable low pass filter before it (the low pass ensures 4 samples should be roughly the same value already, so it should not matter to which one the downsampler picks).
Note that in my apt-decoder implementation I'm averaging the samples and using the average as output instead of just dropping them.
That approach has some low pass like properties, allowing you to get rid of the low pass in some cases,
but it's not well suited all use cases, so I would recommend doing it like that.

For the low pass/high pass/band pass filters I'd suggest implementing a generic FIR filter first,
which can be constructed from filter coefficients.
(Similar to my crude implementation here)
Then add a helper function e.g. in the Builder for the block, to generate the coefficients from a list of frequencies and gains.
Similar to scipy.signal.firwin2.
Low pass, high pass, and band pass can the be implemented using helper functions on top of that.
Leveraging rusts macro and const fn magic it might even be possible to generate the coefficients at compile time,
if the desired frequencies and gains are compile time constants.
(That's something I'd like to try and implement, because I never really understood the window method back in my signal processing courses and it bothered me ever since.)

[LongHairedHacker]

Tiniest of updates from me: I never got around to implement filter design tool similar to firwin2. However I did something way better, at least for my use cases.

However I recently noticed that the nalgebra crate has a least squares solver, and at least according to to my digital filter course back in university, the least squares method has some nice advantages over the windowed methods.
So I basically went and did the most naive and straight forward implementation of https://ccrma.stanford.edu/~jos/sasp/Least_Squares_Linear_Phase_FIR_Filter.html that I could.

https://gitea.zenerdio.de/sebastian/firls-rs/

It comes with two macros firls_real! and firls_complex!, that allow you to write code like this:

const COEFFS: [Complex<f32>; 23] = firls_complex!(
    23,                                                        //number of taps
    8000.0,                                                    // sampling frequency
    [(0.0, 1.0), (1200.0, 1.0), (1500.0, 0.0), (4000.0, 0.0)], // passband from -1.2khz 0 to 1.2kHz
    1500.0                                                     // frequency shift 1.5kz to the left
);

firls_complex! is the bigger brother to firls_real!. It first creates a real-valued filter, which would be symmetric to 0Hz if applied to a analytical/complex-valued signal and multiplies the coefficient with a complex oscillator to frequency shift it into something asymmetric with complex-valued coefficients.
Not the ideal approach, to complex fir filters, but it is simple to implement on top of the least squares method.

The resulting filter looks like this:

This is my first time messing with proc macros and nalgebra and the aforementioned digital filter course, also was a really long time ago, so take this as a proof concept at best.
I'll continue to polish it as far is can and add some documentation.

If someone wants to "steal" the concept and implement it properly for future_sdr, I wouldn't mind at all.

[bastibl]

Cool, thanks for the update. We have a generic FIR filter in-tree now. You should be able to directly put in those taps to get a typed FIR filter (specific/monomorphized for the given number of taps): https://docs.rs/futuresdr/latest/futuresdr/blocks/struct.FirBuilder.html

There is also a FIR builder, but I'm not sure how it compares to your implementation (I'm not really a DSP guy -.-): https://docs.rs/futuredsp/latest/futuredsp/firdes/index.html

[mryndzionek]

the least squares method has some nice advantages over the windowed methods.
So I basically went and did the most naive and straight forward implementation of https://ccrma.stanford.edu/~jos/sasp/Least_Squares_Linear_Phase_FIR_Filter.html that I could.

You must be reading my mind! Just days ago I've been experimenting we the exact same thing: https://github.com/mryndzionek/hilb_trans/blob/main/des_firls.py#L100

[brianbreitsch]

Hello,

I really like this project, and want to see if it's viable for some work I'm doing with GNSS receivers. Right now I need to implement a FileSource that can read 4-bit complex samples. In fact, a more robust set of file sources would be useful to me, since I sometimes deal with 2-bit, 4-bit, 8-bit, and 16-bit complex integer samples with different packing orders. Is this just a matter of adapting the FileSource block to do the correct unpacking?

[bastibl]

Either that or use a FileSource::<u8>, i.e. one that reads bytes, and add a custom block directly after it that does the unpacking. I'd go for the latter, since it seems to be more reusable, since it allows unpacking any byte stream no matter where it comes from.

I'm not completely sure what is unpacked to what, but the ApplyNM block might come in handy to implement this on the fly (i.e., without creating a full block). https://docs.rs/futuresdr/latest/futuresdr/blocks/struct.ApplyNM.html

[etschneider]

I'd be glad to help with this if you want.

I'm also a GNSS guy. I'd love to hear about what you are doing with it in Rust!

[brianbreitsch]

@bastibl Thanks for the insight! I started by using the Apply block after a FileSource<u8>:

    let src = FileSource::<u8>::new(samples_filepath, false);
    let head = Head::<u8>::new(100);
    let convert = Apply::new(|i: &u8| Complex {
        re: (i & 0x0F) as f32,
        im: ((i & 0xF0) >> 4) as f32,
    });
    let sink = NullSink::<Complex32>::new();

I won't really know if it worked until I can run some sort of processing after the conversion, but I think this is roughly correct. I suppose ApplyNM could be useful for other sample bit depths.

@etschneider I basically just want to see how viable Rust is for doing GNSS receiver development -- I'm starting out with trying to get just a simple acquisition and tracking loop running for GPS L1CA. I'd love to know if you have any insight or if you've tried any GNSS stuff in Rust!

[etschneider]

@brianbreitsch I've written multi-constellation simulators in C++ and Rust. Rust is better. :-)

I have considered making ACQ and correlator/tracking blocks myself, but my plate is getting pretty full at the moment. I'd certainly assist when I can.

Re: your converter, looks good to me. You could of course use a Complex32 file sink and your existing GNSS tools to test.

[etschneider]

Oh, re: converter, if your nibbles are signed you'll need to handle that. And you might also want to do zero centering and scaling to +/- 1.0, as is pretty standard.