On Wed, Jun 14, 2017 at 3:47 PM, Alexander Chemeris
<alexander.chemeris(a)gmail.com> wrote:
USB based SDRs like USRP B2x0 have hard time keeping
the Tx/Rx alignment
when there are any disturbances. So osmo-trx features a sophisticated
algorithm to maintain this alignment for USB based devices. Thomas has spent
tremendous effort tuning it to perform well, but may be there are edge cases
which are not handled there yet. Let's wait for his comments.
The 'clock' issue is occurring between osmo-bts and osmo-trx and not
between osmo-trx and the device. For the latter, irregular packet
timing would appear as underruns, overflows, late packets, etc. -
errors non-specific to GSM numerology.
There are timing considerations at startup because the device needs
time to initialize. In the case of the B200 on first boot, the startup
time is especially long because of the FPGA load. Running the
uhd_usrp_probe utility will give an indication of the device
initialization time. On top of that delay, osmo-trx could add another
second for Tx/Rx synchronization purposes.
If clock skew is not occurring at startup, then process scheduling is
probably related. If the flow of CLK IND stops entirely, as in the
case when osmo-trx stops running, the message would be "No clock from
osmo-trx". Clock skew could also occur because of variability in
calling gettimeofday(), but I have not encountered that on any systems
that I run.
-TT