First of all, we need to design a signal processing algorithm. The GNU Radio package contains a frontend graphical interface designated for design signal processing flow graphs that may ease our work. It could be found in Application Center with GRC name, which means GNU Radio Companion. GRC automatically creates python programs for the required SDR blocks.

Let’s start with adding of USRP Source from UHD tab to the workspace of GRC. USRP Source is the abstraction layer that allows communication with a hardware. It produces digital signal which will be consumed by the next blocks in our flow graph. The source block tells our SDR to turn on receive mode.

The next block we are going to add is QT GUI FFT Sink under Instrumentation tab. This one helps to visualize the frequency components. To connect the blocks, just click on the «out» of the Source and then on the «in» of the FFT Sink. USRP Source title changed color from red to black, which means that output properly connected with input of the next block. If QT GUI FFT Sink title is still red, then probably we have WX GUI enabled in Generate Options (top block). If we change that option to the QT, the FFT Sink will also become black. QT (http://www.qt.io/) and WX (https://www.wxwidgets.org/) just different libraries with graphical user interface elements.

It’s necessary to increase sample rate in samp_rate variable to be able to register the GSM signal. 1 million would be enough. Let us also create another variable center_freq to be able to change the central frequency in one place. Now we can set center_freq in both blocks and change it in Variable block if needed.

Our lab Base Transceiver Station (BTS) transmits downlink signals at 949.8 MHz and receives uplink signals at 904.8 MHz. If you don’t know exactly GSM frequencies transmitted near you, you may scan them using GNU Radio uhd_fft tool or software like gqrx (http://gqrx.dk/).

We will listen at 949.8 MHz first to catch some broadcast channel signals.

Push «Execute the flow graph» button to catch some radio waves!

Here it is! The downlink GSM signal at 949.8 MHz.

We will use Ubuntu 14.04 for our purposes. Basically, it’s possible to use any Ubuntu system, but we tested everything on 14.04 and guarantee that it will work fine. UHD library built with loadable modules support could be downloaded from Josh Blum’s PPA. Thus, we need to open Terminal and enter:

$ sudo apt-get install python-software-properties
$ sudo add-apt-repository ppa:guruofquality/pothos

Python-software-properties provides the add-apt-repository binary, which is necessary to install a new ppa (Personal Package Archive, is a collection of software not included in Ubuntu by default, https://help.launchpad.net/Packaging/PPA) easily. Pothos repository contains a proper UHD package for UmTRX. Update the cache of the Software Center repository:

$ sudo apt-get update

To install UHD driver from that repository, we should open Ubuntu Software Center. From drop-down menu of All Software button choose Pothos and scroll down until «uhd» package appears. That’s the one we need to install.

It’s also possible follow the standard procedure described in the UHD build guide to build it from the source (http://files.ettus.com/manual/page_build_guide.html).

Once UHD has been installed the UmTRX module must be built and installed over it. We have just installed Ubuntu 14.04 so some necessary software for building UmTRX module is abscent. It’s easy to get, though!

$ sudo apt-get install git
$ sudo apt-get install libboost-all-dev
$ sudo apt-get install build-essential
$ sudo apt-get install cmake

Git is a widely used version control system for software development. Boost is a set of libraries for the C++ programming language that provide support for tasks and structures such as linear algebra, pseudorandom number generation, multithreading image processing, regular expressions, and unit testing. The build-essentials is a reference for all the packages needed to compile a debian package. It generally includes the gcc/g++ compilers an libraries and some other utilities.

We are ready to install UmTRX module right now:

$ git clone https://github.com/fairwaves/UHD-Fairwaves.git
$ cd UHD-Fairwaves/host
$ mkdir build
$ cd build
$ cmake ../
$ make

In this part we cloned Fairwaves repository to the local folder, created a folder for the installation and built the module. To install the driver with a package:

$ cpack
$ sudo dpkg -i umtrx_*.deb

We highly recommend to use Josh Blum’s UHD driver as we based the development of UmTRX driver on it.

It is suitable moment to setup and boot UmTRX board to ensure if the installation went correctly.

The UmTRX Lab Package includes a power supply, GPS antenna and pigtail wires for GSM antennas. The user have to take care of assembly and cooling. A 3-pin mains lead is required.

Cooling is necessary and the heat generated must be dissipated in a stable manner in order to avoid permanent damage of the UmTRX. Cooling using fans is easy to implement but is mostly suited to indoor use. Two fans may be connected via the connectors X17 (FAN1) and X18 (FAN2). FAN1 is constantly powered and FAN2 is automatically switched on/off by U35 (MAX6665ASA45) when the temperature is around 45°C. The maximum DC current of FAN2 must be less than 400mA.

TX and RX antennas should be selected according to the application. Damage may occur if UmTRX is set to transmit without a suitable 50 ohm load connected! We will use antennas from the box.

As we plugged power and cooling, we need to connect our board to computer via ethernet cable directly or via switch. For now, UmTRX does not support 100M Ethernet and it will not be recognized if your computer does not support gigabit Ethernet. Though, if your PC ethernet port supports only 100 Mbit/s, you may use 1GBit/s network switch. By default UmTRX has a static IP address 192.168.10.2/24, so it is recommended to set your computer’s IP address to 192.168.10.3/24.

It’s easy to check, if UmTRX and UHD were installed properly:

$ uhd_find_devices

If the result was like that, we made everything right:

We may also probe the properties of the attached device:

$ uhd_usrp_probe 192.168.10.2

The output of the command shows different properties of our UmTRX, such as driver version and channel settings.

The next step is installation of GNU Radio package into our Ubuntu system. We recommend to use build-gnuradio script as it would allow to install the latest version of the package and not to overwrite our existing UHD driver. Create a folder in your /home to avoid any issues with file permissions.

$ wget http://www.sbrac.org/files/build-gnuradio && chmod a+x ./build-gnuradio && ./build-gnuradio prereqs gitfetch gnuradio_build

We are using additional parameters prereqs, gitfetch and gnuradio_build to check if our prerequisite software is installed (and install it if necessary), copy the installation files to created folder and build GNU Radio only, without UHD driver. The process takes about 2 hours, so please be patient.

To have more options in experiments with SDR, it’s helpful to install Osmocom GNU Radio Blocks (http://sdr.osmocom.org/trac/wiki/GrOsmoSDR). By using the OsmoSDR block we can take advantage of a common software API in our application(s) independent of the underlying radio hardware.

$ git clone git://git.osmocom.org/gr-osmosdr
$ cd gr-osmosdr
$ mkdir build
$ cd build
$ cmake ../
$ make
$ sudo make install
$ sudo ldconfig

So, the script finished it’s work and we are ready to have some fun with GNU Radio!

Software Defined Radio is a radio system which performs the required signal processing in software instead of using dedicated integrated circuits in hardware. The advantage of that approach is that since software can be easily replaced in the radio system, the same hardware can be used to create many kinds of equipment for many different radio standards. Therefore, one SDR can be used for a variety of applications. SDR is a technology that makes IT and Telecommunications closer to each other.

Basically, our system should consist of two parts: computer with software and SDR transceiver. There are plenty of SDR transceivers: UmTRX, USRP, HackRF, BladeRF, etc. Which one to choose?
As we are going to work with GSM, it would be wise to choose SDR that was created with consideration of GSM specifications. There is such SDR solution on the market. It is named UmTRX and was developed in Fairwaves.

UmTRX is based on the open source hardware (Altium Designer schematic and board layout files are made available under the Creative Commons Attribution-ShareAlike 3.0 Unported license) and can be deployed using open source software (for example, GNU Radio, Osmocom family of open source projects), therefore it benefits from being part of an ever-growing ecosystem of complementary hardware and software for mobile communications. UmTRX was developed to be used as a transceiver for OpenBTS and OsmoBTS GSM base stations considering GSM specifications, but due to its SDR nature it could be used for many other applications as well. It operation based on the Ettus UHD driver. UmTRX has its own GPS clock (26 MHz Voltage Controlled Temperature Compensated Crystal Oscillator) and industrial grade components (such as Lime Microsystems Multi-band Multi-standard Transceiver with Integrated Dual DACs and ADCs LMS6002D). UmTRX has two independent channels, so one can operate on two different frequencies. As it works in different environment conditions all over the world, like hot climate of Africa and high humidity of tropical islands, we can be sure it will work on our table.

As we decided our hardware option, we need to choose our first application. Let’s try to investigate GSM signals using our UmTRX.

We are going to use GNU Radio software to build that project. GNU Radio (https://gnuradio.org) is a free and open-source software development toolkit that provides signal processing blocks to implement software radios. You can use it to write applications to receive data out of dial streams or to push data into digital streams, which is then transmitted using hardware. GNU Radio has filters, channel codes, synchronisation elements, equalizers, demodulators, vocoders, decoders, and many other elements which are typically found in radio systems. More importantly, it includes a method of connecting these blocks and then manages how data is passed from one block to another.

Our hardware part needs to receive radio frequency (RF) analog signals and transform them into the digital form using Analog-to-Digital Converter (ADC). UmTRX system should do that job easily. As for software part, digital signal processing (DSP) is where GNU Radio has a plenty of tricks.

Our goal from the beginning – when we made the first UmTRX design in 2011 – was to create an SDR which meets all rigid technical and legal requirements for telecommunication equipment. And make sure it has a reasonable cost, so e.g. you don’t have to spend extra $600-$900 for a GPS Disciplined Oscillator (GPSDO) after you already spend $700-$800 on an SDR – hence all UmTRX come with a built-in GPS. Our original focus was on 2G/GSM, but with up to 30.72 MSPS UmTRX 2.3.1 handles 3G/UMTS and 4G/LTE just as well.

It took us 5 hardware revisions to get to UmTRX 2.2 which was the first UmTRX we were happy with. We’ve built UmDESK desktop BTS based on UmTRX 2.2 and it found many users since it was introduced in 2013.

With the experience we obtained building the UmDESK, we set the bar higher – to create a lightweight and inexpensive outdoor base station.

This led us to start on a new UmTRX design with a goal to make it more compact and suitable for embedded environment; the UmTRX 2.3.1 was born!

It’s now used in all our outdoor UmSITE base stations which are deployed on all continents except Antarctica and are suitable for both Siberia-cold and Sahara-hot temperatures (see UmSITE temperature tests).

Why UmTRX 2.3.1?

UmTRX 2.3.1 is a compact dual-channel SDR built for embedded systems suitable for industrial, outdoor, harsh and remote environments. It is designed as a base station transceiver and thus has specific features required for this like power amplifier and external RF front-end control ports.

If you’re looking for a cheap high-bandwidth SDR, LimeSDR is probably the best choice right now, if you’re looking for a high tuning range, USRP B2x0 is what you need, but if you’re building a telecom grade or embedded or outdoor system, UmTRX 2.3.1 is the only option right now.

We’ve put together a comparison table of the most popular SDR boards capable of full duplex operation, required to run a base station. Receive only or half-duplex SDRs like HackRF or rtl-sdr are not included into this table for this reason.

UmTRX 2.3.1 vs UmTRX 2.2

UmTRX 2.3.1 use the same key technologies and thus should be very familiar for existing UmTRX users. It is also dual-channel SDR transceiver based on two LMS6002D chips, equipped with an onboard GPS and using Gigabit Ethernet as a communication interface. The same UHD host driver and even the same FPGA firmware is used for both boards. At the same time UmTRX 2.3.1 features a number of improvements and new features important for embedded environments and for building complete base stations.

Main differences between UmTRX 2.3.1 and UmTRX 2.2 include:

• Flat 100mW output power up to 4GHz.

• Only pinhead connectors for optimal space usage.

• Durable yet compact MCX connectors instead of U.FL in UmTRX 2.2.

• Smaller size: 128x95mm vs 159.5×99.5mm for UmTRX 2.2.

• Connectors for power amplifiers with software regulated power supply voltage and output power and VSWR monitoring.

• Better power efficiency thanks to updated DC/DC converter circuitry.

• Most tantalum capacitors replaced with MLCC for higher MTBF.

• Improved heat dissipation thanks to 90% copper filled bottom side and better mounting holes placement (pictured above with a mounting aluminium plate).

• Better RF performance thanks to RF channels shielding, dedicated ultra-low noise LDO for LMS6002 chips and clocking circuits, DC/DC converter synchronization to RF sampling clock.

• Input and DC/DC output voltage monitoring ADCs.

• True remote board control through the Ext Panel connector, including full board power down.

• RS232 debug port instead of USB in UmTRX 2.2 for higher reliability.

• Up to 40 MSPS RF sampling rate with an external clock (limited to 30.72 MSPS over the wire aggregate sampling rate due to 1GbE bandwidth) compared to up to 20 MSPS in UmTRX 2.2.

• Few other minor changes to improve robustness.

More information

You can find more information about UmTRX 2.3.1 in its datasheet.

Where to buy

Please go to our web-shop for small orders or contact us for volume pricing.

Early on in the design of UmTRX it was decided that it would be a dual-channel platform, with this being identified as supporting many target use cases and operator requirements, including:

• dual-band operation, e.g. 1800MHz for local coverage and 900MHz for longer distance
• road coverage, with a dedicated BTS and narrow beam antenna facing in each direction
• two operators on a single system, e.g. one public and one private network

Not to mention that the capacity afforded by two carriers also happens to be the sweetspot for many villages and rural installations.

Given that making a single channel system which meets GSM specifications is sufficient a challenge in itself, the approach favoured was a dual-channel platform comprised of two completely independant transceivers — rather than two carriers with one transceiver and DSP tuning.

At the present time UmTRX is the only truly dual-channel transceiver that is fully compatible with the Osmocom GSM stack. There are some platforms which offer the ability to support two carriers with a single radio, but these are limited by the bandwidth of the transceiver and channels must be in the same band and cannot be spaced too far apart.

In this post we take a look at how it’s possible to run two separate GSM BTS instances with a single UmTRX. Which is to say, two independent base stations with only one UmTRX transceiver board, or commercial base station hardware that is based on this, such as the UmSITE product line.

Note that while a single BTS together with UmTRX can also be configured to use both channels — i.e. as a BTS equipped with dual-TRX — this is different as there is only a single BTS instance, with both TRX configured for the same band and connecting to a common BSC and network.

Hardware setup

The hardware setup used in testing is quite simple, with a UmTRX connected to a HP Microserver running Ubuntu 14.04.2 and the Osmocom software. The TX ports for channels 1 and 2 were connected to an Agilent E4406A VSA Transmitter Tester and an ISO-TECH ISA 830 TG spectrum analyser.

Software installation

Build tools and packaged dependencies were installed first via apt-get:

$ sudo apt-get install python-software-properties build-essential cmake libtool autoconf autotools-dev pkg-config git libopencore-amrnb-dev libsofia-sip-ua-dev libortp-dev sqlite3 libdbi-dev libdbd-sqlite3 libncurses5-dev libpcsclite-dev libusb-1.0-0-dev

Driver

The base UHD driver was installed next and packages with module support compiled-in are available via the Pothosware PPA, which can be added with:

$ sudo add-apt-repository ppa:guruofquality/pothos

Following which the Apt cache is updated and UHD can be installed, along with the Boost development files which are required in order to build the UmTRX module for UHD:

$ sudo apt-get update
$ sudo apt-get install uhd libboost1.54-all-dev

The UHD-Fairwave sources were cloned and built next:

$ git clone https://github.com/fairwaves/UHD-Fairwaves.git
$ cd UHD-Fairwaves/host
$ mkdir build
$ cd build
$ cmake ../
$ make

The UmTRX driver module can then be installed simply via “sudo make install”, else packaged as a Debian package via cpack. For more details see the Driver page.

Osmocom software

The Osmocom software is installed by cloning the sources, creating a build directory, entering this and running cmake, followed by configure and make etc. Rather than detail all these individual steps for each component in the software stack, just the required git branches along with any configuration options are noted here. See the linked wiki pages/sources for more details.

Libraries

The following Osmocom libraries are required:

• libosmocore
• libosmo-abis
• libosmo-netif
• libosmo-sccp

The master development branch should be used for each.

OpenBSC

OpenBSC should be built from the fairwaves/master branch.

First OsmoBTS

The software for the first OsmoBTS instance should be built from the fairwaves/master branch. Remembering to configure TRX hardware during build with:

$ ./configure --enable-trx

Second OsmoBTS

At the time of writing multi-BTS functionality has not been integrated into the OsmoBTS main development branch, and so the software for the second OsmoBTS instance must be built from the achemeris/2sector branch. Once again, TRX hardware needs to be enabled, but this build of OsmoBTS should be installed to a different location from the first. For example, by using:

$ ./configure --prefix=/usr/local/special/2sector --enable-trx

OsmoTRX

Similarly, at the present time the achemeris/2sector branch of OsmoTRX must be used.

Once the OsmoBTS and OsmoTRX code to support multi-BTS configurations has been tidied up, this functionality will be available via the fairwaves/master branches of each.

Configuration

The configuration used was based on the multi-BTS with handover example, with one major difference: each BTS instance must be configured to have only a single TRX, both in the OsmoBTS configurations and the OpenBSC NITB configuration sections for these. In our example it was decided to put BTS 0 on 1800MHz and BTS 1 on 900MHz.

So for BTS 0 the first 5 lines of configuration were:

bts 0 
 band DCS1800 
 ipa unit-id 1801 0 
 oml remote-ip 127.0.0.1 
 rtp bind-ip 127.0.0.1

And with BTS 1 the first 5 lines were:

bts 0 
 band GSM900 
 ipa unit-id 1802 0 
 oml remote-ip 127.0.0.1 
 rtp bind-ip 127.0.0.1

Note the use of different values for ipa unit-id.

The OpenBSC NITB configuration (open-bsc.cfg) used was based on the multi-BTS one, with the main difference being to remove the trx 1 config sections from bts 0 and bts 1. The first BTS was put on ARFCN 540, which has a downlink at 1810.8MHz, with the second BTS on ARFCN 63, which has a downlink frequency of 947.6MHz.

Running

The OpenBSC network-in-the-box software was started first with:

$ osmo-nitb -c ~/.osmocom/open-bsc.cfg -l ~/.osmocom/hlr.sqlite3 -P -C --debug=DRLL:DCC:DMM:DRR:DRSL:DNM

Followed by the first BTS.

$ osmobts-trx -t 1 -c ~/.osmocom/osmo-bts-0.cfg

And then the second BTS, which was installed to a non-standard location:

$ /usr/local/special/2sector/bin/osmobts-trx -t 1 osmobts-trx -t 1 -c ~/.osmocom/osmo-bts-1.cfg

For obvious reasons each started with only one TRX.

Next the transceiver was started with two channels.

$ sudo osmo-trx -c 2

Note that the above screenshots were taken after everything had been started up.

With our two BTS network started we could then see that we had carriers on the expected ARFCNs.

So there we have it — you can now run two independent BTS instances with a single UmTRX board!

New and improved features

Further updates made to the host software and accompanying firmware as part of this transition include:

• Numerous additional features for versions of UmTRX that are used in the UmSITE product line, such as the ability to control integrated power amplifiers, and sense forward and reflected RF power at their output ports;
• Support for timed commands;
• Retrieving GPS NMEA data over IP is now functional.

On this last point, retrieving raw NMEA data from the GPS module is as easy as using a one line netcat command:

$ echo . | nc -u 192.168.10.2 49171

If you prefer to have gpsd rather than watch raw NMEA data, you can use socat:

$ echo . | socat - UDP-DATAGRAM:192.168.10.2:49171 | socat - PTY,link=./gps,raw,echo=0
$ gpsd -b -N -n -D1 ./gps

Installing

The default branch for the UHD-Fairwaves GitHub repository is now the one where the UmTRX module lives, umtrx_update. However, the old branch with the legacy monolithic driver, fairwaves/umtrx, still exists.

If you were using the old driver it’s probably best to uninstall this first, before installing a stock version of UHD, followed by the UmTRX module. See the Driver page for details.

The UmTRX firmware should also be updated at the same time as the host driver. See the Flashing page and note that the name of the command used has changed slightly.

Up until 19th February 2015 (the Chinese New Year) it will be possible to purchase a UmTRX v2.2 complete with a power supply and coax pigtails for only $850. This offer is being made by Fairwaves in support of getting hardware into the hands of more developers, and is limited to 2 kits per individual and 10 per university.

Orders placed now should be received in January. To find out more see the blog post over on the Fairwaves website, and to place an order head over to the web shop.

In most parts of the world a spectrum licence is required in order to operate a mobile base station (BTS), in much the same way that a licence would be required if you wanted to set up your own radio or TV station. This is not unreasonable and, after all, a great deal of inconvenience can be caused if spectrum use is not carefully coordinated and interference leads to service outages.

License-exempt use

If you are fortunate enough to live in the Netherlands it’s possible to operate a BTS in guard band situated between GSM and DECT allocations, license free, provided that transmit power is limited to 200mW and antenna height to 10 metres. And this is precisely what Fairwaves did in August 2013, when together with Event Connection they built a GSM network that covered the city of Nijmegen.

Similar license-exempt use is also permitted in Sweden and possibly some other areas — but these are the exception to the rule.

While access to guard band spectrum is permitted for low power use in the UK, this is limited to those 12 licensees who together paid Ofcom £3.8 million for the privilege and were awarded licences back in 2006.

Non-operational licensing

Regulatory authorities typically provide a class of licence that can be used to support the development and testing of wireless technologies. Here in the UK this is referred to by Ofcom as a Non-operational licence, and was actually previously known as a Test and Development licence. These may be valid for up to one year and currently cost £50 per site.

It’s important to note that a non-operational licence:

• may not be used to provide a service, as to do so would constitute being a cellular operator and this is not covered and would therefore be unlawful;
• is not a “GSM licence” per se and instead provides permission to use the allocated spectrum subject to certain power, bandwidth and antenna etc. constraints;
• could cover any frequency, provided that Ofcom are able to clear use — which is highly dependent upon what has been requested and what the primary use of that spectrum is;
• is a privilege and not a right!

Applicants will be expected to provide details such as the requested frequencies, modulation type and bandwidth, transmitter power level, and antenna gain and height. Those without a background in RF systems may find answering some of the questions a challenge, however, a solid understanding of the fundamental basics is essential.

There are no hard and fast rules when it comes to what power levels or antenna gains etc. will be permitted under a non-operational licence, but note that requests for access to spectrum are subject to approval by primary users. Applications should be driven by need, common sense must prevail, and a few milliwatts TX power and a low gain antenna should suffice for bench testing.

Those who wish to apply for a non-operational licence should:

• See the Ofcom website for the application form and accompanying guidance;
• Note that the class of emission for GSM is 271KF7W;
• Only apply for what is actually required and have realistic expectations;
• Contact Ofcom when uncertain — they are most helpful.

Note that regulators in other countries typically provide similar licensing schemes that can be used to support research and development.

The need for lighter regulation

Lighter regulation for guard band spectrum, such as has been employed in the Netherlands and Sweden, would provide a great many benefits beyond simply facilitating the development and testing of wireless technologies. For example, SMEs and communities could use it to provide network service in rural and sparsely populated areas that have been deemed  not economically viable by the incumbent operators. However, this topic is one that requires a blog post all to itself!

Andrew

Top image: bench testing a Parallella board running the Osmocom software driving a UmTRX.

Collaboration at TADHack 2014

The Telecom Application Developer Hackathon, or TADHack for short, took place over 6-7th June in Madrid and almost the entire Fairwaves technical team were in attendance.

For the hackathon Fairwaves engineers collaborated with Ben Klang, founder of real-time communication specialists, Mojo Lingo, and Jose de Castro of Tropo, on the development of an in-network application service called FairShare Community Mobile. This aims to alleviate the problem of mobile network saturation where resources are scarce and costs may be high — such as is often the case in developing nations — through ensuring fair use of resources by managing call duration.

The collaboration resulted in a working prototype which was demonstrated live, using a UmTRX-based BTS, and which went on to win the Geeks Without Bounds Challenge Prize.

The presentation slides can be found on SlideShare and the video is below.

HOPE X, 18-20th July

Hackers On Planet Earth (HOPE) is a biennial conference that is sponsored by 2600 magazine and which covers a broad range of topics, including technology in art, communications, hacking, activism, privacy, security, politics and much more.

The conference will be taking place from this Friday until Sunday at the Hotel Pennsylvania in New York, and Alexander Chemeris, Andrey Bakhmat and Sergey Konstanbaev from Fairwaves will be present, along with Peter Bloom from Rhizomatica, who will be giving a talk on their work building community mobile networks in Mexico, and the societal benefits and legal challenges etc.

Also present from Rhizomatica will be Ciaby and Tele, who will be demonstrating how to set up a community cellular network.

If you are attending HOPE X and you’re interested in cellular networks, be sure to seek out the guys from Fairwaves and Rhizomatica and say hello!

Cluecon, 4-7th August

Cluecon is an annual four day conference for telephony developers that is being hosted in Chicago. At this Alexander Chemeris will be giving a talk on the third day on the Osmocom architecture, Fairwaves UmTRX-based hardware, and how to use these together to build a small GSM network. The talk will be aimed at VoIP developers with little or no prior experience of GSM network technology, and there is likely to be a demo of something new at the Dangerous Demo contest.

Andrew

Top image: Ben Klang & Alexander Chemeris pitch FairShare at TADHack (source: tadhack.com)

v2.2 of UmTRX has gone in to manufacture and with v2.3 to follow soon after.

The Fairwaves engineering team have been hard at work updating the UmTRX hardware platform, based on feedback from customers and experiences gained with deployments in the field. The first new update is v2.2, this has just gone into manufacture and changes from v2.1 include:

• Corrected component footprint for temperature sensors
• Corrected mask-to-silk warnings around T1-1, T1-2
• Mounting holes more accurately aligned to 0.5mm grid and diameters increased to 3.2 mm
• Added extra hole between LMS at centre line of board for better mounting to heatsink
• All free space of bottom layer filled by the GND copper polygon for better heat dissipation
• Add silkscreen on the vias which are under the LMS6002D ICs to make the screen stronger
• Added one more screw in the middle of the board between LMS6002D ICs
• MCX connectors replaced by MMCX
• GND pins of SMA connectors now with thermal spokes
• Resistors R103 of LMS6002D reference voltage for ADC/DAC reduced to 51 Ohm.

Just as v2.2 goes into manufacture, v2.3 is about to go into testing. Further changes in v2.3 include:

• Clock distributor IC changed to Si53301 in order to get clock divider for PLLs of LMS6002Ds
• Added R158 and R160 (S3 bypass) to enable use without clock I/O components
• Higher efficiency DC/DC conversion:
  • converters are now TPS54560D instead of L5973AD
  • Lower resistance power coils used
  • +6V output decreased to +5.5V
• DC/DC converters are synchronized to fixed 541.67kHz (26M/48) from FPGA after firmware start in order to minimise interference
• LMS6002D power supply and reference voltages are now from a single ultra low noise IC, HMC1060
• LMS6002D channels are now screened by a standard shield from Laird Tech
• Output stage IC changed to SBB5089Z to obtain flat gain up to 4GHz and 100mW output
• All possible components have been moved from the bottom to the top in order to get ~90% copper fill on the bottom
• PCB size shrank to 128x95mm, but still a 6 layer stack
• More reliable DIP switch used for Master-Slave clock mode control
• Single LVCMOS output of FPGA for UmSEL diversity switches control instead of LVDS
• Added four channel ADC ADS1015 to measure power amplifier control voltages via 1:10 resistive dividers
• Added two Hirose DF11CZ-8DP-2V(27) connectors for control and monitoring of two external power amplifiers

As can be seen there have been quite a number of updates!

The first batch of v2.3 boards should be ready for testing towards the end of June and we’ll be providing further details here and the GitHub repository will be updated in due course.

Andrew