This is merely a historical archive of years 2008-2021, before the migration to mailman3.
A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/UmTRX@lists.osmocom.org/.
Thomas Tsou thomastsou at gmail.comOn Mon, Jun 11, 2012 at 7:12 AM, Alexander Chemeris <alexander.chemeris at gmail.com> wrote: > On Mon, Jun 11, 2012 at 4:08 AM, Thomas Tsou <thomastsou at 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. Thomas -------------- next part -------------- A non-text attachment was scrubbed... Name: umtrx_rsa1.JPG Type: image/jpeg Size: 111174 bytes Desc: not available URL: <http://lists.osmocom.org/pipermail/umtrx/attachments/20120617/9571175f/attachment.jpe> -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-transceiver-workaround-for-transmit-testing-with-no-.patch Type: application/octet-stream Size: 3048 bytes Desc: not available URL: <http://lists.osmocom.org/pipermail/umtrx/attachments/20120617/9571175f/attachment.obj>