In order for the team/community to understand the purpose and aims of the project, a project README shoudl be created.

This should be pretty straightforward. We need to be able mix things up and down in frequency with the software equivalent of an oscillator.

Likely this is the type of operation we'll want to run as a batch in a real system, so make sure to include support for both sample by sample processing as well as batch processing.

For debugging and error reporting purposes, we would like to add logging support to the library.

Update documentation for the pulse module. In particular:

• Add single line descriptions where missing, and extended descriptions where necessary
• Add arguments sections where missing
• Add examples sections where missing
• Ensure all docs tests are passing

Use the util module documentation (or better) as a target for level of completeness.

The documentation seems pretty sparse. Probably should make a concerted effort to comb through it and add where you can. Since 'improve documentation' is a pretty vague goal we should discuss some kind of boxed boundaries for the scope of this, or maybe just vote on whether it's good enough or something.

Anyways, I feel like we can do a bit better here.

As different nodes have different type requirements, it's often needed to convert from one type to another. We'd like to create nodes to support the following:

• Convert from Complex to Complex.
• Convert from Vec<Complex> to Vec (alternating real/imag).
• Convert from T to U assuming U: From.

Currently there isn't a good way to handle errors that occur within a node and propagate them up to the network. We need a way to try to handle errors, tell when nodes are being starved, etc.

Update documentation for the prn module. In particular:

• Add single line descriptions where missing, and extended descriptions where necessary
• Add arguments sections where missing
• Add examples sections where missing
• Ensure all docs tests are passing

Use the util module documentation (or better) as a target for level of completeness.

If you include a trailing comma in the list of nodes to start, start_node! and start_node_threadpool! throws an error.

We'd like to be able to support multi-sends, i.e. one node sends multiple times on the same channels. This would be useful in cases where the node generates a vector but data should be sent out of the node one sample at a time.

To decrease the barrier to entry for contribution, a basic skeleton of the project should be created so that developers can write code for the comms-rs project.

Acceptance:

• Documentation for contribution or project skeleton created
• Issues generated to support fleshing out the skeleton
• Deployment keys/system determined

We would like to be able to send and receive samples via ZeroMQ.

In order to allow control of nodes, we need to be able to support inputs into the nodes that are provided on demand versus on every iteration of the node.

Update documentation for the hardware module. In particular:

• Add single line descriptions where missing, and extended descriptions where necessary
• Add arguments sections where missing
• Add examples sections where missing
• Ensure all docs tests are passing

Use the util module documentation (or better) as a target for level of completeness.

To manage nodes better, we want to be able to manage all of the nodes in a network so we can do stuff like share state between the network, gracefully shutdown, etc.

This will be a simple upsampling node that merely injects zeros when upsampling for now.

Currently the graph API is super clunky, requiring locking and such to build the graph. This should be made much easier.

Currently the generated documentation from cargo doc is either incomplete or unreadable. We'd like to improve the documentation to make use of the library easier.

We'd like to support FM: both modulation and demodulation.

Update documentation for the fft module. In particular:

• Add single line descriptions where missing, and extended descriptions where necessary
• Add arguments sections where missing
• Add examples sections where missing
• Ensure all docs tests are passing

Use the util module documentation (or better) as a target for level of completeness.

Consider looking at https://rust-lang-nursery.github.io/mdBook/ for putting together some solid documentation for the library.

As a user of the comms-rs system, I would like to have a radio hardware abstraction layer so that I can use one interface to setup whatever physical hardware I have on hand.

Prior to implementation, as per @Alex-Addy 's suggestion, we should investigate general rustic HAL implementations and see if there are any relevant traits.

For example, the main trait should have the following methods, or method-like abilities:

Radio:
    setup -> initializes any appropriate transfers
    teardown -> cleans up any resources and memory
    [set|get]_center_freq -> sets the center frequency of the radio appropriately for the hardware chain
    [set|get]_samp_rate -> Sets appropriate "bandwidth" to the given number or gets the value
    [set|get]_gain -> Sets/gets the hardware gain
    recv_samples(number, input_idx) -> Gets the number of samples for the given "antenna" or input
    send_samples(samples, output_idx) -> Sends the given samples to the selected "antenna" or output

These should be universal for any kind of radio that we support. Individual implementations could have additional methods for modifying tuning parameters (various IF stages) or gains, but would require the user to have knowledge of the particular hardware platform.

We would like rtl-sdr support as it's a very cheap affordable SDR that people could use.

We would like the ability to plot spectrum and time domain sample data for analysis. We need to assess whether or not we can do this at run-time.

We want a node or set of nodes that can receive the various complex valued symbols output from a modulator and upsample and pulse shape them. We'll keep it simple to start with and only target a couple basic shapes:

• Rectangle pulse shaping
• Root raised cosine (once we have an FIR filter implementation)

Taking a guess this would take the form of a node that receives a Complex value and spits out a vector of Complex. It would also have a couple parameters for things like samples per symbol, and total FIR filter tap length.

Update documentation for the mixer module. In particular:

• Add single line descriptions where missing, and extended descriptions where necessary
• Add arguments sections where missing
• Add examples sections where missing
• Ensure all docs tests are passing

Use the util module documentation (or better) as a target for level of completeness.

Create a prelude that imports all the things that generated nodes need. Make sure to silence unused imports so that the users don't need to worry about it.

Currently the Mixer module only has a sample by sample implementation. This is fine for demo purposes, but the batch mode implementation will be critical for any real world use cases.

Goals:

• Batch mode Mixer implementation
• Tests
• Docs

In order to ensure code quality and test against regressions, we need to set up continuous integration.

Build a tool which can benchmark sample rate throughput for various graphs and machine types

Update documentation for the modulation module. In particular:

• Add single line descriptions where missing, and extended descriptions where necessary
• Add arguments sections where missing
• Add examples sections where missing
• Ensure all docs tests are passing

Use the util module documentation (or better) as a target for level of completeness.

This one isn't 'hard' per se, but it's pretty important. FIR filters are gonna be everywhere in practice, as a minimal thing we'll need a naive implementation so we can do pulse shaping, alias filtering, and matched filtering.

Reference the wiki, but the basic equation is:

Where output signal is y[n], input signal is x[n], and filter taps (coefficients) are b_i.

Later on down the road if/when we end up doing all our batch processing we may want to extend this to do convolution via FFTs as an additional alternative node. FFT based filtering is faster once your number of taps is "large", which iirc in practice is something like 100+ taps. I'm not sure if even rust will be able to do filters that large real time, so I'm not sure if this will be something we want to bother with or not.

Either way, the scope of this issue is limited to the direct form 1 implementation, straightforward and easy. Filter implementation should just take vector of taps as input argument. Filter design is a later problem that can be solved, if it's even necessary. As a user I plan on doing the design outside of rust via Matlab or Scipy, then just grabbing those taps and dropping them into this node.

I'd like the ability to play audio from real samples.

See: https://en.wikipedia.org/wiki/Automatic_dependent_surveillance_%E2%80%93_broadcast

For now support for three specific node types would be nice:

• Some node to do 0 and 1 generation, u8 output
• Uniform random variable node, should support start and stop range parameters for node init()
• Gaussian random variable node, should support mean and standard deviation parameters (mu and sigma)

These would be nice in and of themselves, but they can also serve as very basic node examples for the less rust inclined developers to model their nodes after. As such they should display 'best practice' and whatever that means for our team.

Currently, when producing nodes via the macro, documentation cannot be added to the nodes. The macro should accept docstrings to attach to the macro.

In order to enable the creation of a more rustic API for the BladeRF platform, comms-rs should provide a C interface to the blade RF API with appropriate tests.

Acceptance:

• Minimal viable package created which can emulate libhackrf functionality in rust
• Package has at least one test
• Merge request accepted

Update documentation for the filter module. In particular:

• Add single line descriptions where missing, and extended descriptions where necessary
• Add arguments sections where missing
• Add examples sections where missing
• Ensure all docs tests are passing

Use the util module documentation (or better) as a target for level of completeness.

We need a complex FFT and IFFT node. It needs to support interleaved IQ format in i16.

I think we have the tools necessary to start doing some actually interesting things... we should make a couple examples demonstrating that fact. If it falls out from this that we're missing important things, then great! We'll add those as issues.

Update documentation for the prelude module. In particular:

• Add single line descriptions where missing, and extended descriptions where necessary
• Add arguments sections where missing
• Add examples sections where missing
• Ensure all docs tests are passing

Use the util module documentation (or better) as a target for level of completeness.

A contribution guide should be created and documented in the project so that new developers know how best to provide code to the comms-rs project.

Acceptance:

• Guide created
• Location of guide documented in the README
• Example of workflow documented in the guide demonstrated on GitHub
• Example referenced in guide somewhere

In order to enable the creation of a more rustic API for the HackRF platform, comms-rs should provide a C interface to the libhackrf API with appropriate tests.

Acceptance:

• Minimal viable package created which can emulate libhackrf functionality in rust
• Package has at least one test
• Merge request accepted

This node would be a wrapper for the Radio HAL, but would have intelligence around calling down to the HAL methods based on the streaming/synchronous behavior captured . The node could then be integrated into the graph for execution based on feedback created from other nodes.

Update documentation for the node module. In particular:

• Add single line descriptions where missing, and extended descriptions where necessary
• Add arguments sections where missing
• Add examples sections where missing
• Ensure all docs tests are passing

Use the util module documentation (or better) as a target for level of completeness.

Update documentation for the io module. In particular:

• Add single line descriptions where missing, and extended descriptions where necessary
• Add arguments sections where missing
• Add examples sections where missing
• Ensure all docs tests are passing

Use the util module documentation (or better) as a target for level of completeness.

This is a bit different than the random number generator node. The goal here is to use the standard linear-feedback shift register (LFSR) implementation of a PRNS generator. These are commonly used for communications systems for various things like frequency hopping and spread spectrum waveforms.

It's already basically implemented on the feature/prn branch, and supports LFSRs of size 8, 16, 32, 64, and 128 bits, as well as arbitrary polynomial specification for the generators. Reference for what I'm talking about regarding those polynomials. Crypto and coding theory nerds should recognize that Finite and Galois Field stuff. Note that in my implementation I've flipped around the direction that everything is flowing in that graphic, this is because in my mind bit 0 refers to the right most bit, and bit 15 would be the left most bit in that graphic.

Work remaining on this one is basically getting some decent documentation on the use written up, and some additional comments for the code. I won't bother explaining the operation of the LFSR, and will instead throw a reference into the docs somewhere.