From: Sylvain M. <24...@gm...> - 2011-08-05 13:49:16
|
Hi, > 1312549290.0930 ERROR 3068681072 UHDDevice.cpp:497:check_rx_md_err: UHD: Loss of monotonic: 22.7704 > 1312549290.0931 ERROR 3068681072 UHDDevice.cpp:498:check_rx_md_err: UHD: Previous time: 22.7731 > 1312549290.1033 ERROR 3068681072 UHDDevice.cpp:497:check_rx_md_err: UHD: Loss of monotonic: 22.7762 > 1312549290.1034 ERROR 3068681072 UHDDevice.cpp:498:check_rx_md_err: UHD: Previous time: 22.7789" > > This is quite as I would have expected it. To me this seems to be solely related to the unstable clock issue, am I correct here? No. 1) The default clock is not 'unstable', it just has an unpredictable offset that's outside of gsm spec. 2) This offset would not cause this kind of report. This looks more like network issues that cause the timestamps to not be continuous. Or CPU issues causing network delays / dropped packets / whatever ... > However, also when I am trying to run it with the external clock, it does does work. In this case I do not get an underrun, but after approximately 2 minutes (power is at his max) I get the usual "ALARM 3069414256 TRXManager.cpp:90:clockHandler: TRX clock interface timed out, assuming TRX is dead." and the log says: > > "1312548259.0907 ERROR 3068640112 UHDDevice.cpp:624:writeSamples: UHD: Sent fewer samples than requested" > > In all cases I never see the network on my mobile. I should note that it works nicely using my USRP1 and my mobile and using a similar config file (e.g. same band, ...) > > It seems to me, that this is a clocking issue (again...). But the software provided with the clock says it is correctly adjusted to 10Mhz and the output should also be quite precise, we measured and adjusted it with guys from our electronics lab... Did you check that the USRP work at all using the external reference ? (i.e. using usrp_fft and trying to view a know signal or something). Cheers, Sylvain |