ok, implimented some ping pong buffers.
I think the code is making some sense on the TX but the RX code still needs looking at.
you can't use ping pong buffers if your changing data types using bitwise operators etc to go from 8 bit to 32bit since the 2 ping pong buffers need to be the same type to work !!
I maybe should just have the ping pong buffers in between more processes.
The ping pong buffers might help the RF reciever and ADPCM decoder but I think I need to add another 2 pingpong buffers between the I2S output intutupt and the ADPCM decoder also.
going to dig out the arduinos this week and test / work on this code
I would love it if anyone has time to take a look ! code link at bottom of this log
I think I will have more success if I load a hole array of samples into libLTC. I've set both TX and RX device to decode LTC in the hope I might get one working !
I am using LCD screens in the effort to debug. UART serial port is not fast enough.
the project is starting to join the digital wireless mic project. So I suppose this is becoming a digital diversity ADPCM LTC capable wireless mic system if it ever works.
The ADPCM would ultimately be replaced by a better encoder / decoder in DSP , but I thought ADPCM would be a starting point to knock down the data rate and learn the basics.
RF24 tx module configured at 150kbps
The 2 RX modules are set to test RSSI, module 1 wins if its => module2's RSSI level so module 1 is more likely to win. I'm sure there is a better way !
packet size is 240bytes of ADPCM. If I remember correctly 1 ADPCM byte is made of 4 samples. I need to check that , it would cause timing issues if it does'nt decode the same in reverse !!
In earlier tests I tried using circular buffers and packet numbering. circular buffers just filled up or emptied and did not stay in sync at all ..