Hello,
I was wondering whether there is an FPGA image for the UmTRX which gives 4x
DDC Rx chains (at the expense of the two DUC chains) like the USRP1
usrp1_fpga_4rx.rbf. I guess this is unlikely, due to the fact it looks like
the majority of people are using the UmTRX for OpenBTS! How difficult would
it be to change the current firmware to support this.
Another couple of questions, what's the maximum achievable bandwidth
through a single Rx chain so far and are there any constraints on what
value of decimation to use (e.g. USRP has the requirement that to use both
CIC filters decimation factors have to be a factor of 4, otherwise the
frequency response will be affected)? When I increase the sample rate (e.g.
4.333 MHz) I start seeing the frequency response affected, the FFT plot
seems to 'flicker' between a reasonably flat looking response and a poor
frequency response (see attached files - both taken from the same running
instance of a flow graph)
Cheers,
John
--
*Dr. John Wilson*
Product development engineer, Path
Intelligence<http://www.pathintelligence.com/>
T +44 2392 388442 @pathintel
DETECT • ANALYSE • PREDICT • INFLUENCE
Path Intelligence Limited, registered number 5176274. Registered in
England,
registered office at 1000 Lakeside North Harbour, Western Road, Portsmouth,
UK, PO6 3EN
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.htmlhttp://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
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
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
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
>
>
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
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
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
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?
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
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/rrlphttp://www.mentby.com/Group/openbts-discuss/question-regarding-the-rrlp-in-…
Basically, does it work and hence worth persuing?
Regards
Craig