Ham radio applications for detection of extremely weak signals

Hi!

I’m excited to get started with this very impressive little card. I looked up the specs, and the first time a Teraflop was available was 1997 for the low low cost of USD$46M. Only 850kW needed to run (Plus air conditioning) and a meagre 1600 sqft footprint.
https://en.wikipedia.org/wiki/ASCI_Red

Anyway, My interests lie in processing audio which is downconverted RF information, looking for morse code and similar On/Off keying signals below the noise. There is a lot of general purpose DSP ware out there for hams but it all seems much more “wideband” than I am looking for. My desired system bandwidth is 100 to 200Hz at most.

I have a front end up and running that downconverts the RF to 1kHz.

I do notice there’s no audio input on this board, but there are pins for I2S
https://www.jetsonhacks.com/nvidia-jetson-nano-j41-header-pinout/

Down the road, I have a candidate ADC in mind, but for now I’d love to get a pointer or two on some audio input modules compatible with the Jetson. High ENOB, low noise, and high sample rates are all pluses.

So, what’s the easiest way to get quiet and clean audio into this thing?

Far from being an answer, but if the conversion is already to digital before reaching the Nano, then USB. Serial UART would be ok if speed does not get in the way, and for lower audio frequencies this probably isn’t an issue, but then you are likely getting a serial USB UART anyway. Any kind of ADC you get which connects to the Nano over USB and which has a driver available in Linux is probably a good choice (this would skip using the Nano’s serial UART and either provide its own serial UART or some other interface). If this is already analog audio, then I don’t know.

Btw, if you consider 44.1KHz sample (audio to 22.05KHz) with 8-bit, then this is a bit over 352Kbit/s. Serial UARTs typically never have an issue up through 115200 bps, and if some slight sanity is taken in the design, then a speed just past the 352Kbit/s is not hard to achieve, but support for such speeds may be non-standard among devices running faster. Morse code key rates will be much slower than this, so I’m guessing you could easily detect a carrier off/on even with a fast Extra class with 115200. But why limit it? If you have a USB device with a driver not limited to a serial UART (sorry, I don’t know of a specific example), then you might as well allow audio as well. If not, then an ADC which has its own integrated serial USB UART would be the way to go since this is something basically certified to work at the speeds you are interested in.

The conversion at this point, is to a low level signal centered on 1kHz.
Typical morse rates have on times for a “dot” from about 50mS on out past 200mS

I assume this is doing something similar to FFT on a digital PCM stream. The question is how much processing or refinement is being done on the signal prior to reaching the Jetson.

A serial UART would have no trouble with a 1KHz stream, but may not be close enough to “isochronous” if the stream itself is analog, or if the digital data has to arrive with tight timing specs. USB devices have a mode called “isochronous” which is used with microphones, video devices, and devices which need to reserve bandwidth and never lose timing. Isochronous does not necessarily reserve all bandwidth, and thus other devices can operate, but other devices take a lower priority. My thought on a USB ADC is that the transfer mode would take care of a lot of timing issues. Low requirements at 1KHz could make an ordinary serial UART work for the job, but if you have something with built in USB, then it might already be set up for “better timing behavior”.

Incidentally, this is also why i2s exists. I2s is isochronous, and may be able to handle more “channels” (not needed for your case) by cutting down the resolution. The i2s is a good choice if the processing is actually producing i2s before reaching the Jetson. See:
https://en.wikipedia.org/wiki/I%C2%B2S

Unless the chip involved is actually an audio chip and not just an ADC i2s is probably not a suitable format.

There are some I2S ADCs that I could use.

For now, I’d be happy with some known sound card that works on the Jetson (pi compatible?) without too much complexity in installing drivers etc.

Fortunately for me, PC sound cards have been aggressively optimized in ways that help me.

So what’s the least hassle I2S audio input for the Jetson?

Hello!

Yes you most certainly can use I2S to interface to an audio codec. I do recommend that when selecting an audio codec that …

  1. There is a Linux driver available
  2. There are good examples available for configuring and using the codec. Typically the hardest part of using an audio codec is configuring the route within the codec and configuring any settings for filters, gains, etc. This is the part I see most people struggle with.

That said so codecs that I have seen people use successfully are …

  1. SGTL5000

  2. Realtek codecs including RT5640 and RT5658

    • The RT5640 is used on the older Jetson TK1
    • The RT5658 is used on the Jetson Xavier platform and we have tested with Nano
    • I see a few people using various other RT56xx codecs with Jetson on the forum as well.
  3. MAX98090

  4. TI TLV320AIC32x4

Using any of the codecs require …

  1. Updating the pinmux for the 40-pin expansion header [0]
  2. Updating the device-tree to enable the codec and reconfigure the Tegra soundcard for the codec
  3. Updating the Tegra audio machine driver to do any necessary initialisation for the codec (eg. setup clocks, etc).

The fe-pi audio board is pretty easy to use and changes for the machine driver (step 3) are already
in place.

There have been a few discussions on the forum about I2S audio on Nano and there are more details here [1].

Regards,
Jon

[0] https://devtalk.nvidia.com/default/topic/1051776/jetson-nano/enabling-i2s-audio-output-on-40-pin-connector/
[1] https://devtalk.nvidia.com/default/topic/1052068/jetson-nano/nano-compatible-i2s-soundcard/1