For those of you who don’t know, ANT+ is a wireless networking protocol mostly used by running/cycling/etc sports gear. It was designed by Garmin (actually a company it bought, Dynastream) back when Bluetooth wasn’t nearly as good as it is now. I like ANT+ because it is simple and reliable. It is the kind of thing that was likely written by just one or two core developers, whereas bluetooth is the work of hundreds of people (committees) over two decades to get working well. Bluetooth can do so much more, but most of that more (one-to-many, localization, etc) don’t work on most devices. I like protocols that “just work” and are simple enough it doesn’t take 3000 pages just to cover the spec (looking at you bluetooth).
ANT+ is comparable to an FM radio. Anyone can listen. Of course, unlike FM radio, ANT+ on 2.4 Ghz can only broadcast across one or two rooms.
ANT+ was starting to die a slow death. A few things happened at the same time. The core patents expired, which means Garmin was looking at a much weaker revenue stream from the protocol itself. Secondly, the EU decided to enact a bunch of privacy laws the prevent unencrypted data transfer of personal data. ANT+ is open, heart rate (etc) are technically private data, and must be encrypted. I think this is ridiculous because of how short range the data is. ANT+ on its best days can not travel further than two people can shout, actually usually its less than that. It’s within the world of “it’s private if I want it to be just by staying in my own home”. If anyone can get close enough to sniff your ANT+ packets, they could also just use a fancy thermal camera to read your heart rate.
There are a few things that make ANT+ work saving, beyond just the “its simple and works” argument earlier:
1. The protocol is designed from the ground up for ultra low battery usage. It can run on tiny coin cell batteries for years.
2. The protocol works very well with “one to many” devices. If you need a couple of listeners for the same device, it is very easy to do, and that’s a feature we often want. This is very nice to have on indoor cycling setups (sports watch, tablet, TV can all listen at once). It’s also nice on community gyms where you don’t have to worry about someone else’s device still being paired to equipment there (no unpair/pair dance), just read the device ID and select.
3. It standardized protocols for devices (namely heart rate, power meters, etc) so that any manufacturer could talk to any other manufacturer. This is tough to do well, but really nice when it works.
4. It tends to work better in “noisy” RF environments with lots of devices, because it takes up less air time, so less interference.
A few things it does not do well:
1. Encryption of data. There’s some encryption support but it never got used. I’ve added a fresh take on it, but it would only work between both ends running RadiANT (not just ANT+ spec)
2. It has tiny data packets that don’t get confirmation. For example, it can’t stream audio, not well at least, for example, because that’s big data packets and without confirmation receipt it won’t know to resend lost data (leading to crackle and static). It’s best for lighter, “stateless” data flows where an occasional lost piece is fine (ie you don’t need your heart rate truly 4 times per second, occasionally 3 times per second is plenty).
3. Not built by default into most smartphones. They’ve got the raw radios that could do it, but they don’t expose the software layers to make it work directly.
One think I like about ANT+ is that it can in theory avoid pairing all together. As part of my Aerosense project, I have built ANT+ power meter readings in so that it looks for any open broadcasting power meters and starts grabbing data, if there is one. If there are more than one sensors, it has logic to figure out which one is with you most often, and preferentially pairs. Basically the idea is that the power meter that hangs around you most often, of those available, is probably yours. Pairing a sensor isn’t that hard, but it does annoy me fairly often, I get started on a ride, then have to stop and pair a sensor.
I like ANT+, so I just decided to yolo a custom ANT+ compatible RF library.
Actually no, that’s not what I decided. First, I decided for my Zephyr Aerosense project that I would need ANT+, and wanted an ANT+ test project. I thought a USB ANT+ dongle on an NRF dev board would be an “easy intro”. I was wrong, so wrong that I actually got ANT+ working on the aerodynamics sensor before I could figure out the dongle (with heavy agentic coding assistance). But it was a useful intro to the spec.
The ANT+ dongle was exciting because, mostly thanks to the powers of the NRF52840, it promised to be much better than the 15 year old ANT+ dongles on the market, with higher sensitivity and less packet loss. A “dongle” is how a computer talks to ANT+ devices, particularly for indoor cycling setups like Zwift. Connection issues have long plagued the community, so its a real need.
Updating the dongle makes a lot of sense. It uses an ancient part. Newer parts are much more sensitive, they can better pick up the signals. There is also just newer library logic, and more features on the chips that make for a more reliable, lower latency experience. It also gets past the absolutely tiny, terrible antenna on those dongles. Everything looks better without question.
Next step was realizing that ANT+ is doomed to die, eventually. It looks like Nordic Semi would like to eek out a bit more life from this (it helped make them the defacto chip provider for fitness devices). Garmin uses ANT+ so deeply in their products that they aren’t moving away from it anytime soon. But there is no more real money to be made here, so it’s the end of the line from a corporate perspective.
What do I see here? This is where open source, community work comes in. So I decided to make RadiANT. RadiANT isn’t ANT+. But it is meant to be ANT+ compatible. I also decided to add in a totally different encryption layer, frequency hopping, and some other features for theoretical new device protocols. I see some possible future here for ANT+ compatible radios as a simpler, lower power version of the Matter smart home standard, really aiming at hobbyists who want a simple, still proven radio protocol for sensors and simple devices.
My main rationale for building this is that, after having used both ANT+ and BLE in the wild, and having programmed for both, I genuinely feel ANT+ is better for some needs. I think it is worth saving, especially if we could open it up and make it easy to use. But writing my own radio library stack? That’s really really hard. A year ago I couldn’t have done it. Enter the latest agentic coding. Opus 5 worked through the ANT+ dongle hangups in a way the older Opus models couldn’t, and I thought, well, maybe it can do a full RF library of its own too…
In order to avoid potential legal issues during the build, I needed to avoid parts of the code for which the legal status was unclear. That meant basically only the ANT+ raw spec (in the expired patents and a few released Garmin docs) plus the core device profiles (ie HR) were available. The hardest parts of the RF library are wrapped in a binary lib_ant.a which we can’t read anyway. So the main solution was to use the sdk-ant devices I had already got working, plus real world devices I had, as simulators. Once we know the inputs and outputs, we can figure out our own bridge code to get there. Opus 5 was quite strict on this, with minimal prompting it setup ‘clean room’ policies for itself to avoid the licensed material, and clearly avoided it during coding sessions. I also specifically requested Opus to do aim to do better, with ANT code built around a core that’s 20 years old, it does seem reasonable that there new and improved techniques to use for RF.
Coding was Opus 5 running for a week, given 5 dev boards to test back and forth on. In case you were wondering what the picture of the laptop in the dark with green dots around it, that is the glow of the leds from each separately attached dev board.
For innovation, I think the most interesting thing I added here is the RadiANT to Matter forwarding. The idea here is that an indoor fitness device (trainer, treadmill) or even an HR monitor can be used for smart home integration. BLE pairing doesn’t work for this case because users usually want to have that data passing to their smart watch (etc). So we can get an occupancy sensor that is basically “treadmill in use” or “heart rate monitor in higher zone” and use that to do things like crank down the AC or turn on a smart fan. Another potential use case is a commercial gym being able to keep an occupancy dashboard so users can know “7 of 8 treadmills are occupied” live. Right now an ANT+ dongle can be setup to serve as both an ANT+ dongle and a Thread forwarding radio (being picked up by a standard Thread/Matter router). It will also to be able to forward temperature data from ANT+ devices.
For convenience I also built some “manufacturer ready” examples, a BLE/RadiANT HR monitor and a treadmill. This is an easy to use Zephyr module, ready to import. My hope is that manufacturers, probably not the big names, but at least white label manufacturers will be able to take this and upgrade their products easily, keeping the Radi(ANT+) ecosystem strong.
Support is primarily aimed at the NRF52840, the NRF5340, and the NRF54L15, all of which were tested here fully. To prove out this works on other chip vendors, support for the CC2652 is implemented but is not as well proven out for BLE and Thread coexistence. Adding new chips isn’t easy, as brands all have their own proprietary radio libraries, and some don’t expose those libraries at all.
Not everything is done. Plenty of device profiles are not implemented. Windows Drivers likely need a better long term solution (there are some options here, but I haven’t bothered to implement yet, as what exists should work fine for now).
Check out the project: https://github.com/winedarksea/RadiANT
Colin Catlin, 2026