Open IP over VHF/UHF 1

I’ve recently done a lot of work on the Codec 2 FSK modem, here is the new README_fsk. It now works at lower SNRs, has been refactored, and is supported by a suite of automated tests.

There is some exciting work going on with Codec 2 modems and VHF/UHF IP links using TAP/TUN (thanks Tomas and Jeroen) – a Linux technology for building IP links from user space “data pumps” – like the Codec 2 modems.

My initial goal for this work is a “100 kbit/s IP link” for VHF/UHF using Codec 2 modems and SDR. One application is moving Ham Radio data past the 1995-era “9600 bits/s data port” paradigm to real time IP.

I’m also interested in IP over TV Whitespace (spare VHF/UHF spectrum) for emergency and developing world applications. I’m a judge for developing world IT grants and the “last 100km” problem comes up again and again. This solution requires just a Raspberry Pi and RTLSDR. At these frequencies antennas could be simply fabricated from wire (cut for the frequency of operation), and soldered directly to the Pi.

Results and Link Budget

As a first step, I’ve taken another look at using RpiTx for FSK, this time at VHF and starting at a modest 10 kbits/s. Over the weekend I performed some Minimum Detectable Signal (MDS) tests and confirmed the 2FSK modem built with RpiTx, a RTL-SDR, and the Codec 2 modem is right on theory at 10 kbits/s, with a MDS of -120dBm.

Putting this in context, a UHF signal has a path loss of 125dB over 100km. So if you have a line of site path, a 10mW (10dBm) signal will be 10-125 = -115dBm at your receiver (assuming basic 0dBi antennas). As -115dBm is greater than the -120dBm MDS, this means your data will be received error free (especially when we add forward error correction). We have sufficient “link margin” and the “link” is closed.

While our 10 kbits/s starting point doesn’t sound like much – even at that rate we get to send 10000*3600*24/8/140 = 771,000 140 byte text messages each day to another station on your horizon. That’s a lot of connectivity in an emergency or when the alternative where you live is nothing.

Method

I’m using the GitHub PR as a logbook for the work, I quite like GitHub and Markdown. This weekends MDS experiments start here.

I had the usual fun and games with attenuating the Rx signal from the Pi down to -120dBm. The transmit signal tries hard to leak around the attenuators via a RF path. I moved the unshielded Pi into another room, and built a “plastic bag and aluminium foil” Faraday cage which worked really well:


These are complex systems and many things can go wrong. Are your Tx/Rx sample clocks close enough? Is your rx signal clipping? Is the gain of your radio sufficient to reduce quantisation noise? Bug in your modem code? DC line in your RTLSDR signal? Loose SMA connector?

I’ve learnt the hard way to test very carefully at each step. First, I run off air samples through a non-real time modem Octave simulation to visualise what’s going on inside the modem. A software oscilloscope.

An Over the Cable (OTC) test is essential before trying Over the Air (OTA) as it gives you a controlled environment to spot issues. MDS tests that measure the Bit error Rate (BER) are also excellent, they effectively absorb every factor in the system and give you an overall score (the Bit Error Rate) you can compare to theory.

Spectral Purity

Here is the spectrum of the FSK signal for a …01010… sequence at 100 kbit/s, at two resolution bandwidths:

The Tx power is about 10dBm, this plot is after some attenuation. I haven’t carefully checked the spurious levels, but the above looks like around -40dBc (off a low 10mW EIRP) over this 1MHz span. If I am reading the Australian regulations correctly (Section 7A of the Amateur LCD) the requirement is 43+10log(P) = 43+10log10(0.01) = 23dBc, so we appear to pass.

Conclusion

This is “extreme open source”. The transmitter is software, the modem is software. All open source and free as in beer and speech. No chipsets or application specific radio hardware – just some CPU cycles and a down converter supplied by the Pi and RTLSDR. The only limits are those of physics – which we have reached with the MDS tests.

Reading Further

Open IP over VHF/UHF 2 – Next post in this series
Pi Radio IP – Current GitHub Repo for this work
FSK modem support for TAP/TUN – Early GitHub PR for this work
Testing a RTL-SDR with FSK on HF
High Speed Balloon Data Links
Codec 2 FSK modem README – includes lots of links and sample applications.

19 thoughts on “Open IP over VHF/UHF 1”

  1. Just curious about rpitx, is this in theory also possible with other similar SOCs, or is there some special magic inside the bcm silicon?

    Just asking because bcm is known not to sell those SOC to anyone but rpi, so no chance for customised HW (if ever that makes sense anyhow). Probably in the long term some STM32MP1 or atmel/microchip SOC would be more tinker friendly, but first of all it’s impressive what can be achieved with HW for a couple of 10$! Hats off!

    1. Good questions Diego. I’m not sure, as I’m new to technology used in RpiTx.

      However there are many other low cost PLL based FSK chips out there that could be used instead for a few $.

      I have looked at the PLL outputs from some stm32 chip but they were quite noisy at UHF, might be usable at HF.

      1. Those RF chips tend to be on a fading nowadays, just remember the good old Motorola chips like MC2833, MC3362 and tons of others, all gone.

        So using general purpose MCUs is a really cool concept. Would be great if it’s not confined to one vendor only, and would also be great if there would be hand solderable samples as well (something like i.e. an Allwinner V3s), bga in the toaster oven sounds like a mess to me 😉

    2. There’s nothing super magical about it, the Pi is just ubiquitous enough to have attracted this kind of development. Basically all it needs is a PWM peripheral clocked by a PLL that’s capable of reaching the frequency of interest, and the ability to do fast updates to the PWM using DMA.

      Without actually checking, I would guess that a lot of GHz-class ARMs are capable of the same thing. (slower chips like SAM3 are lacking a PLL that goes high enough to do VHF/UHF PWM with any reasonable resolution).

  2. I think using these frequencies VHF/UHF for this scope is illegal in most of the countries since they are reserved for tv broadcast .

    Be careful …

      1. The question isn’t can a licensed Amateur transmit, it’s is the data rate and transmitted spectrum legal.
        For example in the US, 97.305, the (2), (5) , and (8) corresponding to 97.307(f).

        It may be legal in some countries, but not all.

    2. The topic is amateur radio, which is a licensed service with reserved frequency bands. Not how to build a TV band bug transmitter.

    1. The hot ticket (I think) would be to use the NPR design, and leave off the radio chip. Build a daughter-board to take it’s place and transmit where ever you want (not just ISM bands).

      The advantage here, being the IPV4 out of the box, and skipping over all that AX.25 bo-jive from the 20th Century. (grin)

      I think 12 Watts is a good target using SSB (good range, and keep the TXD preamble short..

      1. I think the SI RF4463F30 can be tuned from 142-1050 MHz.

        That’s a broad frequency range and it’s a useful versatile chip. Just need different filters.

    2. I’m Guillaume F4HDK, the inventor of the “New Packet Radio” solution.
      I confirm that NPR70 already makes all you expect : bi directional IP links, with fast TX/RX switching, dynamic time slot allocation, 100kb/s or more, Timing Advance management, etc… The frequency is not restricted to ISM, of course! With the standard 70cm module you can go from 420 to 450MHz. And with modified modules, you can go on other RF bands. Finally, you can get 20W of RF power with a standard DMR amplifier.
      https://hackaday.io/project/164092
      If you have question about my project, feel free to ask.

      1. Hi Guillaume – that’s a great project you have there, well done! I am reading the web site.

        Have you done any measurements on sensitivity or packet error rate? We might be able to help you with FEC as well.

        The radio chipsets work well but in general the modems aren’t optimal and it can be difficult to tune the physical layer at they are “black box” closed hardware. For example the Si4463 datasheet suggests a Rx sensitivity of -106dBm at 100 kbit/s, the theory is:

        MDS = Eb/No+10log10(BitRate)-174 = -117dBm.

        We have done the maths and Eb/No = 7dB (with a good FEC code) is enough for a low PER link. So with 2W you could get the same performance as 20W …. or increase your bit rate by a factor of 10!

        Hmm, I wonder if we can put your upper protocol layers on top of our modem/FEC?

        1. Hi David,
          The sensitivity measurements of NPR70 are at the end of the document “advanced user guide” inside my website
          https://hackaday.io/project/164092
          We do use external VR-P25D power amplifiers, and they do have an internal RX preamplifier which improves greatly the sensitivity. But even with it, it’s not perfect.
          I know the FEC of NPR70 is far from perfect… why not getting some help about it.
          About putting upper layers of NPR70 inside “your modem”, do you mean the M17 one ? Or something else?
          Maybe we could continue the discussion in a more convenient place: by e-mail (f4hdk [at] free [dot] fr), or in the M17 forum, or the NPR70 tchat ( https://hackaday.io/messages/room/279145 ) ?

  4. Mate,
    I would happily pay reasonable amount $10-50 AUD to have a PDF book that gives step by step guide that outlines something like – buy this kit/antenna and download this software/configuration; I know hacks/funs reading a guide but I am coming from a software background and lack the necessary skill in SDR space/hardware.

    1. Yes that’s the plan – get this packaged up somehow so anyone can set up a low cost IP link, build simple antennas, align and debug the link.

      I’ve put a skeleton milestone list on the project README

      Patreon is a useful way to sponsor this work.

  5. I would look at Orthogonal Frequency Division Multiplexing (OFDM) it is a frequency multiplexing technique that has gained considerable attention the past few years.


    1. Thanks AD0WQ – I edited your comment for brevity. Yes, I am familiar with OFDM – pls see codec2/README_ofdm.md

Comments are closed.