Can’t the first proof-of-concept be just audio recorded on the phone and sent over LoRa?
A standalone device with mic/speaker would be perfect, but I think it should be optional.
You’re doing an amazing job with the plugins @mc-hamster, trying to learn a bit so I can collaborate in the future.
Sure. We just need someone to add the required features to the android app in a way that doesn’t interferers with the current uses if that features isn’t present or enabled on the device.
Then you need a device side plugin that can accept your recording, chop it in to packet sized bits, then on the receiving end resample the packets and push the file to the phone.
There are other ways to skin this cat. I’d like to see something that uses a generic file transport plugin so it is easy to share smallish files over the network. Then on the app side of things PTT transmissions can use a file naming system so the app can automatically present it with the audio play back interface.
For practical reasons it should probably only be available to the user when using the faster channel settings.
The proof of concept of audio over lora was already done by deulis/ESP32_Codec2. No need to duplicate that effort.
To implement on meshtastic, it would be to create the proper protocol to handle the blocks of data, buffer it and then play it back out. The work would be almost exactly the same regardless of the source of data. Maybe some additional effort to enable it on hardware as a stand alone feature and also make it work on other client devices.
I think the most challenging part would be to work with the delays and throughput limits imposed by our mesh routing protocol.
Thanks for the shout out. I’m just learning as I go too. Happy to learn along with you.
thanks for this amazing thread!
I wonder if the implementation should be in the esp32, or in the end-user app, meshtatic-android.
While PTT is great I dont think it aligns with what this system can do when it comes to an outdoor long-range communication device. I have been testing in the cascades and what it does its handles messages at long ranges really well. The GPS position is also really nice. I’m getting ranges that exceed radios for audio in dense forests and the valleys of the mountains around me which is what I want. Im putting together a team and we are going to deploy a tethered balloon from the Top of Mount Si and from there we want to see if we can cover a chunk of the cascades.
The truth is PTT will have limited ranges it really will because the delay for a text message can be upwards of 8 minutes if you are 30+km away depending on the radio settings. I don’t see PTT working much past already established radio ranges since the delay makes the convenience of a conversation go away and then they just become delayed audio messages. The battery consumption would also be something to note.
I do think being able to broadcast short messages with audio should be a feature but maybe not push to talk as when you push you will also begin broadcasting and can block other signals whereas the mesh nature of the “text” network works well with each other and allows multiple nodes to be working together vs listening or transmitting like PTT would require.
Text to speach would be a really good feature. Also, to have the app generate tones from a message as a way to communicate.
I think this falls more in line with the goals
I think on the app side, the channel speed would define the length of the audio.
With codec2, even in the worst case scenario you would be able to pack a few seconds of audio per transmission, so you can inform the user how much time it may take for the audio to be sent (and maybe a queue so you don’t delay other messages because of this one… or maybe the audio meesages could be sent as additional payload to others that travel around).
In each package there is ~200 bytes… As codec2 lowest encoding is 450bps, for each second recorded, you will fill two packets, so it won’t be realtime, and the app should stop the user from sending too long (or too frequent) mesages.
At a minimum you should take in to serious consideration the 10% duty cycle. Worst case scenario the device cycle may transmit that payload three times.
@zebus is unfortunately correct if using these devices past their short or medium range. PTT Voice Transmission - #47 by zebus
Just some inspiration to remeber the posibility of LoRa + Voice.
To add to @luandro 's link how about using Semtech SX1280 chip for higher data rate at cost of lower range. It is 2.4 ghz frequency that may not have duty cycle limitations in some countries. Relevant experiments for image transfer using SX1280 and ESP32-CAM at link below:
Thanks.
There is a bonus distance ranging feature with Semtech’s SX1280 chip as demonstrated by Stuart Robinson:
Thanks.
Very nice.
Honestly I saw the topic show up again and thought “Not again…” but this is a really cool development that makes previously discussed ideas much more plausible.
If just requires different hardware 
That was a good read!
I would not have thought this possible with 2.4ghz at such low power output, LoRa continues to impress me.
I’m not a particularly technical guy, but from a practical comms standpoint, voice communication does not have to be particularly long range. Voice communication is great because it is real time (or, if it is digital, close to real time), but there aren’t too many cases where I need instant, real time communication with someone who is very far off. For longer range connections the slowness of text entry is less of a problem.
@CycloMies suggested limiting the max hop limit, and that would work great for all my use cases. I would love to see an auxiliary voice channel that sits adjacent to the mesh, doesn’t flood the network, and only reaches as far as my closest team members. I was messing with a few Beartooth units over the weekend, and I have to say that the mix of short range voice and longer range text was pretty nice.
I have ordered 5 of these:
and couple of these:
to play with Semtech SX1280 chip.
Thanks.
I really like the idea of voice transmission (or even just voice message) with no mesh or hopping whatsoever and limited range. It would be cool to replace the need for gmrs radios completely with one device.
@b8b8 I would rephrase last part of your sentence like “need for bulky gmrs radios completely with miniature credit card size (or even smaller ?) device”.
Thanks.
If people start working on DIY guides for adding a speaker, microphone, and ptt switch for common boards, and some design files for 3d printed cases the next steps may be starting a plugin or two on the coding side.
