UmTRX June 2012

umtrx@lists.osmocom.org

6 participants
4 discussions

UmTRXv2 final project
by Andrey Sviyazov 30 Jul '12

30 Jul '12

Hi all! Here last version PCB of UmTRXv2. In the next e-mail I'll include project files and cheapest BOM for debug variant. I think it is final, because of nobody desire to say me any suggestions (except Robin). Best regards, Andrey Sviyazov.

3 47

UmTRX integration with OpenBTS
by Alexander Chemeris 21 Jun '12

21 Jun '12

Hi Thomas, If we get a UmTRX to you, could you make OpenBTS to run with it quickly, like before the end of the month? No matter how hackish the solution would be. We just need a way to start testing the hardware performance in a more real situation. Then we could target a cleaner solution. To recap - right now we could transmit on a single channel, and receive on both channels, but the control of LMS chips is done by an external python script. I.e. to tune and set bandwidth, gain, etc you have to run this script before claiming a device with UHD. -- Regards, Alexander Chemeris. CEO, Fairwaves LLC / ООО УмРадио http://fairwaves.ru

4 19

UmTRX timestamp bug Was: UmTRX integration with OpenBTS
by Alexander Chemeris 18 Jun '12

18 Jun '12

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: >> On Mon, Jun 11, 2012 at 4:08 AM, Thomas Tsou <thomastsou(a)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. -- Regards, Alexander Chemeris. CEO, Fairwaves LLC / ООО УмРадио http://fairwaves.ru

1 0

UmTRX UHD branches clean up
by Alexander Chemeris 17 Jun '12

17 Jun '12

Hi all, I've cleaned up our git branches to make sure everyone are on the same page. Now a stable code (if could say so) is in 'fairwaves/umtrx' branch. I.e. you should build FPGA image, ZPU firmware and UHD host code from this branch. Other branches are topic branches, owned and maintained by respective developers for their very own purposes and you're not warranted from any consequences of using them, including, but not limited to disappearance of your cat. (I apologize for the language - just finished reading a 15 page long contract) -- Regards, Alexander Chemeris. CEO, Fairwaves LLC / ООО УмРадио http://fairwaves.ru

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

UmTRX June 2012