New CODEC work

[Bruce Perens]

Some recent ham radio digital voice CODEC development which I have guided the AI through:

AMBE for all ham radio modes except System Fusion: D*STAR, DMR, NXDN, etc., with the AMBE-2+ modes compiled out by default until some patents expire in another 3 years. 0.97 or better compliance validated against an AMBE 3030 chip (1.0 is best) when in chip-compatible mode, non-chip-compatible is the default and handles bad packets without squeaking and doesn't emulate chip bugs. Also IMBE for Project 25 phase 1. Both floating and fixed-point implementations in Rust:

https://github.com/BrucePerens/hams_open/tree/main/daemons/ham_digital_modes/src/ambe

Codec2 In fixed-point Rust, 0.9999 compliance with the float C version:

https://github.com/BrucePerens/hams_open/tree/main/daemons/ham_digital_modes/src/codec2_3200

1600: https://github.com/BrucePerens/hams_open/tree/main/daemons/ham_digital_modes/src/codec2_1600

C API for 3200 Rust, we can extend this for 1600: https://github.com/BrucePerens/hams_open/tree/main/daemons/codec2_3200_capi

Next: try to make a non-machine-learning version of RADE. It probably won't sound as good but might be close enough to be compatible.

[Ed Marciniak]

One thing that would really help with adoption of codec2 would be to make it compile with an Arduino 1.8.2+ for PJRC teensy, and the Raspberry pi pico ecosystem. It seems to me someone ported it to run on some nordic nRF, but that’s of no help. I believe the holdup has to do with CMSIS last time I looked.

In the case of the Teensy 3.5/3.6/4.0/4.1, a bonus would be creating audio sinks/sources compatible with their audio designer tool. This potentially has application in something like Twinkle, a ZRTP capable SIP phone client  if a null codec passes the bitstreams to a USB device (with or without a headset jack))….from a security perspective if the USB device only allows one connection, and the audio isn’t part of the audio subsystem, it takes away an opportunity to intercept audio after decryption or before encryption on a ZRTP secured call.

This would also have the advantage of making it possible to build a serial to AMBE on a stick device with no audio codec, perhaps allowing transcoding from Dstar to/from fusion or monitoring P25 traffic from an SDR.

If someone is seriously interested in tackling adding clear instructions for installing dependencies and/or conditional compile for Teensy, I’d be willing to send them a Teensy 4.x plus audio codec board. If it doesn’t create a shipping headache, I can include a cheap headset that will plug in. I’ll pay shipping and if applicable, tariffs.

If someone’s already done it on Teensy or RPi Pico, please let me know.

---

From: 'Bruce Perens' via digitalvoice <digita...@googlegroups.com>
Sent: Sunday, 20 September 2026 15:52:43
To: digitalvoice <digita...@googlegroups.com>
Subject: [digitalvoice] New CODEC work

 

--
You received this message because you are subscribed to the Google Groups "digitalvoice" group.
To unsubscribe from this group and stop receiving emails from it, send an email to digitalvoice...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/digitalvoice/53f61d4f-ecb9-458f-ab3c-83599a38b8fdn%40googlegroups.com.

[Bruce Perens]

I did some work to put it on ESP-32 today that would probably apply to
those platforms. It goes down to 32 bit fixed point arithmetic and
no_std (Rust without the standard library) and has lots of CPU budget
left over for little embedded processors. I'm not interested in
encryption, sorry. I think I have a Pi Pico and some STM-32 platforms
around here, but can't promise when I would get to them.

Thanks

Bruce

> To view this discussion visit https://groups.google.com/d/msgid/digitalvoice/DS0PR15MB5697031A2A6C6074717D0C68FD852%40DS0PR15MB5697.namprd15.prod.outlook.com.



--
Bruce Perens K6BP

[Ed Marciniak]

The Teensy is Cortex-M7 with single precision FP(600-700mhz).

The RP2350 is cortex-M33 also with hardware single precision, but much lower clock speed (150 MHz dual core).  I just stumbled across a meshtastic related repository for that with codec2 support but haven’t dug deeper. I know from power measurements that an RPi pico 2 can idle at 80-85 milliwatts depending on whether an LED is on or not.

I missed stumbling upon that because the repository might only be 2 weeks old and I didn’t expect it

https://github.com/meshtastic/codec2

The dual core RP2350 could be interesting in running codec2 on one core and the modem on the other. The hardware might be small enough to fit inside a hand microphone housing.

No worries about a lack of interest in encryption. I was just thinking about some interesting ideas.

One thing that’s really interesting with ridiculously low bit rates is that one could interleave the current output packet concatenated with a copy of the previous packet and the previous previous packet, allowing 66% or 75% packet loss at the price of 60-80 

ms latency, while dispensing with RTP/RTSP and similar. 

With creativity, perhaps while packet loss is low, the latency disappears, if loss is moderate you could play one or more frames behind…and roll the dice statistically to play a word 20*n late and eat 20ms increments  of jitter at a word boundary…or proportionally more if channel conditions are worse.

Cases where that might be useful range from LTE where the radio scheduler bursts to try and efficiently use Ethernet framing, or something like picket fence VHF+ fading where the channel capacity during peaks might support it, or I don’t know … maybe aircraft scatter.

73,

Ed NB0M

---

From: 'Bruce Perens' via digitalvoice <digita...@googlegroups.com>

Sent: Sunday, 20 September 2026 23:20:26
To: digita...@googlegroups.com <digita...@googlegroups.com>
Subject: Re: [digitalvoice] New CODEC work

 

To view this discussion visit https://groups.google.com/d/msgid/digitalvoice/CAK2MWOuvU3tD3SzwOQt%2BK66MKrpKMwg0zrBNvT76Yb8rs%3D6YTA%40mail.gmail.com.