Skip to content
This repository has been archived by the owner on Aug 11, 2022. It is now read-only.

milestones

Jump to bottom
Michael Hirsch edited this page Nov 14, 2016 · 2 revisions

Please feel free to edit. I have broken these out by category to help team parallelization.

RF Signal Generation and Reception (getting signal to/from ionosphere)

GNU Radio is a possible software solution. Consider the imminent need to have transmit and receive referenced to 1 PPS from GPS. GNU Radio is an easier way to access the FPGA, ADC and DAC

  1. Transmit a pseudorandom continuous phase modulated waveform with 100 kHz bandwidth centered at 3.7 MHz
  2. Receive this waveform at 3.7 MHz with 100 kHz bandwidth, DDC to complex baseband format.
  3. Determine what sort of RF switching if any is needed.
  4. Generate simple metric of data bandwidth vs. SNR and bandwidth in AWGN (should reasonably match theory)

Data recording (saving signals for short & long term)

  1. assuming we'll use USB hard drives with powered USB hub--is there any issue with this? What format to use on hard drives?
  2. Record complex baseband signal to external hard drive in https://github.com/ryanvolz/digital_rf format

FPGA timing track (sending/receiving the signals with accurate timing):

Note that this part has to work well or the rest of the radar doesn't work -- this is key project-wide blocker

  1. figure out how to use 1 PPS to trigger noise sequence transmission.
  2. trigger receiver off of 1 PPS or mark receive samples with 1 PPS ticks

Processing track (working with signals on node):

PC <- Ethernet <- Red Pitaya : is easier to prototype.

Raspberry Pi 3 <- Ethernet <- Red Pitaya : may be necessary if Red Pitaya CPU isn't powerful enough for onboard processing. Raspberry Pi network benchmarks point to the Raspberry Pi 3 having adequate Ethernet bandwidth for a 1 MHz dual-channel ADC stream.

  1. working with already recorded data and http://www.atmos-meas-tech.net/9/829/2016/ what can we process onboard the Red Pitaya given limited CPU/RAM? Can we obtain this already recorded data? Just one or two examples is all we need.
  2. a first data reduction step is tagging obviously interesting data. Let's discuss with Juha et al about what are obviously interesting metrics. This data can then be flagged for long-term retention or priority over-the-air download or alerting.

Future (the radar has to work first)

Filter track (cleaning up the signal):

to meet regulatory constraints and as good engineering practice, we filter the output

  1. the Red Pitaya (or other transmitter) will have 10 - 100 mW of power in the 1-10 MHz range. How can we low pass filter this signal
  2. does the Red Pitaya make in-band noise (adjacent to desired signal)? If so, can we shape or predistort the waveform to not bother neighboring users of the spectrum?

Network track (getting data to/from nodes):

These tests might be accomplished with iperf and a packet-loss simulator, even in loopback.

  1. find/test off-the-shelf network algorithms, simulating high packet loss and latency https://openmesh.wordpress.com/2011/01/30/a-list-of-open-source-ad-hoc-network-and-routing-protocolsplatforms/
  2. find off the shelf algorithm for connecting mesh-network to Amazon AWS
  3. with your chosen method, verify at what data throughput it will break down for 2-hop scenario
  4. update system expectations/specifications based on those results
  5. document/verify it's easy to add new nodes, and that system doesn't collapse if alternate path is available.

Testing guidelines

After first unit is proven, build second/third units for field test

  1. Initial deployment to other site(s) (Haystack, UNH) for data throughput vs. ionospheric conditions testing. Attempt ionospheric radar.
  2. Based on measured data throughput and radar, update specifications/expectations for overall system.
Clone this wiki locally