Current status:osmo-trx-lms can be compiled and started. It sends and receives bursts, but there seem to be some clock-related issues.

in osmo-bts-trx, we can see the clock ind calculations showing a permanent drift of error_us=[-77XXX,-80XXXX], indicating that the clock at osmo-trx is going too fast. Output from ettus b200 running with UHD suggests that the limesdr clock is running around 4 times faster than it should.

The clock indication is driven by the Receive path in osmo-trx as far as I can tell.

The timestamps received while calling LMS_RecvStream show a bit of strange behaviour as how I udnerstand it. To give an example, at start() time I added a flush_recv function like it's done for UHD, in order to sync the radioInterface class clock with the one from the device. It basically runs 10 times in a loop calling "MS_RecvStream(&m_lms_stream_rx0, &buffer0, len, &rx_metadata, 100);" with len=2500. I then print the received timestamp in hex after each call (no sleep in between), and that's what I get:

So it can be seen that the first 2 ties I call the function, when I check it next the timestamp has been increased by the same amount of samples I asked for, ie 0x9c4=dec2500. However, On Forth call, it can be seen that the timestamp has increased for more than that value, 4d1c - 1388 = 14740 samples. Why this value?