UmTRX

umtrx@lists.osmocom.org

189 discussions

[ANNOUNCE] UmTRX sales start on the Hardware Freedom Day
by Alexander Chemeris 21 Apr '13

21 Apr '13

Dear all, (I'm sorry for cross-posting to several mailing lists, but it really belongs to all of them. Please respond only to a mailing list you're subscribed to.) UmTRX sales start =============== It's the Hardware Freedom Day and we're starting sales of UmTRX to celebrate it! Now you could order it directly from Fairwaves web-shop [1], UmTRX is a completely open-source hardware SDR transceiver designed for professional/industrial applications. We designed it for use with OpenBTS software [2], but it also works well with OsmoBTS/OpenBSC [3]. UmTRX uses a UHD [4] with only minor changes to interact with a host and thus works well with GnuRadio and other applications based on UHD. 1. http://shop.fairwaves.ru/ 2. https://code.google.com/p/umtrx/wiki/RunningOpenBTS 3. http://openbsc.osmocom.org/trac/wiki/OsmoBTS 4. https://github.com/fairwaves/UHD-Fairwaves Technical details ============== UmTRX is an SDR transceiver inspired by USRP N series. If you worked with USRP N you will find it familiar, but there are significant differences which are described below as well. * Single board with an integrated RF part. * Optimized for industrial use and high MTBF. * 1GbE Ethernet connectivity to a computer. * Two full-duplex RF channels (side "A" and "B" in UHD). * Single chip transceivers LMS6002D are used for AD/DA and RF processing (300MHz to 3.8GHz) * Stable reference clocks: - 26MHz TCXO (integer multiple of GSM sample rate) with 100ppb frequency stability. - DAC for TCXO frequency fine tuning. - Integrated GPS module for automatic TCXO frequency stabilization. - External clock source is possible. * Thermal sensors for temperature based calibration. * 100mW @ 900MHz, 50mW @ 1800MHz RF output power. * 8-28V DC input power supply. * Spartan 6 LX75 FPGA. PS Big thank you to Lime Microsystems for their excellent support of open-source users! Check out their chips if you're planning to develop and SDR system. GSM specific info ============== UmTRX was designed to be easy to use to use with OpenBTS and OsmoBTS. So far it's the easiest way to get them up and running in your lab. * Quad-band support without any changes * 100-200m coverage (with an external duplexer and a small omni antenna). * >2km coverage with an external 2W GSM repeater and a patch antenna * Two independent TRXs (*). * Single-ARFCN and Multi-ARFCN support. (*) OpenBTS doesn't support the second channel on UmTRX yet. We're working to implement this and plan to release this soon. I also want to say thank you to our beta testers who received earlier versions of UmTRX. Some of them even blogged about their experience :) http://blog.shimaore.net/2013/03/umtrx.html http://genesysguru.com/blog/blog/2013/03/23/umtrx-is-alive-again/ UmTRX package contents ======================== * UmTRXv2.1, flashed and ready to use. * Power supply, 12V/30W - http://www.phihong.com/assets/pdf/PSAC30U.pdf * U.FL-to-SMA-F pigtail cables. * Two small GSM antennas - one for Tx and one for Rx. * An active GPS antenna. * Thermal pads. Note 1: The power supply comes without a 220V power cord. Make sure to prepare one before you receive the UmTRX to be able to power it on immediately. ;) Note 2: You'll need a heatsink or a fan to prevent UmTRX from overheating during long continuous operation. We provide thermal pads, but you have to find a heatsink by yourself. HDD heatsinks are good options, because UmTRX has almost the same size as an HDD. -- Regards, Alexander Chemeris. CEO, Fairwaves LLC / ООО УмРадио http://fairwaves.ru

1 0

CID / LAC / C1 / C2 broadcast
by joel yabut 21 Apr '13

21 Apr '13

Alex, Anyone know the problem if my Cell ID, LAC, C2 / C2 appears blank on my TEMS investigation when I am monitoring my BTS? Transmit power is good but despite my setting up and putting values on CID/LAC they are blank on my TEMS. Anyone knows why this is so? Thanks! Joel

2 1

OpenSIPS Was: transceiver won't start; fpga build error
by Alexander Chemeris 14 Apr '13

14 Apr '13

Hi Stephane, On Wed, Mar 6, 2013 at 4:20 AM, <stephane(a)shimaore.net> wrote: >> Thank you for your patch to make it working with OpenSIPS :) Looking >> forward for more contributions to the SIP side of things. > > My line of thought is to use OpenSIPS as registrar, with a Redis > backend. Then use OpenSIPS to route calls, SMS, .. based on the IMSI. It seems that using OpenSIPS as much as possible is a good way for scalability, instead of trying to get Freeswitch to scale. At least that's what I was suggested. So I wonder what we could actually offload to OpenSIPS. Do you think we could use OpenSIPS not only as a registrar, but also as an authentication server? And what do you think about routing calls with it? I was told that the best way to get it to scale is to use static routing, i.e. without an access to an external DB. But now the problem is that subscribers move from a BTS to a BTS and it can't be completely static. One solution is to actually have Location Areas as in GSM and use broadcasted SIP INVITEs in them. Or alternatively we could do some "virtual LA" on SIP level by creating a layered set of OpenSIPS instances. SMS is another issue, because it requires a "store and forward" server. Did you know an existing solution for that? Or is it easier to just write the thing from scratch :) -- Regards, Alexander Chemeris. CEO, Fairwaves LLC / ООО УмРадио http://fairwaves.ru

2 8

This is sweet! ---> Re: Network From Scratch documentation
by Martin O'Shield 10 Apr '13

10 Apr '13

On Tue, Apr 9, 2013 at 8:01 AM, Alexander Chemeris < alexander.chemeris(a)gmail.com> wrote: > Hi all, > > Thanks to Andreas everyone now could run an OsmoBTS/OpenBSC using an > UmTRX to get a real BTS. You could also use LCR to connect calls using > your preferred SIP softswitch. > > This is a great achievement, as OsmoBTS seem to have a better and more > stable GSM implementation than OpenBTS. So we even think about > replacing GSM part of OpenBTS with Osmocom parts. And, well, OpenBTS > SIP part with a high-level SIP library like reSIProcate/DUM. Though it > will be OpenBTS only by architecture then. :) > > Anyway, I invite everyone to experiment with UmTRX+OsmoBTS and report > your experience here. > > ---------- Forwarded message ---------- > From: jolly <andreas(a)eversberg.eu> > Date: Tue, Apr 9, 2013 at 4:14 PM > Subject: Network From Scratch documentation > To: OpenBSC Mailing List <openbsc(a)lists.osmocom.org> > > > hi, > > i just updated the transceiver/osmo-bts/openbsc/lcr documentation: > http://openbsc.osmocom.org/trac/wiki/network_from_scratch > the changes refer to some issues during UmTRX/Osmo-BTS workshop. > especially it describes how to setup/run a network with and without LCR. > > regards, > > andreas > > > > > -- > Regards, > Alexander Chemeris. > CEO, Fairwaves LLC / ООО УмРадио > http://fairwaves.ru > >

2 1

Fwd: Network From Scratch documentation
by Alexander Chemeris 09 Apr '13

09 Apr '13

Hi all, Thanks to Andreas everyone now could run an OsmoBTS/OpenBSC using an UmTRX to get a real BTS. You could also use LCR to connect calls using your preferred SIP softswitch. This is a great achievement, as OsmoBTS seem to have a better and more stable GSM implementation than OpenBTS. So we even think about replacing GSM part of OpenBTS with Osmocom parts. And, well, OpenBTS SIP part with a high-level SIP library like reSIProcate/DUM. Though it will be OpenBTS only by architecture then. :) Anyway, I invite everyone to experiment with UmTRX+OsmoBTS and report your experience here. ---------- Forwarded message ---------- From: jolly <andreas(a)eversberg.eu> Date: Tue, Apr 9, 2013 at 4:14 PM Subject: Network From Scratch documentation To: OpenBSC Mailing List <openbsc(a)lists.osmocom.org> hi, i just updated the transceiver/osmo-bts/openbsc/lcr documentation: http://openbsc.osmocom.org/trac/wiki/network_from_scratch the changes refer to some issues during UmTRX/Osmo-BTS workshop. especially it describes how to setup/run a network with and without LCR. regards, andreas -- Regards, Alexander Chemeris. CEO, Fairwaves LLC / ООО УмРадио http://fairwaves.ru

1 0

I'm done with RRLP!
by Craig Reading 09 Apr '13

09 Apr '13

PHew! - finally finished my experiments with RRLP. Full details at www.genesysguru.com In summary: range error=ephemURA of xx.0 (xx) doesn't fit in (0,15) The problem seems to be that SV accuracy in metres is being used as the URA index. The confusion arises due to differences between the Receiver Independent Exchange Format (RINEX) 2.10 format and Interface Specification IS-GPS-200 (http://www.gps.gov/technical/icwg/). IS-GPS-200 section 20.3.3.3.1.3 states: ”SV Accuracy - Bits 13 through 16 of word three shall give the URA index of the SV. The URA index (N) is an integer in the range of 0 through 15.” RRLP server needs to be modified to support RINEX and specifically to add a mapping from SV accuracy to URA index. For now I changed line 1084 in rrlpserver.erl to assume a URA index of 6 e.g. SV accuracy in the range 13.65 – 24 metres: stuff("ephemURA", nmth(7,1,Tokens), AdjustTable), Change to: stuff("ephemURA", “6” , AdjustTable), With Control.Call.QueryRRLP.Early OpenBTS option configured a crash occurs. OpenBTS: ../CommonLibs/Vector.h:189: void Vector<T>::copyToSegment(Vector<T>&, size_t, size_t) const [with T = char, size_t= unsigned int]: Assertion `base+span<=other.mEnd' failed. Hence the solution for now is to unconfigure this option: unconfig Control.Call.QueryRRLP.Early It looks at though the Almanac file downloaded from http://www.navcen.uscg.gov/?pageName=currentAlmanac&format=yuma is saved into /tmp/almanac as HTML rather than plain text: As a quick fix I changed my Almanac URL: config GSM.RRLP.ALMANAC.URL http://celestrak.com/GPS/almanac/Yuma/almanac.yuma.txt My final configuration options are: config GSM.RRLP.ACCURACY 40 config GSM.RRLP.ALMANAC.ASSIST.PRESENT 1 config GSM.RRLP.ALMANAC.URL http://celestrak.com/GPS/almanac/Yuma/almanac.yuma.txt config GSM.RRLP.EPHEMERIS.ASSIST.COUNT 3 config GSM.RRLP.EPHEMERIS.REFRESH.TIME 0.5 config GSM.RRLP.RESPONSETIME 6 Hope this helps! I'm moving on to experiments with Uplink-Time Difference of Arrival (U-TDOA) methods for locating mobile devices with a bit of GSM burst data analysis , Complex Event Processing (CEP) and data correlation thrown in …. I call this Mobile Fingerprinting … lets see! Regards Craig

2 1

RRLP success!
by Craig Reading 06 Apr '13

06 Apr '13

Finally manage to get an iPhone running iOS 6 to cough up a location response! It is a bit hit and miss at present. Along the way I think I've found a couple of bugs in the fairwaves openBTS branch. I've started posting my experiences at www.genesysguru.com More posts over the weekend. Great fun! Regards Craig

1 0

RRLP update (range error=ephemURA of xx.0 (xx) doesn't fit in (0, 15) )
by Craig Reading 04 Apr '13

04 Apr '13

Fetched “CurRnxN.nav” from ftp://ftp.trimble.com/pub/eph/and had a look at the raw data. The .nav data file is formatted as Receiver Independent Exchange Format (*RINEX*) 2.10 and contains GPS navigation methods. SV accuracy is defined in Broadcast Orbit Record 6 and this value is used as the URA at line 1084 of rrlpserver.erl. The problem seems to be that SV accuracy in meters is being used as the URA *index*. The confusion arises due to differences between the Receiver Independent Exchange Format (*RINEX*) 2.10 format and Interface Specification IS-GPS-200 (http://www.gps.gov/technical/icwg/). IS-GPS-200 section 20.3.3.3.1.3 states: ”SV Accuracy - Bits 13 through 16 of word three shall give the URA index of the SV. The URA index (N) is an integer in the range of 0 through 15.” Hence I think the RRLP server needs to be modified to support RINEX and specifically to add a mapping from SV accuracy to URA index like in the code example here: http://www.gpstk.org/doxygen/GPS__URA_8hpp-source.html#l00109 For now I changed line 1084 in rrlpserver.erl to assume a URA index of 6 e.g. SV accuracy in the range 13.65 – 24 meters: stuff("ephemURA", nmth(7,1,Tokens), AdjustTable), Change to: stuff("ephemURA", “6” , AdjustTable), Can any Erlang programmers help fix this?

1 0

RRLP update
by Craig Reading 04 Apr '13

04 Apr '13

A quick update ahead of some full blown documentation on my blog. 1. You need to set your GPS seed position: The GPS positioning signal has a period of 1 ms, corresponding to a distance of about 300 km. This means that there are many potential solutions for the GPS positioning equations in an irregular lattice around the Earth. If the GPS receiver does not know its true position within about 200 km, it must check all of these potential solutions in a brute force search before making a reliable position estimate, a process that can take 20 minutes or longer. To avoid this delay, the GPS receiver requires a seed position within 200 km of its true location: config GSM.RRLP.SEED.ALTITUDE xx config GSM.RRLP.SEED.LATITUDE xx.xxxxxx config GSM.RRLP.SEED.LONGITUDE xx.xxxxxx Note: You can find your own latitude, longitude and altitude (in meters) for the seeds here: http://veloroutes.org/elevation 2. Make sure your server time is correct: Current time must be known to within a few seconds to make rough estimates of satellite position and bootstrap the positioning calculations. Like seed position, rough time can determined through a brute-force search, but that is very time-consuming. With OpenBTS the rough current time comes from the time-of-day clock on the machine running the RRLP server. 3. There are 4 OpenBTS configuration options which determine when a RRLP query is performed: e.g. during call setup, during call teardown, during a Location Update Request (LUR) or during a SMS: config Control.Call.QueryRRLP.Early 1 config Control.Call.QueryRRLP.Late 1 config Control.LUR.QueryRRLP 1 config Control.SMS.QueryRRLP 1 QueryIMEI determines if the MS is checked to see if it supports RRLP: config Control.LUR.QueryIMEI 1 4. A common problem as widely reported and also obsered by myself is: range error=ephemURA of xx.0 (xx) doesn't fit in (0,15) In RRLPServer.cpp this causes method transact to return early without as MS location being determined (and table RRLP being written to). This error is output in roundAndCheck at line 912 in rrlpserver.erl URA stands for User Range Accuracy. The URA index defined bounds are -16 to 15. The valid range for ephemURA data is defined in the ephemeris Adjustment Table that is used for Ephemeris corrections, scaling, etc at line 1164 in rrlpserver.erl e.g. 0-15. The adjustment table defines: Correction, Scale, Min, Max I suspect that the problem is that a negative number is being returned in the GPS ephemeris data e.g. in ftp://ftp.trimble.com/pub/eph/CurRnxN.nav - at the very least the correct URA bounds are -16 to 15 rather than 0 to 15. My hack (for now) is: {"ephemURA", [0, 0, -16, 256]}, I'll carry on trying to get to the bottom of this error and fix it properly. Regards Craig

1 0

RRLP
by Craig Reading 03 Apr '13

03 Apr '13

Before I start "playing" with RRLP in OpenBTS 2.8 with UmTRX I'm just wondering if anybody has some current advice. I note in CLI.cpp: //apparently non-function now -kurtis //addCommand("sendrrlp", sendrrlp, "<IMSI> <hexstring> -- send RRLP message <hexstring> to <IMSI>."); There are plenty of atricles out there e.g. http://wush.net/trac/rangepublic/wiki/rrlp http://www.mentby.com/Group/openbts-discuss/question-regarding-the-rrlp-in-… Basically, does it work and hence worth persuing? Regards Craig

3 5

← Newer
1
...
5
6
7
8
9
10
11
...
19
Older →

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

UmTRX