UmTRX

umtrx@lists.osmocom.org

189 discussions

Re: [rfc] git workflow model
by Alexander Chemeris 16 Jul '12

16 Jul '12

Hi, On Sun, Jul 15, 2012 at 8:48 PM, ☎ <Max.Suraev(a)fairwaves.ru> wrote: > Hello. > > I'd like to test new ML anyway so here is my question :) > > I've stumbled upon pretty interesting $subj at > http://nvie.com/posts/a-successful-git-branching-model/ (Russian translation is > available at http://habrahabr.ru/post/147260/ ). > > What do you think of it guys? Should we try to adopt it? Or at least document > whatever model we use now? I need some time to read the post, but in general it's a good idea to describe branching policy. -- Regards, Alexander Chemeris. CEO, Fairwaves LLC / ООО УмРадио http://fairwaves.ru

1 0

UmTRX prototypes cost
by Alexander Chemeris 15 Jul '12

15 Jul '12

Hi Jean-Samuel, Could you share the prices you get for UmTRX from your fab for this batch of prototypes and for the next batches? We have to understand the cost price to see what could we offer to customers. -- Regards, Alexander Chemeris. CEO, Fairwaves LLC / ООО УмРадио http://fairwaves.ru

2 6

UmTRX goes public
by Alexander Chemeris 15 Jul '12

15 Jul '12

Hi all, As UmTRX release gets closer, i want to gradually move all related documentation, discussions, news, etc to public. The plan is to move everything under the Osmocom umbrella, because it's a good neighborhood for UmTRX. Omsmocom.org server is somewhat overloaded now, so for the time being all git repos will stay at github and wiki and files will stay at Google Code. They will be moved to osmocom.org when they upgrade their server. Mailing list is not a big load, so the UmTRX public mailing list has been created as umtrx(a)lists.osmocom.org. Some of you already received subscription e-mails, everyone else is encouraged to subscribe as well. You could do that with the web interface here: http://lists.osmocom.org/cgi-bin/mailman/listinfo/umtrx Please use the public mailing list for all technical discussions from now on. "Project-mayotte" and "gsm-internal" are to be used for business and manufacturing related, private or other highly 533kr337 discussions. I'm going to publish schematics today together with some brief description of features. Public Lime documentation will be published as well. -- Regards, Alexander Chemeris. CEO, Fairwaves LLC / ООО УмРадио http://fairwaves.ru

1 0

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

UmTRX v1b coming soon
by Andrey Sviyazov 31 May '12

31 May '12

Arrived to a place of relaxation and... started to work :( There are questions about EB-570: 1) Is it used somewhere? In the datasheet there is probable errors, for example, 1PPS is specified as input. 2) There are inputs Reset and Standby. The first can be left open, and the second is possible need to be connected to to FPGA. 3) There Is RTC_CLK_O we don't need him? And that there may be, 32768? 4) Which of two UART's better to use or are they equivalent? There are no any words in datasheet about it. 5) Unfortunately no place for both on PCB and we can use either EB-230 or EB-570. Best regards, Andrey Sviyazov.

4 10

Fwd: UmTRX UHD firmware
by Alexander Chemeris 23 Apr '12

23 Apr '12

Hi all, Attached is an UHD-based FPGA image for UmTRX. We've just fixed one last bug in the Tx chain and I think it's a good time to let everyone know about the progress. Corresponding host software could be built from the 'fairwaves/umtrx-dboard' branch in our repo: https://github.com/chemeris/UHD-Fairwaves/tree/fairwaves/umtrx-dboard Notes: 1. UHD code doesn't touch LMS configuration at all. So all LMS configuration should be done before you run UHD tools with the help of 'umtrx_lms.py' utility. This includes turning on LMS Rx/TX modules, tuning, calibration, amplifiers configuration, etc: https://github.com/chemeris/UHD-Fairwaves/blob/fairwaves/umtrx-dboard/host/… 2. So far only Tx has been tested and is known to work fine. Rx testing is our next target. 3. LMS works at 13 MSPS and UHD allows you to go up to this rate. Interpolation in Tx chain is known to work well, so you could also use fractions of that rate, like 0.270833 MSPS ;) 4. It's strongly recommended to tune VGA1 DC offset in a LMS before using - it reduces LO leakage by very nice 25 dB. 5. We still have to figure out how to tune I/Q balance in UHD. Without calibration LMS doesn't perform very well. I know it should be pretty straightforward to do, but we have to figure out how. -- Regards, Alexander Chemeris. CEO, Fairwaves LLC / ООО УмРадио http://fairwaves.ru

1 1

Selectivity improvement solutions proposal for UmTRX
by Jean-Samuel Najnudel - BJT PARTNERS SARL 23 Apr '12

23 Apr '12

Hi Alexander, These last days, I tried to find a solution for the selectivity improvement. I have 5 solutions to propose. 1st and 2nd are inboard solutions. 3rd, 4th and 5th uses an external board. Some seems to be much better than others. 1/ We could use an IF frequency above 375 MHz to be able to connect the IF signal dirtectly to the LMS, without any upconvertion back to RF frequency. This would save some components. We could use the ADRF6601 (PLL/VCO + mixer) and the TB0448A IF SAW filter. The ADRF6601 is single chip PLL/VCO and mixer. This would be quite convenient. The TB0448A is cheap (< 3 USD), narrow band (good selectivity) and 400 MHz center frequency (> 375 MHz LMS lower limit). Cost of this solution would be about 60 USD and selectivity would be really good. The main disadvantage of this solution is the filter would restrict the signal to a single GSM carrier. This would avoid us to get both GSM carriers on each LMS. We would not be able to get true diversity. We would only be able to get switched diversity. After the LNA, RF SAW filter and the RF switches, we can split the signal between the current RX path to LMS RX LNA 3 and a new alternate RX path (ADRF6601 => TB0448A => LMS RX LNA 1). Depending of our need for selectivity, we would be able to select 1 of these 2 RX path (direct RX path to LMS RX LNA 3 or IF filter RX path to LMS RX LNA1). This would allow to use the board either as a normal wideband SDR board or with a very selective filter. 2/ A very nice option would be to use a variant of the 1st solution with a wider bandwidth SAW IF filter. For example, if we use a 400 to 600 KHz bandwidth IF filter, we would also get a very good selectivity and we would also be able to sample both GSM carriers on each LMS. This would allow a good selectivity and full diversity. The problem is we would need a 400 to 600 KHz SAW IF filter, with good selectivity, reasonable price and an IF center frequency above 375 MHz. I was not able to find such a filter. 3/ As suggested a few days ago, we may use the external selectivity improvement board design I sent you. Instead of the Triquint 856378 IF SAW filter, we could use the TAISAW TB0448A narrow band filter. This TAISAW filter is really much cheaper than the Triquint. This would save a lot of budget. However, we would still need 4 mixer and 2 PLL/VCO for each LMS RX path. This external board would cost approximately 100 USD (excluding PCB and assembly). We would need 2 of these boards for each UmTRX board. This would make 200 USD per UmTRX. Including PCB and assembly, toatl cost would be around 300 USD. This is not compeltely unrealistic but it seems still quite expensive. 4/ Another solution would be to build a single carrier version of the 3rd solution design. We would need only 1 RF path (PLL/VCO + mixer) with only 1 narrow band filter per LMS RX path. This would not need any splitter or combiner. Design would be quite simple and cost would be about 2 times lower. However, as we will have only 1 carrier on each antenna, we would not be able to get diversity at all. This solution would finally not have many advantages compared to 1st solution. It would cost more and would not allow any kind of diversity. 5/ Last solution would be to build an external diversity improvement board, as 4th solution, but with a wider band IF SAW filter. We could use the following RF path: LNA => RF SAW filter => mixer => IF SAW filter => mixer => RF SAW filter. Dual mixer could be the ADL5802 connected to the ADF4350 PLL/VCO. We could use the TB0218A IF SAW filter. This filter is quite affordable (< 10 USD). Selectivity is good and bandwidth is wide enough to select 2 GSM carriers (separated by 400 KHz). Cost of such external diversity improvement board would be quite reasonable. This would be a very nice solution to select 2 GSM carriers. Connected to the UmTRX, this selectivity improvement board would allow to get both switched or true diversity. As TB0218A center frequency is 140 MHz, we would not be able to connect directly the IF signal to the LMS. We would need to up convert the signal back to the RF frequency. As IF down converted signal is upconverted back to the original RF frequency, it would be possible to use this selectivity improvement board with any kind of existing OpenBTS (UmTRX, USRP, SSRP...) or OpenBSC (Sysmocom BTS, IP.access nanoBTS...) hardware to improve the Rx selectivity. This would offer a wider potential market than an inboard solution. Considering all these solution, I believe 1st and 5th solutions seems to be the best choices. 2nd solution would also be really nice but I was not able to find the appropriate IF SAW filter. Please let me know your opinion regarding each of these two solutions. By the way, the TB0448A and TB0218A SAW filters looks really good but I am not 100% sure the GSM carrier spectrum distortion due to the pass band ripple of the SAW filter is acceptable. Center part of the GSM carrier (f +/- 100 KHz) is fine but side parts of the GSM carrier (bellow f - 100 KHz and above f + 100 KHz) may be cut a bit by the SAW filter. Could you also please check the TB0448A and TB0218A datasheets to double check if the usable bandwidth is wide enough ? Especially, do you think cutting a bit the side parts of the GSM carrier may cause problem ? Anyway, please let me know your point of view regarding these selectivity improvement solutions. Best regards. Jean-Samuel. :-)

4 31

UmTRX hardware development plan
by Alexander Chemeris 23 Mar '12

23 Mar '12

Andrey Sviyazov, I think this question is mostly for you. Could you please outline the development plan for the UmTRX hardware (with all associated things, like RF board design)? What are critical dependencies? E.g. when we should decide on the casing? My feeling is that we've lost the track and focus on things which are important, but not at this stage. -- Regards, Alexander Chemeris. CEO, Fairwaves LLC / ООО УмРадио http://fairwaves.ru

3 2

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

UmTRX