ofontbach
commented
7 months ago Hi @uptools, The FPGA is indeed having a deterministic behavior and, thus, no timestamps will be skipped. If you see erratic numbering on the CPU side, you can pin it on a lack of performance. That is, samples are being lost due to the incapacity of the CPU to read all of them during the available time budget. I'd suggest playing with the buffer/packet sizes of the timestamping solution to adjust this time window (e.g., maybe using packets that contain 0.5 ms worth of data works better than trying to read 1 ms each time). Other than this, just make sure to compile in release mode, to give maximum priority to the srsenb process and to adjust the networking parameters affecting the E310 (again buffer sizes, etc.).
Hi! We have compiled last version (jan 11-2023) and generated the bitstream and installed it on AndtSDR E310v1. We can execute srsenb with device_name=iio and connect to the E310 via giga-ethernet, configured for 6 PRB's.
The reader thread (which fills the ringbuffer buckets) is getting the timestamps from the FPGA, although it does not seem to get very stable timestamps, as the difference between them oscilates in the range <28000000,46000000>.
The processing thread is reading from the ring buffer, and finds the magic byte on the ringbuffer headers, although after about 4000 reads, it gets an invalid header error a few times, and then it continues reading but not checking the ringbuffer headers anymore.
Even though we do detect the downlink signal with a spectrum analyzer, the phone cannot see the nodeB.
Are the FPGA generated timestamps having the expected behaviour? Could the erratic FPGA timestamp values cause the inability to be detected by the cellular phone?