search

cariboulabs / cariboulite

CaribouLite turns any 40-pin Raspberry-Pi into a Tx/Rx 6GHz SDR
1.06k stars 97 forks source link

SMI Bus Troubleshooting and Consistency #150

Open japh7832 opened 8 months ago

japh7832 commented 8 months ago

Hi,

I've got two Raspberry Pi zero 2Ws and 2 Caribous. I'm trying to set the center frequency of the Caribou on the high channel and input a CW signal that's 10 kHz off the center frequency and just record the resulting 10 kHz sine wave for 1 second - a simple, "hello world" test. I'm using the 'cariboulite_util' test script to set all the receive parameters and write the recorded data to a file.

I'm seeing a lot of variability in the SMI bus. About 20% of the time when running the cariboulite_util script, there will be an SMI bus error and the script will exit. When the SMI bus does initiate correctly and data is recorded, I get blocks of values in the middle of my 10 kHz sine wave multiple times a second.

Here's a screenshot of a 20 second recording. image

The lower amplitude envelope is the 10 kHz sine wave and the skinny, tall higher amplitude data points are the blips that seem to randomly appear.

I have seen this behavior on both Caribous that I have, multiple Raspberry Pis, multiple OS and driver installs, multiple gain settings, and using multiple signal generators to generate the recorded input.

Has anyone else seen this issue and have some possible solutions?

I haven't started modifying the standard test scripts yet, but is there a way, using the caribou driver functions, to confirm the SMI bus is initialized and working correctly before trying to record data?

Should I just start with a clean slate and reflash the OS image and reinstall all the software and dependencies to see if the problem miraculously disappears?

Thanks for any help!

-James

hea-lab commented 8 months ago

I have experienced samples corruptions long time ago (https://github.com/cariboulabs/cariboulite/issues/25), but the issue was closed by the maintainer without any explanation.

The corruptions came from design issues with the FIFO and the SMI driver which is not fast enough to launch the next DMA transfer, so in this current situation you will lose some samples ... In proper design, you have to protect IQ samples (numbering them and adding a CRC for example, but as I understand the FPGA is pretty full, so it is very difficult to add this logic to detect/ensure no sample loss)

I don't know if the maintainer fixed the 2 issues, if not I am afraid this design cannot work properly

japh7832 commented 8 months ago

Thanks for the reply. I have a collaborator that has the same hardware set up and so far has not seen this issue - so there's a chance I have just a bad driver or library somehow?

I followed all the install instructions from the main branch ReadMe and I don't think that this issue is caused by any of the problems mentioned in the troubleshooting section.

The RF transceiver chip's data bus has to be in sync and goes through a re-sync'ing process when that synchronization is lost. Part of me is wondering if that data bus is losing synchronization multiple times a second?

I guess I'll start taking a deeper dive into the SMI documentation mentioned in the ReadMe and see if I can make it a little more robust.