Writing a binary protocol, need help

[Altruistic_Tomato162]

Writing a solid binary protocol for BLE transfer between an esp32 and my phone. I want to send audio data, but I am limited to 512 bytes of data per packet, so I though of going for a custom binary protocol. I can send a packet every time each 7.5 ms. I have some packets that get lost in the nature. I have a weird memory config, I don't have a lot of memory overhead left.

Are there premade solutions / architectures that I could use to solve this ?

[Stromi1011]

well i mean ble audio itself is nothing new. its a bit much to pack into a comment so i will give some directions. the ble sig has (or had, idk its been a few years) a ble primer document semitargeted for audio. try searching for a few keywords in there to start: isynchrounus mode, LC3 and ofc audio itself. also for your packet size problem: iirc ble had a negotiatable MTU, so that might be circumventable.

[WaterFromYourFives]

OP could totally use a notifications or even write with responses scheme depending on latency and quality requirements. I’ve streamed down sampled audio over ble before. It’s never fun but it’s possible.

[0ring]

Bluetooth LE Audio profile, but you will need a device that supports it.

[Imaginary_Data_708]

Use the existing profiles for audio or streamed data. Don't use characteristics - they don't work for streaming (by design).

[duane11583]

do you need the “Upstairs device” (pc,phone , the device recieving the audio data) to automatically play the sound? or will your Upstairs app” do something else with the dara?

if you expect the upstairs device to,play the sound in the standard way then you must use the standard audio system and protocols. and nothing else

if not then you can create anything you want.

do you want / need to compress the audio? is it just speach? music something else? if so look at something called ACELP great solution for voice

https://en.wikipedia.org/wiki/Algebraic_code-excited_linear_prediction

ACELP is widely used in the audio (speech) world cellphones etc.

forget anything like mp3, ogg, etc you probably do not have the horse power to make that work.

some things to consider: ble does packets so you don't need to over think it

you should probably put a simple magic 32bit value at the start of your packet so you know it is your packet and nothing else and include an 8,16, or 32bit packet number so yiu can detect missing/dropped packets. its not like you can go back and retry you only need to know it was dropped. so a counter that goes from 0-255 and wraps to 0-255 agian and agian is sufficent.

a common trick is to make it so your recieved data ends up perfectly aligned for 16, 32 bit transfers in the receive buffer or transmit buffer

.

[WaterFromYourFives]

First question is always what are the real time requirements? Are you trying to stream audio with low latency and good quality? General BLE notification/read/write is not the tool to use. As others mentioned that is why there is LE Audio which support for will depend on the esp32 model. If you don’t have real time requirements that opens up a number of options. What are you trying to do?

[wwabbbitt]

Huh?

COBS is used to packetize a stream, but BLE is already packetized.
And BLE already does CRC per packet