18 Jun
2012
18 Jun
'12
1:37 a.m.
On Mon, Jun 18, 2012 at 5:32 AM, Thomas Tsou <thomastsou(a)gmail.com> wrote:
On Mon, Jun 11, 2012 at 7:12 AM, Alexander Chemeris
<alexander.chemeris(a)gmail.com> wrote:
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.
--
Regards,
Alexander Chemeris.
CEO, Fairwaves LLC / ООО УмРадио
http://fairwaves.ru
On Mon, Jun 11, 2012 at 4:08 AM, Thomas Tsou
<thomastsou(a)gmail.com> wrote:
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. 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?