One of the most thrilling childhood toys for the adventurous 1970s or 1980s kid was probably the toy walkie-talkie. It didn’t matter that they were a very simple AM low-end-VHF radio with a range of about 500m and a Morse key of debatable utility, you could talk clandestinely with your friends, and be a more convincing spy, or commando, or whatever was the game of the moment. It’s a memory conjured up for grown-ups by [Chris G] with his ESP32 walkie-talkie, which replaces a shaky 49MHz connection with one a bit more robust through the magic of WiFi.
The hardware is a collection of modules on a custom PCB, aside from the ESP32 there’s an I2S microphone and I2S audio amplifier, which along with battery and speaker are housed in a neat 3D printed case. I2S is used for simplicity, but there is no reason why analogue components couldn’t be used with a few code changes. Connection is made via UDP over a WiFi network, or should there be no network via ESP-NOW. We’re not sure the range will be brilliant with those little on-board chip antennas, but with the wide range of 2.4GHz antennas to be had it’s likely a better result could easily be achieved if the stock item disappoints.
We like this project, and it’s one that’s especially pleasing to see given that we saw the potential a few years ago in a less successful walkie-talkie using the ESP8266.
Hmmm. I wonder if this would work with one of the LoRa modules.
Technically yes, legally probably no.
Hell hath no fury like a Ham enthusiast blocked.
Are there regs on what you can and cant broadcast over LoRa? (Beyond the obvious for any general access radio) Or do they have an airtime use / fair use regulation?
In EU 1-.1% airtime depending on band and location.
I’m not on the Lora everything bandwagon so I haven’t checked if the high speed channels are in the .1% band, but even if they are in the 1% band, 36s of speech isn’t much.
I was thinking LoRa for the range, i guess the airtime restrictions would be a problem, maybe a record->compress->short burst transmission model could work to reduce airtime.
With the noted issue of airtime, there’s some rules and regulation regarding encryption, it’s actually banned for HAM operations to discourage commercial non-fair-share services. I don’t understand it myself.
But ISM isn’t HAM. It’s hard to imagine WiFi or wireless keyboards or car key or garage door remotes without encryption.
Depends on where you’re operating and the circumstances.
ACMA License Conditions Determination says we can use encryption in emergencies for example.
No problem, use any LORA module
not really, although bitrate might be enough at least on lower Spreading factors.
You still need to keep in mind that it operates on RF bands where you are not allowed to spend more that 1% of time transmitting.
I don’t know if I’m holding it wrong, but I’ve never described ESP32 on chip WiFi as particularly robust for any kind of constant bandwidth use.
…Especially as (as far as i can see) its shooting raw uncompressed I2S over the WiFi?
Thanks to this article I found out about ESP-NOW, but it seems to require some kind of pairing. Has anyone tried this kind of communication by pushing raw audio frames into ether and receiving them using promiscuous mode?
I’ve tried using broadcast mode available in esp32 with LongRange 2.4Ghz transmission (WIFI_PROTOCOL_LR + WIFI_PHY_RATE_LORA_250K)
pc -> codec2->serial->esp32->esp-now-> ..::AIR::.. -> esp-now->esp32->serial->codec2->pc
Works pretty well for the very short distance but fails when codec2 lost some frames from continuous compressed stream. With custom software, based on codec2 with proper handling of missing data, will work!
I wrote a long comment about using code2 as codec for this, but I had some technical hickup en I tried to publish it. I haven’t tried it, because my programming skills are not sufficient. Did you run the codec on the pc or the esp? If on the esp, how did you manage to work around the FPU requirements?
>>Did you run the codec on the pc or the esp?
On The pc.
I’ve tried to build and run on esp32 but without success. As I remember, oldest codec2 version, after some changes compiles
I noticed, right after I published my question, that there is a esp32 port of codec2 on GitHub. Haven’t tried it.
Put it in an Altoids can.
Check out the YouTube channel “That Project”.
He has several esp32 projects, and does an excellent job
From the author:
However, there are some disadvantages of UDP that we should be aware of:
– Delivery of UDP packets is only best effort – there is no guarantee that someone will receive the packet you send.
– There is also no guarantee of packet ordering –
someone may receive the packets you have sent in completely random order.
As for UDP the first statement is true but for the second one i don’t agree as why (by who) change packet order.
Or maybe i’m missing something as udp over tcp?
Link-local communications, you are possibly correct, there’s nothing there that will “re-order” the packets.
Soon as a router is involved however (especially one with traffic shaping and priority queue) or a “mesh” style network (like the Internet itself: a mesh of “autonomous systems”), all bets are off.
Lower layers retransmitting may give you packets arriving out of order.
Nice project. Very simple walkie talkie. I was trying to find some simple ones for the kids when they were 3. A switch for on off and button to talk would have been great, anything that simple had horrible audio where you could barely hear what was said. The frs radios have way too many buttons and volume knobs for the little ones.
I started to look into arduino and nrf24 walkie talkies and there are some projects. This project is what I expected I would need, DAC’s, wifi for the transmitter/receiver It would be nice to pair two of them together if you were not using them around a wifi router. Or somehow mesh network more. I was looking at using the esp8266 i have on hand.
I did find a couple of radios by cobra with only a power button and talk button, almost same form factor as the article, if these could have hacked firmware they would be perfect, alas they only transmit to the paired parent radio. (model was cobra fs-300-2)
Why do I look at this project and have a sudden urge to install one in the sole of my shoe?
A lovely little device – and I remember when a walkie talkie used a long piece of string to carry the signal.
Good Thinking, 99!
Try my Arduino intercom – just don’t make the PCB it’s horrible.
https://github.com/ukmaker/Intercom
Interesting project! 😎
Remembers me a bit of the Bluetooth Talkie app..
>”which replaces a shaky 49MHz connection with one a bit more robust through the magic of WiFi.”
Interestingly, AM radios could be much better sounding than they used to, if the receiver side was improved.
Like, by using a synchronous detector (an artificial AM carrier that’s generated on the reception side). 🙂
Makes me wonder why there’s so little interest in this. Air band radio uses AM all the time (it’s safer because AM allows talk over) and the audio quality isn’t bad at all.
There is a 1999 draft IETF specification for Reliable UDP Protocol or RUDP which does provide for in-order UDP packet delivery.[1] However I could not find any mention of broadcast and/or multicast capability in the draft IETF specification for RUDP. However broadcast and/or multicast capability either exists in RUDP or it can be added since Microsoft ripped off RUDP and “made” it into their proprietary R-UDP protocol which is used in IPTV service delivery over multicast networks.[2] Using RUDP with the ESP32 would involve custom packet crafting. Since you have already implemented a FILO plesiochronous packet buffer in your walkie-talkie, another approach would be to simply add a sequential packet order field to the outgoing UDP packets and enable the receive processor to reach into the receive packet buffer and rearrange any out of order packets. The packet order field will of-course need to be separated from the I2S data before it is sent to the I2S decoder.
* References:
1. Reliable UDP Protocol
https://tools.ietf.org/html/draft-ietf-sigtran-reliable-udp-00
2. Reliable User Datagram Protocol / Microsoft R-UDP
https://en.wikipedia.org/wiki/Reliable_User_Datagram_Protocol#Microsoft_R-UDP
To the author: you may want to consider the fully open source Codec2 for encoding voice using extremely low bandwidth, therefore gaining distance by keeping the data rate low. https://www.rowetel.com/?page_id=452