QMESH: LoRa Mesh Networked Voice Communications

LoRa is great for sending short data packets over long ranges but is not normally suitable for voice communications. [Dan Fay] is looking to change this with QMesh, a synchronized, flooded mesh network protocol for ham radio applications.

In a flooded mesh network every node repeats every message it receives. This has the theoretical advantage of making the network self-healing if a single node stops working, but often just means that the nodes will interfere with each other. Thanks to some characteristics of LoRa, [Dan] is using several tricks to get around this packet collision problem. LoRa network can make use of the “capture effect”, which allows a receiver to differentiate between two packets if the power level difference is large enough. This is further improved by adding forward error correction and slightly changing the frequency and timing of the LoRa chirps. QMesh also implements TDMA (Time Division Multiple Access) by splitting transmission into time slots, and only transmitting every third slot. This means it is operating on a 33% duty cycle, which is much higher than the 0.1%-10% allowed on license-free ISM-bands, which legally limits it to the ham bands.

On the hardware side, [Dan] has been using the STM32 NUCLEO-144 development boards with F4/L4/F7/H7 microcontrollers and a custom shield with a 1 W LoRa module and OLED screen. While [Dan] wants to eventually build handheld radios, he plans to first develop small FM repeaters that encode voice as codec2 and use QMesh as a backhaul. QMesh is still under development, but we would love to see the results of some long-range testing, and we are excited to see how it matures.

If your interested in a more basic LoRa-based human-to-human messaging system, take a look at Meshtastic. It’s been going very rapidly over the past year. To learn more about LoRa and other digital modulation schemes, check out the crash course we did with an SDR a while back.

31 thoughts on “QMESH: LoRa Mesh Networked Voice Communications

      1. That’s why I say make it and release it to the masses. It’s kind of like the Napster effect – if it’s illegal – come and get me. Make the software that could handle it and release it. We all know how making a program illegal to run on your computer turns out. It could be as simple as sending small .ZIP packets with a keyword to unpack them. Utilizing uuencode/uudecode is another thought that comes to mind. It wouldn’t be long and people would interface it to their computers and let emailing send the data packets around. Illegal yes, but stoppable and prosecutable? I guess we’d find out.

      2. In the US at least, you can do full encryption on the ISM bands (915MHz, 2.4GHz, 5GHz, etc.). You can’t encrypt on the amateur bands (or on the ISM bands as a radio amateur), but you can cryptographically sign your messages. I’ve pondered replacing the CRC checksum on the QMesh frames with something like a SHA256 HMAC as a way to keep unauthorized users off a QMesh network.

        In the case of QMesh, it wouldn’t be hard to add encryption for use as an ISM 915MHz device (or even with 2.4GHz LoRa), but to make it robust to packet loss, you’d probably want to have a full IV in each packet, which can add significant overhead. Of course, there is a tradespace of security vs. robustness vs. overhead with different sized IV’s or using non-AES encryption algorithms with smaller block sizes like Simon and Speck (https://csrc.nist.gov/csrc/media/events/lightweight-cryptography-workshop-2015/documents/papers/session1-shors-paper.pdf). You could also have an IV that is based off of a shared, changing state like a highly-accurate, GPS-synchronized time.

          1. I believe the rule as I know it, states you can’t use encrypt or other methods to obscure the meaning of a message.

            So commonly used “codes” are ok (ie: 73, CQ), but if you and your buddy want to develop a code word system to hide what you were saying, they could go after you.

            At least that is what I learned when I got my HAM license 10 years ago. Correct me if I’m wrong.

          2. tl;dr version: if you want encryption, stick with Part 15/ISM rules. If you want high power and unrestricted transmit time, stick with non-opaque transmissions a third party can trivially read. Oh, and it’s REALLY easy for professional equipment to automatically localize a VHF-or-higher transmitter down to the foot, if there’s a reason to do so.

            For US amateur radio, whatever you transmit over the air has to be publicly documented well enough that any interested listener can intercept and fully decode it.

            For standard or “well-known” protocols, it’s assumed that anyone who is interested is informed of the specification. As long as the protocol takes steps to meet the periodic callsign inclusion requirements, it’s all good.

            But for the rest, you have to use some common or standardized method of identifying the sender callsign and ensuring that any third party can find out about the spec. For example, every 10 minutes, use morse, rtty, etc to transmit callsign and spec info. Anyone interested in decoding the rest now knows the (legally mandatory) responsible party, and has something to search for on the internet to learn how to decode it.

            And, under no conditions may an amateur transmission include opaque or non-decodable data.

            Industrial-scientific-medical transmissions, or other Part 15 transmissions are not restricted as to content. The original intent of ISM was to ease compliance for microwave oven makers, induction heaters, and various very old medical rf devices. So, noise is ok, but it’s also lawful to transmit meaningfully intelligible signals too.

            Part 15 transmitters have to pay attention to a bunch of band-specific rules. In the non-ISM bands, this includes really vicious power output and/or antenna restrictions. The ISM bands, on the other hand, allow significant power even for Part 15 transmitters.

            Part 15 does have other annoying restrictions, such as being required not to cause interference to other users of the frequency (who may be actual licensees, who always have priority and a right to ask the FCC to track down and stop the interference).

            The last serious restriction is that most Part 15 bands have strict limitations on the ratio of transmit vs idle. The details are a bit band-specific, but generally, no one transmission can be very many seconds long, and the gaps between transmissions must be many times the duration of the last transmission. Once again, the specific regulatory requirement varies per band.

            If you start causing significant interference to a utility company or other professional user, they’ll usually just send one of their engineers to find the source of the interference and, if it’s accessible, remove it. If it’s on private property they cannot reach, they might attempt to contact you or may just file an interference complaint with the FCC. Since most utility monitoring does legally count as safety-of-life critical, the FCC tends to actually deal with these, fairly promptly, unlike the average interference complaint.

            The tinfoil hat crowd (or people wanting to use this kind of stuff in protests, especially against repressive regimes) should be aware that, if anyone has more than a passing interest, it’s trivial (and cheap) to precisely localize any RF emitter. Any regime interested in being repressive is well-equipped to locate and identify transmitters, and send some jackboots to “insist” that the responsible party help them understand the message…

            It’s even easier to simply jam them, if it’s more useful to interfere with the message than to stop the sender.

            Other countries have their own regulatory rules, some of which aren’t even slightly similar to US rules. And, of course, a random post on the internet can only give you a start for your own due diligence. I’m not a lawyer, I didn’t take your money to give this answer, and you can’t even prove I’m human. Arf.

        1. You might get some good ideas about encryption over lossy channels from peeking at Datagram Transport Layer Security. Most of it isn’t really relevant, or would actually be counterproductive for your purposes, but it’s at least adjacent to your usage case.

          And, if you treat a mesh as a lossy, reordering channel, it avoids the need for each mesh node to spend the resources to fully decrypt and validate each packet before forwarding. Still a good idea to have some kind of cheap validating signature wrapped around the crypto payload, just to avoid wasting airtime forwarding obviously corrupted packets. To the final destination, the packet stream would be a lossy, potentially reordering, potentially duplicating message channel, which is very close to what DTLS was written for. Incidentally, postcards-via-snailmail is a very similar message channel, if you scale the timeouts appropriately ;)

    1. I dunno. If, say, RTTY was encrypted, I would have never become an SWL or a radio amateur in first place. Listening to conversations of strangers is one of the most fascinating things, I think. The dedication they put into their hobby is inspiring and makes people want to join them. Just think of it, please. :)

      1. The goal of this and similar project is not related to Ham Radio.
        I also enjoy listening to communications, especially if it’s through one of my diy receivers, and learnt a lot from doing so in the past thanks to them being open. Devices like that one serve different purposes however: when governments embrace the dark side (which seems to happen very often) they would help people to communicate securely and organize.
        Of course it is illegal, but in those situations everything becomes illegal if it can’t be controlled by governments. Every revolution is declared illegal by the evil king, but that doesn’t make them less necessary when bad times come.
        The objective therefore is not to have idiots trolling the airwaves in normal times (which is what most kids often do with their €25 Baofengs) but to have a tool ready to be used when things go really bad and your freedom could depend on it.

        1. The important thing is to figure out how to develop a system that is practical to test, even if the legal version is of limited usefulness.

          It really sucks to discover the bugs AFTER the zombies emerge. But all the really USEFUL tools cause too many disruptions for normal times, so it’s good to design something that can be a good neighbor during testing, but switches to being useful during an apocalypse. Hey, it’s a good excuse for yet another Big Red Button, so it’s not ALL bad!

          It’s not just the authorities that might have an opinion about your testing. If you start interfering with some utility’s normal infrastructure monitoring, they won’t be amused. And, if you’re doing it in a manner that’s clearly in violation of the regulations, it’s much easier for, say, a gas line company to call up the FCC and complain about serious hazards occurring because some moron is causing harmful interference, and actually get the FCC’s attention.

          Sure, technically, they’re probably also operating as a Part 15 user, meaning they’re not protected against interference from other Part 15 users… but if the FCC ignores the complaint and someone dies, careers are going to get ended and people will be going to jail.

    1. So the big thing that I’m trying to do with QMesh vs. other mesh protocols out there is to have a mesh network that can provide isochronous bandwidth that you can use to stream stuff like voice. I haven’t seen any other commodity hardware-based mesh networks that can do this, though it looks like Beartooth is getting close (I can’t locate the paper right now, but I think they published something about a year ago about it).

  1. I do not se any calculation on how much the time delay there is going to be between a packet going in and then out into the ether again. I.E. how many ms. is it going to take for a voice to pass between 10 nodes?

    1. Hi Emil —

      I’ve spent a lot of time wrestling with the latency tradeoffs. Codec2 (as well as Google Lyra and I think AMBE and IMBE) have frames that are a minimum of 40ms in length. Right now, I’m thinking that each QMesh frame should be around 160ms (so four frames) in length. Yes, it adds significant latency with lots of hops, but it’s more bearable with push-to-talk voice (some trunked P25 systems seem to have 500-700ms of latency baked into them).

      And yeah, 10 hops would be a *lot* of hops. I’ve seen claims that routed mesh network protocols become intractable after about 6 hops.

    1. Codec2 has been implemented on a 168MHz STM32F4 with the SM1000 box that runs FreeDV:

      https://github.com/drowe67/codec2/blob/master/stm32/doc/sm1000_manual.md

      As for me — I’ve put implementing codec2 on the MCU on the backburner in favor of making the QMesh nodes KISS-compatible TNCs. My change of heart came from a few things:

      1. The KISS protocol is used by a lot of different amateur packet radio programs, including APRSDroid. If I use a Bluetooth-to-UART bridge like the HC-05, I can have APRSDroid running on my phone connect to a QMesh board over Bluetooth, and APRSDroid just works and will send/receive KISS frames over QMesh.

      2. The development of the Codec2 Walkie Talkie Android app (https://github.com/sh123/codec2_talkie/) means that all you need to successfully stream Codec2-coded voice is a KISS-compatible TNC. IIRC, the creator of PicoAPRS demonstrated streaming Codec2 voice over APRS using this app.

      3. Google recently released the Lyra vocoder (https://github.com/google/lyra). It uses neural networks to get really, really good audio quality in ~3Kbps of bandwidth (LPCNet is another NN-based vocoder that gives similar awesome results). Getting this to work with QMesh would make QMesh really compelling as a PTT voice system. Caveat is that the compute requirements are too high for any microcontroller out there. You basically need a smartphone for it to work in real time.

      1. “Getting this to work with QMesh would make QMesh really compelling as a PTT voice system. Caveat is that the compute requirements are too high for any microcontroller out there. You basically need a smartphone for it to work in real time.”

        Nothing wrong using a smartphone to encode/decode/compress the audio, then using QMesh LoRa as the transport medium. As an example with Meshtastic, currently an Android APK on a smartphone is used for sending and receiving text messages using LoRa. So using QMesh LoRa as a transport medium, and smartphone to encode/decode and optimized audio using Lyra vocode would be perfect. After all, a device is required for the PTT. Just a thought. :0)

  2. We just tried these LoRa flooded mesh walkie talkies in the office yesterday: https://m.alibaba.com/product/1600709442005/2023-Mytetra-MYT-DM207-Digital-Walkie.html

    We verified that the power was about 7 watts, 30 percent duty cycle. There’s a simple two stage amplifier inside. The 2nd harmonic is ridiculously loud, but likely less than -20dBc.

    The flood retransmissions don’t occur close in. I had to remove the antennas in order to see the retransmission, so they are likely using RSSI to gate retransmissions.

    Architecturally, this system can’t work when relay units are collocated, due to self-interference.

Leave a Reply to ytrewqCancel reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.