Frame splitting in 2s_lora_walkie_talkie example about esp32_codec2_arduino

[R2AirVlad]

It iterates over the packet and reads audio frames, when last byte from the current frame is read it will decode complete frame and send it over to i2s for playback.

Ok, but for what we need working codec2 frames if we have 48-bytes packet at all... All frames at packet is sequenced each over and it will be decoded fine... Then we got 48 bytes packet we can start playing all the packets bytes, absolutely no need to split it for frames -- but in case of voice delay maybe justified... I don't know

To have repeater operation you need second modem with frequency split, because you cannot send and receiver over the same modem at the same time unless some form of time slots are employed where you send on time T and receive on time T + 1.

I mean a half-duplex - just receive and immediately transmit the received packet. If packets is small and retransmits as fast as working speed codec2 is should be works.

[sh123]

It iterates over the packet and reads audio frames, when last byte from the current frame is read it will decode complete frame and send it over to i2s for playback. To have repeater operation you need second modem with frequency split, because you cannot send and receiver over the same modem at the same time unless some form of time slots are employed where you send on time T and receive on time T + 1.

[sh123]

If multiple Codec2 encoded audio frames are aggregated into one packet then receiver needs to split, because Codec2 requires frames of specific size, it cannot decode complete packet containing multiple audio frames. It is possible to send packet containing one audio frame, but if such small packet is re-transmitted over e.g. KISS Bluetooth then there are delays, because Bluetooth is not efficient in operating on such stream of small packets.

For half-duplex, a.k.a. "parrot" you need to accumulate number of packets, wait for some time until no more data is received and then re-transmit complete buffer (this is how analog "parrots" are operating). So you need 2-2.5x channel time for each user's 1x transmission. If you want to re-transmit each packet immediately then sender (and other users) must know that he should wait for a packet duration, otherwise there will be interference, it requires some kind of time slot mechanism and you will need at least 2x bandwidth on the channel. Taking this complexity into account, it might be easier for repeater to operate full duplex with two modems and clients to operate half duplex with frequency split?

[R2AirVlad]

If multiple Codec2 encoded audio frames are aggregated into one packet then receiver needs to split, because Codec2 requires frames of specific size, it cannot decode complete packet containing multiple audio frames. It is possible to send packet containing one audio frame, but if such small packet is re-transmitted over e.g. KISS Bluetooth then there are delays, because Bluetooth is not efficient in operating on such stream of small packets.

Tested. I can't achieve sequential decoding without codec2 framing algorithm, all bytes is mixed up in queue and codec2 can't read it. Only first byte is present on its place - all another is completely mixed... very strange behaviour, maybe codec2 such works peculiarity...

For half-duplex, a.k.a. "parrot" you need to accumulate number of packets, wait for some time until no more data is received and then re-transmit complete buffer (this is how analog "parrots" are operating). So you need 2-2.5x channel time for each user's 1x transmission. If you want to re-transmit each packet immediately then sender (and other users) must know that he should wait for a packet duration, otherwise there will be interference, it requires some kind of time slot mechanism and you will need at least 2x bandwidth on the channel. Taking this complexity into account, it might be easier for repeater to operate full duplex with two modems and clients to operate half duplex with frequency split?

Half-duplex - is aka TDMA (or simpler TDM — Time Division Multiplexing) in digital world ;))
If we stay in "packet paradigm" we always has opportunity to slice it as we need. Of corse transmitting speed is doubled to be need, but this idea is workable for my opinion. Will test it...

[R2AirVlad]

https://en.wikipedia.org/wiki/Time-division_multiplexing

[sh123]

TDMA is more about splitting unidirectional channel by time, here you will need to split bidirectional channel, probably, with some guard intervals and CSMA, like in WiFI, but unlike WiFi hidden nodes problem will be more dramatic when multiple users will be operating. It needs more complex protocol, which will eat a lot of narrow band channel bandwidth, so adding second 5$ modem for full duplex and uplink/downlink splitting might be an option.

[R2AirVlad]

For best understanding see my description of entire algorithm:

1. Station A start transmitting - master station;
2. Every period of time = 2*(time of coding/decoding and sending/receiving one packet +5% protection interval) master station send one packet;
3. Station C - slave station (repeater):
   3.1. Receive packet and control CRC (internal LORA modem function);
   3.2. If packet CRC = OK - read from buffer and transmit (this process timing equal by described on step 2);
   3.3. If packet CRC != OK - - trashed and waiting next packet;
   3.4. Hearing next packet from master station. Because we did't send new packet from master station during time us formalised on step 2 we have time-slot on station C to process one packet;
4. Station B - slave station (recipient) - receive, control CRC, and buffering packet. Let's do such method for a couple of packets. The number of packets (N) which needed to buffering can be described us:
   N = codec2 bitrate / packet length + 1 or 2 extra packets if we have loosed packets and need to continuously jobbing for codec2.
   Next - codec2 read data from queue and play.

If station B need to callback to A - they just exchanging in described above scheme.

[sh123]

@Fotr0 , there might be need for clock synchronization between stations, otherwise there might be collision if A and B will transmit at the same time, for example, A and B can synchronize on first digirepeated packet from C or C can periodically send some beacon.

[R2AirVlad]

Yes, I thinking about it... Probably the better way like on SSFH synhronization to use GNSS lock-on. We need some 'tick' signal from any GNSS system.