Hi everyone,
I’ve been looking for a project like Meshtastic for a while.
Have you thought about adding PTT voice transmission using Codec2 (https://github.com/drowe67/codec2)?
If there are enough nodes the data rate can be increased to support audio transmission.
7 Likes
@Anelito Interesting idea! Further reading: https://github.com/x893/Codec2WalkieTalkie
“Should also (courtesy of RadioHead) be able to support the very interesting RFM95 LoRa family of radios, with long range and spread spectrum.”
Seems possible:
and
and
LoRa duty cycle restrictions are problematic for sending voice. However, there are not such restrictions on PMR 446MHz.
In theory, there could be a short preamble sent, to the Meshtastic mesh network, on LoRa 433MHz, to indicate a node will send PPT Codec2 voice on PMR 446mhz. Nodes hearing the preamble on 433MHz, would switch to 446MHz for receiving Codec2 packets.
This would not disturb the Meshtastic mesh on 433MHz, but the nodes would loose the mesh packets, while operating on PMR 446MHz. However, @geeksville adopted reliable router on the mesh, and therefore the nodes could receive the mesh packets when turned back to LoRa 433MHz (as the packets are being resent).
2 Likes
That’s probably the main limitation of Meshtastic. Relying on single channel nodes, packets loss is highly probable. Just imagine two couples talking over the mesh network at the same time within the same geographic area.
1 Like
In theory, a mix of using mesh on 433MHz, and voice on 446MHz could work, without disturbing the mesh too much. Especially, if we have a max hop limit (TTL 2?) for voice flooding on PMR 446MHz. This would interfere less with the rest of the mesh, as delays would be huge for flooding the voice over multiple hops (making discussion times overall longer).
When the PPT is pushed, the node could send a short notice to the Meshtastic mesh: ‘within TTL 2 switch to 446MHz for receiving voice’. Furthermore, the notice could include also information of users wanted to listen to the voice message (a group of users). Therefore, only selected nodes would switch to 446MHz, and the rest of the nodes would not be interfered.
The node then sends the voice packets to the air, and other nodes on 446MHz would flood (relay) the packets per TTL. Nodes would go back to 443MHz, when no voice packets are heard (or sent) within a time delay (of 5-10s?).
Depending the length of the discussions on 446MHz, the nodes might loose some of the mesh messages. However, the senders would know the messages where not delivered, as they don’t get ACK’s. The sender could then send the messages again. Of course, PPT notices could be sent more widely to the mesh, for noticing other nodes for an upcoming period of not listening to the mesh messages. The nodes on the mesh could then queue the mesh packets, and send them later.
There could even be different LoRa parameters used for mesh packets, and for voice packets: for example slow and long range for the mesh, and fast and short range for the voice - depending on the need.
@Anelito Depending on usage, the loss of mesh packets might not be a problem, if users relay only on ACK’ed packets.
3 Likes
What about using relay nodes with two transreceivers, one at 433 and one at 446MHz? You could split communications and increase reliability not only for audio transmissions but also for texts. We should also consider concurrent voice communications and how to avoid packet collisions if two users simultaneously transmit.
Wouldn’t a TTL 2 limit the size of the mesh to a few miles?
2 Likes
@Anelito In my opinion, if PPT was adopted to Meshtastic, TX settings and protocols for mesh packets on 433MHz and for PPT voice transmissions on 446MHz should be separated.
The reason why I suggested TTL 2 for PPT packets was to a) limit the effects for the rest of the mesh by forcing as few nodes as possible to switch to 446MHz, and for b) voice transmissions suffer greatly of unexpected delays (of witch are typical when TTL is increased). TTL for ordinary mesh packets could be same as they are now.
Overall, my ideas regarding PPT are more or less theoretical, as the implementation might not be as simple. 
APRS exists
It has it’s users https://aprs.fi/
https://aprsdroid.org/ - ecosystem
APRSdroid - OSM Offline Maps - offline maps
(Apart of having fun with tech toys) What is the benefit of making yet another type of voice communicator when you have variety of devices (even mil-spec quality for affordable price) able to perform this task way better than LoRa? Especially when you have these devices doing analog and digital including GPS and other APRS low speed data possibility…
and if you have that piece of extra money there might be some interesting set of devices like this one RFinder Store has a new Location 
2 Likes
Range and battery consumption
Those devices suffer heavy interference especially in an urban environment, their range is very limited.
Meshtastic is an alternative communication infrastructure: adding support for other data types helps bring in innovation (like the Codec2 compression algorithm) and rethink about alternatives to make the whole system more robust and powerful.
1 Like
Routing audio messages via LoRa MESH network? Have you calculated the transmit times - (I didn’t, so I am just asking). My humble guess is that you would need a separate LoRa transeiver with each “node” to cover audio transfers. So each meshtastic device would consist of 2 LoRa transceivers (operating on different channels) and maybe dedicated audio encoder/decoder circuit to cover this extra request.
Or am I wrong here?
1 Like
Yes pretty much what @CycloMies was suggesting when talking about switching to a separate 446MHz network for audio.
The encoding and decoding of audio is a very CPU expensive process that requires a modern smartphone.
1 Like
I agree - audio on LoRa mesh is not a practical goal I think.
re: APRS
Yes (I used to write a fair amount of APRS software and I’m technically a ham, though I don’t do much with it now). I think APRS is great. But different goals for this project:
- Very low power levels (but similar range)
- Self forming “just works” mesh for users, not hams that want to actively construct something
- License free
- The low power levels enable super long battery life and repeater nodes that can work from a quite small solar cell
- Encryption is legal for this application, so secure group messaging
- Extensible open-source devices let people either add new behaviors to the devices or use the device as an easy $15 dongle to connect their rasberry pi to a mesh
4 Likes
@slavino & @geeksville, Totally agree: Routing audio via LoRa might not be practical.
However, wouldn’t using foolproof solutions be to lame? Voice over LoRa could be an interesting adventure for someone?
2 Likes
I’d be down to try testing audio transmission.
Let’s consider a usability boundary by answering a question. How many hours would people be happy waiting for 10 seconds of audio?
1 Like
Duty cycle limitation may be lifted in remote uninhabited areas.
1 Like
Could we calculate the transmission rate per second of audio (highest compression, lossy codec) for restricted and unrestricted duty cycle.
I recall seeing a baud rate for LoRa, but I don’t know how it translates practically for the meshtastic platform.
If I remember correctly the minimum data rate for reliable voice calls using codec2 is 2.4kbps
Just been reading that 600bps gets roboty and just about readable, 3.5kbps for minimum toll (telephony quality) plus another 100bps for transport assurances.
Synchronous delivery and receipt is an additional challenge. But I’m assuming in this case we’ll be a long way from that. (As well as duplex Comms)
1 Like