23 Jan
2019
23 Jan
'19
12:21 a.m.
I have now moved the Limesdr mini back and forth between the Orange Pi
Zero and a Supermicro
(i386). On the Pi Zero I get the following on the console:
Tue Jan 22 20:36:43 2019 DMAIN <0000> Transceiver.cpp:1039
[tid=3043130448] ClockInterface: sending IND CLOCK 321960
Tue Jan 22 20:36:44 2019 DMAIN <0000> Transceiver.cpp:1039
[tid=3043130448] ClockInterface: sending IND CLOCK 322176
Tue Jan 22 20:36:45 2019 DDEV <0002> LMSDevice.cpp:600 [tid=3043130448]
chan 0 recv buffer of len 2500 expect 894a7c got 895e68 (895e68) diff=13ec
Tue Jan 22 20:36:45 2019 DDEV <0002> LMSDevice.cpp:600 [tid=3043130448]
chan 0 recv buffer of len 2500 expect 895440 got 897024 (897024) diff=1be4
Tue Jan 22 20:36:45 2019 DDEV <0002> LMSDevice.cpp:600 [tid=3043130448]
chan 0 recv buffer of len 2500 expect 895e04 got 897de4 (897de4) diff=1fe0
The DDEV message can continue for a long time, and typically then ends
with the transceiver exiting. It can however sometimes recover, and the
first message of
recovery is a IND Clock message, after that the transceiver restarts,
and all is again well for some undefined time.
I have followed your suggestions, and rebuilt --with-neon-vfpv4 , and I
have enabled debugging. If I understand correctly, the function is
readSamples, and
is the actual input from the Lime rx. The length seems always correct,
since I do not get that log entry, but rather that the time has
"slipped", i.e.
the LMS api has not delivered anything for "diff" time, or the timestamp
received has "jumped" in the Lime.
This indicates to me that this specific arm cpu in combination with
limesdr mini and the software "drops data". I will gladly try to debug
or narrow this down,
but ask for some suggestions on how to proceed. One thought is to save a
timestamp each time through readSamples and compare to some constant
to determine that the problem is NOT that we are unable to read as fast
as required. reading 2500 samples would take 2.3 mS if I understand
this, so we need
to cal readsamples at about this rate....
Possible causes could be something *else* locking out the program.