01/27/2017 at 15:32 •
trying ping pong buffers. code here ;
TXlooks more promising than RX
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 ?
08/20/2016 at 18:11 •
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,
08/10/2016 at 02:24 •
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.
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 :)It audio sounds like rubbish of course but that is
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 !
08/09/2016 at 13:04 •
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 !
08/08/2016 at 09:55 •
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 !!
08/07/2016 at 16:55 •
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.
08/05/2016 at 06:02 •
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 !
08/03/2016 at 13:39 •
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.
- 08/01/2016 at 14:52 • 0 comments
08/01/2016 at 08:24 •
I fixed the RSSI problem with
// instance of the radio driver now called rf24
RH_RF24 rf24module1(10, 2, 9); // pin 10 cs, pin 2 inturrupt IRQ pin on module, Nsel ( power ) pin 9
RH_RF24 rf24module2(11, 3, 8); // pin 11 cs, pin 3 inturrupt IRQ pin on module, Nsel ( power ) pin 8
basically the NSEL ( or power ) pin on the modules needed there individual pin in the RadioHead library. so I used digital pin 8 & 9 on the arduino.
I took of the transmitter antenna and the recieve antennas and moved the transmitter near one reciever connecter to the other and both RSSI values were updated in real time.
One confusiing aspect here is the RSSI value is returned after recieving a packet.
So at the momnent I am recieving both packets and then determining there RSSI value and only copying the one that has the higher value into the circular buffer ( the cue for wating to be decoded back to 16 bit samples from 4 bit )
The LMA_ADPCM encoder encodes 16bits into 4bit samples so I am putting 2 LMA_ADPCM samples in each byte. 24 bytes are being sent in each packet.
OK, next I have to impliment the LAM_ADPCM decoder and rebuilt the 16bit samples so I can shove them back out to I2S. The I2S Library cliaims it just left justifys the samples in a 32bit per channel slot. we will see.
more news when I get the decoding written for the reciever. it should be the reverse of the encoder but I'm scepticle I got that correct the forst time !