On Mon, Jun 18, 2012 at 5:32 AM, Thomas Tsou thomastsou@gmail.com wrote:
On Mon, Jun 11, 2012 at 7:12 AM, Alexander Chemeris alexander.chemeris@gmail.com wrote:
On Mon, Jun 11, 2012 at 4:08 AM, Thomas Tsou thomastsou@gmail.com wrote:
If the load drops down and the signal transmits, I wouldn't worry about it for now. The likely condition is that there is a offset between the initial arriving timestamp and the expected timestamp. Because the receive timestamps drive the transceiver, the receiver may run at 100% until the timestamp and expected value align. If OpenBTS transmits consistently, then the system is in sync.
Aah! Yes, we have some issue with setting the timestamp with UmTRX. E.g. I had to modify UHD examples which set timestamp to 0 on startup and rely on this later on. With my change they read the actual value of the timestamp and start from that. Could we do the same for OpenBTS?
I'm running into this issue now, which was the reason I wasn't always seeing transmit output. Workaround patch is attached along with the corrected 'normal' rate GSM signal.
Thanks for the patch! I think we could push it to the OpenBTS repom as it doesn't harm anyone?
Sylvain - with your great debugging abilities, could you find the cause for this bug without too much trouble? To me it looks like the bug is in FPGA firmware, i.e. something went wrong with the VITA timer control when we changed frequencies of the DSP part of the FPGA. The bug is not critical, but is really annoying, because you have to change all UHD utils to avoid setting a timestamp before use.