wireless microphone digital

this project has had a lot of neglect so I just bought 2 x Lyrat 4.3 boards

and 2  x  RFM96 ( SX1276 modules )  radio modules.

The lyrat 4.3 boards come with an audio codec on board and the ESP32's / audio hardware works with the ESP-IDF and ESP-ADF audio IDE

here is the start

https://github.com/benbiles/BBBOXLINK_TX

https://github.com/benbiles/BBBOXLINK_RX

as you can see in these pictures the SD cards have been removed along with some 10k pullups and diodes since there are not enough GPIO pins lefton the boards left for SPI. a lot of esp32 pins are used already for the codec push buttons and Jtag debugger pins. I ordered a cheap JTAG debugger for the board so I'm keeping them in case I can use the debugger. would be helpful. I won't need the SD card slots.

The Lyrat 4.3 boards were cheap and there's BT 4.0 and wifi on there that I thought might come in useful. 

The code is still a mess as i'm porting from arduino C++ based code !

I'm a complete novice when it comes to C++

I just learned for instance you can supply less than the defined number of params to a function or have more than one prototype of a function ! 

amazing , but I think I'm better off converting the library to C for esp32 as there are downsides in compiling C++ with ESP-IDF and the ESP-ADF IDE environment for the time being. It might have been more work than starting from scratch from the datasheet but at least I might learn something about C++ on the way :) 

https://github.com/ornotermes/KiteLib

inspired by..

https://hackaday.io/project/159940/logs?sort=oldest

I will use a better compression than CODEC_G711A if I get the audio link working.

for now I will be concentrating on getting the radio lib working.

I'll have to re-write the radio transmit receive functions for ESP32 ( burst mode needs CS line held low ) and now i'm looking at how to define the hardware interrupt pins in esp32. should be doable ! 

I think I can get away with just tieing the radio reset hardware pin high. ( another possible sparse GPIO pin saved ! ) 

The ESP32 has SPI DMA with ESP-IDF and I2S DMA from the codec in the ESP-ADF.  I think i will have much more luck with ESP32 than the last arduino attempt since I could't really figure out how to assign DMA to the I2S transfer.

Any ideas / help with the code would be much appreciated. especially if anyone is more familiar with esp32 ? 

the RFM96 ( SX1276 modules ) are more known for loraWan but they have high sensitivity in FSK OOK mode and should be capable of 200kbsp at fairly respectable power output.

All my efforts have been on the multichannel field recorder project!

Since working on that I have learned a lot more C and understand a lot 

more about micro controllers!

It's quite clear that to make this project work I will need to use DMA with a circular buffer to transfer the samples to from audio codec and radio hardware.

I now know a lot more about DMA since working on the multichannel field recorder project and will re-start this project from scratch either using ESP32 or STM32f7 mico with RF hardware.

For now i'm just to busy on the other project ! 

trying ping pong buffers. code here ;

TXlooks more promising than RX

https://github.com/benbiles/UHF-digital-wireless-microphone

maybe I need to have multiple pingpong buffers on the RX ?

if packet ready get packet

ping pong buffer

demodulate from ADPCM

16bit array to 32bit array 240 samples for I2S

( load 2nd ping pong buffer ? here )

I2S inturrupt outputs 2nd pingpong buffer 1 sample at a time until empty ?

...

how should the timing work?

should i timestamp / number the packets , packet order ?

I have setup 2 x screens for debugging on I2C to help with timing etc... you cant use Serial.ptint to slow and takes too much time in an audio application.

I'm using liquidcrystal_i2c on the arduino DUE's .. NO not so simple more problems with arduino DUE and repeat start in I2C , sureley this bug was fixed by now !!!! anwyay maybe i'll have to find an alternative I2C library or something , hopefully will get this fixed then I can debug some timing problems I have with IMA_ADPCM codec,

ok finally i have horrible sounding audio streaming in to the reciever in 48 byte packets made of 8bit samples. 1 every 4 samples is sent from the TX.

my mistake was believing that this code would determin if I had a

packet recieved or not. It turns out it was pumping out multiples of the

same recieved packet causing a horrible ringing sound.

if (rf24module1.available())
{
uint8_t len = 48;
if (rf24module1.recv(packetmod1, &len))
{

I have now numbered the packets, so first byte in packet has a number from 1 to 255 and I test that if packetnumber != packetnumber then ignore the packet :)

to be expected. the samples are being pulling in by the I2S codec from

the recieved samples in the circular buffer and this appears to work ok.

I also found that my home made radio config was not working at all so now I have reverted to using a canned config in the radiohead driver.

its tricky making your own config with the SI software and then editing the template in radiohead. you can't just replace the config file with the generated one from the software. basically its a lot of time working out which registers your allowed to change and which have to stay the same and even then it might now work at all.. mmm

I might just stick with the GFSK Rb = 150kbs, Fd = 300kHz pre made config for now

and try and impliment IMA_ADPCM again now the link is working :)

then I will enable true diversity recieving and do some range tests.

So far range is looking good even with just one reciever !

48 byte packets are flying accross from TX to RX. my RTL SDR looks busy with 4GFSK at the correct frequency !

I tried bit shifting >> 24 to uint8_t and back again <<24 and copying the samples back into I2S driver ( passthough ) and everything sounded as good as 8 bit gets :)

At the reciever end I am recieving the packets, unpacking the recieved 48 byte packet array into a circular buffer as they come in. The I2S driver is pulling samples from the circular buffer as it needs them.

So there should'nt be a timing issue ? but maybe there is !

The circular buffer warns if it runns out of samples, its not, it warns if it overflows, its not.

I am only TX ing 1 out of every 4 samples, I tried every other and every sample. I get differnt ringing sounds almost like a delay effect.

could it be packet order ? maybe , next thing to do is just send a uint8_t number as the first byte of every packet.

after that maybe send a stream of numbers that increase in value and see if they are consistant ! perhaps my GFSK radio config is malforming the data. Its hard to debug, if you use the Serial terminal then obvusly things stop working !

My 32bit binary samples are left justified!!!! looking at the binary numbers converted something looks wrong.

if I copy from uint32_t to a uint8_t with a bit shift of >>24 and mask & 0xFF I should get an 8 bit number represetation of the 32bit number.

but i'm getting only 11111111 whatever the 32 bit number. no wonder i'm getting some quite interesting noises on the reciever !

How do you convert a LEFT JUSTIFIED 32 bit number to 8 bit ?

do I need to right justify first ? and then bitwise shift >>24 ?

google brings up a solution to justify binary from right to left but not from left to right !!

Soon into starting to use freeRTOS to try and tackle the timing issues i'm possibly having with I2S SSC and RH_R24 radio ( driver librarys should be multithreaded, thread safe re-entrant libraries ) are needed to use freeRTOS.

I ask on RadioHead forum ,. answer don't no. also freeRTOS requires pin 2&3 to be connected together. I'm using those pins , did'nt want to resolder to other pins. OK , going to stick to learning about SSC timing and see if I can sync the rf24.send(data.len); function call to that timer somhow. quite quicky I found the NVIC_EnableIRQ(SSC_IRQn); in HiFi.cpp ( the I2S driver code ) i am hoping I can sync the sending of the packet to the SSC inturrupt. I might have to write as simple radio send function myself if I can't get this to work.

http://asf.atmel.com/docs/latest/sam.drivers.ssc.unit_tests.sam3x_ek/html/group__sam__drivers__ssc__group.html#ga8a68bfe46c95c426ef07be3ca618a54b

I did some more tests just with I2S passthrough and the decimation. The deciamtion works fine even when doing some Serial.print(samples,BIN); to check samples are coming are going.

The millisecond I enable the rf24.send(samples, len); to send the 48 byte packet the samples freeze up. New plan !

going to try and use https://github.com/greiman/FreeRTOS-Arduino

freeRTOS scheduler library. No idea what i'm doing with it but hoping I can assign the RF function send to one task and the samples IO circular buffer and I2S some others !

today I tired 1 byte at a time and reliased there is way too much overhead in the RF driver for this to be useful ! its obvoius really ,

There is the preamble of x amount of 0's an 1's before each 1 byte packet is sent and other wasted time making the packet in the driver.

So I boilled things down to basics and took some advice from the comments here ! now I am just going to bit shift to 8 bits from incoming 32bits keeping the 48khz samples and increase the RF bandwidth. I can bring the RF power right down and connect the TX with RX with coax cable so I'm not blasting illeagle RF all over the place !

right now there is an RF bottleneck until I edit the radiohead config file ( there is'nt a pre-made , 'canned' template that can do 8 x 48000 = 384000 bits per second gfsk.

After I make that I should know if I have timing problems or not with the reciever and the diversity RSSI packet selection.

At the moment the I2S SSC driver just pulls a sample from the circular buffer everytime the SSC timer inturrupt happens. its wanting a crazy 32 bit 48k samples , per channel !

Thats 1,536,000 bits per second per channel per second..

obvoiusly theres no more information in all these bits than the 8bit 48k it came from but lets

not go rebuilding the I2S driver unless I really have to !!!! It looks like a mess of nasty timming code.