UmTRX integration with OpenBTS

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.com
Mon Jun 18 01:32:06 UTC 2012


On 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>


More information about the UmTRX mailing list