Repairing the HackRF

I broke my HackRF One. I have no idea how, but I did it.

While testing a power amplifier I realized that there was not transmission at all. After checking the software, the connections and the power amplifier, I confirmed that my HackRF was broken. It was able receive but not to transmit. More precisely, I was not able to transmit when configuring the HackRF with medium-high TX power. However it worked when configuring the HackRF to transmit with low power.

A fast check in the schematics confirmed my fears: the power amplifier stage was blown.


The HackRF One uses two Avago MGA-81563 amplifiers. This chip amplifies the input signal by 14dB. In the HackRF this chip is used as a power amplifier (PA) for transmitting and as a Low Noise Amplifier (LNA) for receiving. In the PCB they are marked as U25 and U13 respectively.


HackRF One – LNA and PA schematic

Two RF switches Skyworks Sky13317 – U12 and U14 in the schematic – connect the antenna to the LNA, the PA or they just bypass the amplifiers. When working the with HackRF in GNU Radio, the RF parameter enables the amplifiers (RF=14)  or disables/bypass them (RF=0)

Is very easy to find if the LNA – the amplifier for the RX signal – is broken. You just have to launch the osmocom_fft program (you can find it in the  gr-osmosdr package of Pybombs) and sintonize a frequency where you can see transmissions (eg: the FM band). Configure the IF and BB gain to something in the middle of the scale (around 16 and 26dB respectively) and set the RF gain to 0. Measure signals you receive, set the RF gain to 14 and measure them again. You should have approximately a 14db gain. If switching the RF to 14 attenuates the signals instead of increasing, the LNA (U25 in the schematics) is broken and you have to change it.
The following image shows a working LNA. When the RF is set to 14, the signal is amplified by almost 14dB.

Osmocom_fft. LNA OFF vs LNA ON

Osmocom_fft. LNA OFF vs LNA ON

Finding if the PA is broken can be trickier because you need to use a external tool to measure the output power. This tool can be another HackRF or a cheap SDR like the RTL-SDR, but I will use a spectrum analyzer.
Use GNU Radio Companion to transmit a carrier. Set the IF gain to 47 and the RF gain to 0. Measure the output power, set the RF gain to 14 and measure again. If you don’t see an increase of approximately 14 dBs but you see that the signal is attenuated instead, your PA (U13 in the schematic) is broken and it needs to be substituted.

GNU Radio Companion flow used for testing the HackRF

GNU Radio Companion flow used for testing the HackRF

The following image shows the output of my HackRF with PA off and on. As you can see, the signal with the PA off is stronger. This clearly indicates that the PA is blown.

Broken HackRF. Left: PA off - Right: PA on.

Broken HackRF. Left: PA off – Right: PA on.

The main reason why people kill the LNA is because they put too much power in the input. The HackRF is designed for a maximum RX signal of -5dBm. I read in Internet about people that connected their 5Watts (37dBm) directly to the HackRF input, without any attenuator. Magic smoke guaranteed!

The PA can be destroyed because a antenna impedance mismatch. Transmitting without antenna or an incorrect antenna produces a high reflected power that can destroy the PA. In my case, I did not know that the HackRF continues transmitting even if you stop the application. In order to stop HackRF to transmit, you need to press the reset button. I probably killed my HackRF when inserting and removing the external power amplifier I was testing.


You will need to substitute the blown amplifier. You can buy a replacement in Farnell, Digikey, Mouser, etc for less that 3€. The following image shows the location of the LNA and PA (U25 and U13) in the PCB. Blue arrow points to the LNA (U25) and the red arrow points to the PA (U13):

HackRF PCB. Blue arrow: LNA. Red arrow: PA

HackRF PCB. Blue arrow: LNA. Red arrow: PA

I recommend you to use a hot air soldering station and a lot of flux. If you dont have it, you can still use a regular iron solderer if you have a fine tip and you are skilled enough.

Once you substitute the broken amplifier, repeat the tests to check that the LNA or PA works. This is how my HackRF performs after fixing the PA:

Fixed HackRF. Left: PA off - Right: PA on.

Fixed HackRF. Left: PA off – Right: PA on.

If you changed the MGA-81563 and your HackRF still does not work, I would try to change the Sky13317 RF switches (U12 and U14).

Fault injection attacks on microcontrollers: clock glitching tutorial

There is a lot of published papers with information about practical attacks using glitching on cryptographic devices or embedded systems in general. These papers are usually detailed in the process of glitching but not in the setup they use to inject the glitches. They just say at most what kind of FPGA (or commercial station) are using and what “glitching capabilities” they get (frequency, resolution, etc).

If you look for schematic and code to replicate the attacks on these papers, you will not find too much. Almost nothing is published so the reader might think that glitching is something complicated and not easily to perform without specialized and expensive equipment so a false illusion of security against these attacks is perceived.

However, the truth is that glitching can be done with simple and cheap hardware as it has already shown, for example, with the XBOX360 glitch hack or the unloopers that jeopardized the pay-tv smartcards in the mid-00’s.

Today I am going to show you how to clock-glitch for less than 15$ on equipment.

Continue reading

Ultra-low cost IC decapsulation

or how to decap microcontrollers at home and cut your life expectancy in 20 years

Have you ever read about IC reversing? Would you like to introduce you to the world of invasive IC attacks but do you think it is very expensive?
Of course! It is very expensive! I am not going to lie you about that. However, your can do the first step of a invasive IC attack – the decapsulation – at your home using very cheap tools. Instead of spending thousands of euros in chemical laboratory equipment we can spend just only 40€ in common household equipment.

Continue reading

Optimization of Microchip PIC XC8 compiler in Free and Pro mode

I don’t like to program PICs in C language. In fact, I even used to hate it due to the poor quality of the C compilers.

When I started to program PICs microcontrollers in 1998 there was not too many options to program PICs in C. As far as I remember, only Hi-Tech, IAR and CCS had compilers – not even Microchip has his own one – and they were quite horrible compiling. But the fault was not in the compilers manufacturers, but in the PIC core architecture.

Those days Microchip had only what we know nowadays as the ‘base-line’ (12C50X) and ‘mid-range’ (16C54,16F84,16F87X…) architectures. Those cores were so simple that it was not easy no make a C compiler for them. Few memory, scarce resources, small instructions set, few addressing modes…
Anyway, who needs a C compiler with such simple architectures?

Years later Microchip released the more C oriented PIC17/PIC18 architecture and a new range of C compilers for the new PICs were created. Finally we had “reasonable efficient” tools to program Microchip microcontrollers in C!

Two years ago Microchip bought the Hi-Tech company and renamed their Picc compiler as XC8. With this movement, Microchip provide to their clients a cheap and decent C compiler as their old and deprecated C18 compiler was – in my opinion – plenty of bugs and not worthy to work with.

I still use ASM to program the PIC12 and PIC16 family. However, I program the PIC18 devices in C but I often had to dive into the asm of the generated binary  to optimize it.
In those optimizations I have seen weird things made by compilers and I have been long time wanting to write about it.
Today I am only going to write shortly about how the free mode of the XC8 compiler bloats the binary to make the Pro version look more efficient.

Continue reading


Note: before continuing, read the BSC section as a lot of things there like installation and configuration are applicable to the MSC.

The Mobile Switching Center or MSC is the system that centralize all the network operations.
It controls all BSCs, users and user groups registered in the network. It also provides a web interface for maintaining the users and sending messages.


The MSC software runs on a similar machine than the BSC software. Again, an old computer or preferably a Raspberry PI. In fact, you can install the MSC and the BSC software in the same machine and run them both at the same time.


The MSC software has been also written in Java, but new technologies/frameworks has been used:

  • Servlets and JSP (J2EE): control interface
  • Jersey: RESTful Web Services.
  • Fusesource MQTT-Client: MQTT communications
  • Apache Derby: database
  • JSF 2.0 (Java Server Faces): user interface
  • RichFaces 4.2: User interface with AJAX

The MSC responds all the notifications sent from the BSCs and keeps a list of all the active BSC nodes.
It also keeps a user database with all the information needed to send him a message like the RIC number, the pager frequency or baudrate. The MSC can make user groups to make easy to organize and manage them.

When the operator send a POCSAG message using the web interface, the MSC will check all the active BSCs that have an BTS capable to send the message and will send the order to the BSC using the REST or MQTT interface.


The MSC can use a REST webservices API or the MQTT protocol to communicate with the BSC. To read more about it, please refer to the Communications section of the BSC article.


To download the application or the source, check the Download Section.

The MSC software requires the same runtime environment than the BSC software (Java 6/7 and an application server like Tomcat 6/7). Refer to the Installation section of the BSC article to know more about the installation process. The RS232 part and RXTX library is not applicable here as we don’t need it in the MSC.

In addition to what has been said in the BSC installation section, you have to give permissions to Tomcat for creating a directory where the Apache Derby database is going to be created.
The easiest way to do this is to add the permissions to the tomcat directory (/var/lib/tomcat7 in Ubuntu, Debian and Raspbian):

May be this is a little bit insecure. It is more appropriate to assign the permissions only to the Apache Derby directory.

Note that in a Raspberry the software will take a lot to start. Don’t hesitate if it needs two minutes or three.

Configuring the MSC

Open the file /WEB-INF/pocsag-msc.config located in the application directory where your application server deployed the war file and modify it. The file is commented and self-descriptive.

You can configure parameters like what communication protocol – REST or MQTT – should be used (you can activate both and have BSC nodes working with REST and others with MQTT), the refresh frequency, etc.

After modifying this file, remember to restart the server to have the new changes to take effect

It is VERY IMPORTANT to create the database where the node and users info is going to be stored.
To do this, open in the browser the address http://localhost:8080/OsomcomPOCSAG-BSC (change the machine name, the port and the deploy directory as needed) and in the lateral menu, select the ‘Debug -> Install DB’ option

MSC - Database Installation Window

MSC – Database Installation Window

Press the buttons to create the three tables. You can come back to this window later if you want to erase all the data.


The BTS nodes window

Once you have installed the MSC, configured it and created the databases, you have to be sure that there is at least a BTS node registered and active. Go to the ‘Administration -> Nodes’

From this window, you can list all the nodes that are or has been registered in your MSC. Those that appear in green are currently active (have been seen in the last minutes), the orange ones are uncertain (still soon to consider them inactive) and the red ones are inactive (at least two minutes without receiving anything from them).

If you can’t see any BTS node, check if you have configured everything. Open the MSC and BSC log files and try to determine the cause. May be you are not using the same protocol or it is not correctly configured.

The subscribers groups window

You can create now (or later) the subscribers groups you will need from the ‘Administration -> Subscribers groups’ window. This allow you to organize your subscribers in groups in order to do “massive” message sending.

MSC - Subscribers groups

MSC – Subscribers groups

From this window you can not only create and modify groups but also check their members and send message to the group.

The subscribers window

Before sending messages you have to register the subscribers or pager users from the ‘Administration -> Subscribers’ menu.

MSC - Subscribers

MSC – Subscribers

Subscribers can be added to groups from this window:

MSC - Adding a user to groups

MSC – Adding a user to groups

The message window

From the ‘Messaging – Send Message’ window you can select the subscribers and groups to send a message.

MSC - Send message


I will write about this later…


TO-DO list for the next versions:

DEEP refactorization

Already commented in the BSC section.


Again, already commented in the BSC section.



Download the source from github:

Schematic and PCB are included in the documentation directory.


Download the source from github and compile it with Eclipse:

In the /build directory you can find the compiled project as a .war file, ready to deploy in a Tomcat server.
Read the Osomcom POCSAG BSC section to know how to configure the RXTX library.


Download the source from github and compile it with Eclipse:

In the /build directory you can find the compiled project as a .war file, ready to deploy in a Tomcat server.


The BSC or Base Station Controller is the system that provide intelligence to the BTS and connect it to the rest of the POCSAG network.

The BSC is a software running on a machine connected to one or severals BTS boards.
The main function of the BSC is to inform the MSC that the BTS is operative and receive commands from the MSC to transmit through the BTS.

The system formed by the BSC and its BTSs is called BSS (Base Station Subsystem).


The BSC software doesn’t require too much, so almost any machine would be enough to host it.
The only requirements is that the machine needs to be connected to the network and has a RS232 port (or an USB port to use a USB-RS232 adapter).

Your old PC computer is more than enough to run the BSC software but if you want to create a permanent POCSAG network, I don’t recommend to use a regular PC computer for that purpose. They consume too much power and if you have to run it 24 hours per day, it is desirable to use a low-consumption system like an embedded platform.

Your best option is to use a Raspberry board. It is cheap (<29$), it has a low power profile (0.5W for the Model A) and its ARM v7 is fast enough to run the application. Some tunning could be necessary to make the Java Virtual Machine run faster. I will talk later about how to install the JVM, the application server and how to tune it.

There are other ARM boards that can be used to host the software like the Beagle-board, the raspberry pi clones or even the Chinese android based minicomputers. As far as they have 256 MB of RAM (maybe 128MB could be enough) and a Linux distro they can be used as host machine.

If you prefer the X86 architecture, a good option is to use Geode based boards like the Alix or the new Quark based boards like the Intel Galileo.


The BSC software has been written in Java to make it portable to any platform. It should run on a Linux/Unix, Windows or Mac computer without any problem.

In addition to Java, I have been using this frameworks / technologies to develop the BSC software:

  • Servlets and JSP (J2EE): control interface
  • Jersey: RESTful Web Services.
  • Fusesource MQTT-Client: MQTT communications

Once the application is deployed and running, it will register to the MSC node. Every minute the BSC will send a “ping” message to the MSC in order to keep alive the connection.

When the network wants to send a POCSAG message, the MSC will send the order to every BSC registered and active and the BSC will relay the POCSAG message to its attached BTS to transmit it.


In order to allow the communication between the MSC and the BSC, I have implemented two mechanism so you can choose the one that fits your needs: REST and MQTT. You can configure which one do you prefer and you can even make mixed networks using both protocols.

RESTful Web Services

Representational state transfer or REST is a design model to implement web services using the HTTP protocol.
A web API is available to permit the communication between the BSC and MSC or to integrate a third party software. The API URL and commands supported on the BSC side are:

  • POST /rest/pocsag/send/RIC
    Send a POCSAG message.
    – RIC (parameter in the url path): RIC to send a message
    – frequency: operating frequency in Hz.
    – bauds: baudrate (512, 1200 or 2400)
    – msgType: type of message (TONE, NUMERIC, ALPHA or IDLE)
    – message: body of the messageReturns ‘Sent’ if everything is OK. Otherwise returns ‘Error’

The API URL and commands supported on the MSC side are:

  • POST /rest/node
    Informs to the MSC that a BSC is alive (Ping).
    – port: port number where the BSC application is deployed. This port is necesary in order to reply using the REST interface deployed at the BSC.
    – name: name of the BSC registering.
    – time: Timestamp in Unix/Epoch format.Returns ‘OK’ if the MSC recognize and registers the BSC. Otherwise returns ‘ERROR CREATING OR UPDATING NODE’.


Message Queue Telemetry Transport or MQTT  is an open message protocol for M2M (Machine To Machine) communications optimized for embedded systems and high latency/narrow band networks.

Due to the low bandwidth consumption, this protocol is the recommended if you deploy a network with a lot of activity or a lot of nodes where a REST based network could get overcharged.

Before starting, you need to configure a MQTT server (a message broker) to permit the exchange between the MSC and the BSC. You can install a MQTT broker in the same machine like Mosquitto (instructions to install in the Raspberry Pi), HiveMQ or Moquette. Alternatively you can use a public broker but you won’t have the reliability and privacy of having your own server.

The communication from the MSC to the BSCs will go through a separated channel (“topic”) than the communications from the BSC to the MSC.
The currently supported messages in this this topic and their format are:

  • Pocsag Message
    The MSC ask the BSCs to send a POCSAG message of the type indicated (ALPHA, NUMERIC, TONE or IDLE) to the RIC using the frequency (in herz) and baud rate (512/1200/2400). The timestamp is in POSIX/UNIX format.
    PM:{1519073,148425000,2400,ALPHA,Hello world} – 1384300916263

When the BSC is started, it will subscribe to the topic to receive messages from the MSC and it will post messages to the topic to send data to the msc.
The currently supported messages in this this topic and their format are:

  • Node Ping
    Informs the MSC that the node is alive. The timestamp is in POSIX/UNIX format.

All the posting is done with a QOS of “Exactly once” (level 2), so every message is guaranteed to be received one and only one time.


To download the application or the source, check the Download Section.

The software has been programmed and tested using Java 6 and 7, but Java 5 should works.

In order to run the application a J2EE Application Server is required.
Use a “light” J2EE application server like Apache Tomcat or Eclipse Jetty. A “heavier” and complete J2EE application server like Glassfish or JBoss is not needed and won’t run on an embedded board.
I have tested the BSC application on Apache Tomcat 6 and Apache Tomcat 7 on the Raspberry and a PC computer. Jetty should also run perfectly on Raspberry.

If you don’t know how to install Java or the application server and you are using a Debian derivated like Ubuntu or Raspbian (for Raspberry Pi) read the section below.

To install the BSC software, download the WAR file from the download section (or generate it from the source) and check the manual of your application server to deploy and install the application.If you are using Tomcat, to install the WAR file you only have to copy it in the /webapps directory and start the server. The server will detect automatically that it has to deploy a new application and will create a new directory in /webapps with the content of the application. After some time you will be able to access to the BSC application. Try to connect to http://localhost:8080/OsomcomPOCSAG-BSC and a welcome page should appear if everything is OK.

NOTE: change ‘localhost:8080′ with the correct address and Tomcat port and ‘OsomcomPOCSAG-BSC’ with the correct URL path (the name of the  directory created in /webapps when you copied the .war file).

If you can’t open the welcome page, try to read the log file in the directory /logs to find the problem.

Before starting to operate, you have to connect the BTS hardware to the BSC machine. The easiest way to do this is probably to use a USB-RS232 TTL bridge like those sold in Ebay for less than 4€. If you need to connect.

The software requires you install the RXTX library to access to the serial port from the Java Virtual Machine.
Be sure that the Tomcat user (or the user running the application server) has permissions to open and read the serial port.

You need to put the jar library in the classpath and configure the native libraries. In the official site you have the installation instruction.

If you have problems because after following all the instructions your application servers gives an “Unsatisfied Link Error”, try to add to the JVM parameters the -Djava.library.path=”/usr/lib/jni” (or the path where the .so or .dll files are installed).

Installing Java and Tomcat on Ubuntu/Debian or a Raspberry PI

If you are using a Linux distro derivated from Debian like Ubuntu or if you are using a Raspberry PI with Raspbian (also derivated from Ubuntu), you can follow this instructions to install Java and Tomcat before installing the BSC software

First, you need to install a Java Development Kit (JDK).
You can install OpenJDK 7 from the repositories:

If you are using a Raspberry Pi with an updated version of Raspbian, you can install the Oracle JDK, as it is a little bit faster that OpenJDK:

Install Tomcat 7:

After installing Tomcat, you have to edit the /etc/default/tomcat7 file to make the JAVA_HOME variable to point the path of the JDK. Add (or modify) this line

Install the librxtx library:

You have to add the librxtx library to the Tomcat classpath.
Open the file /var/lib/tomcat7/conf/, search for the line starting with ‘shared.loader=…‘  and add ‘,/usr/share/java/RXTXcomm.jar‘  at the end. Your line will probably look like

Now we have to indicate to Tomcat were the RXTX native libraries are. Open again the file /etc/defaults/tomcat7 and modify the line JAVA_OPTS to add at the end ‘-Djava.library.path=”/usr/lib/jni”‘. The line will look something like

Your Tomcat user needs to have permissions to access the serial port. Normally is enough to add it to the dialout group. Edit the /etc/group so you have a line similar to

You should be able now to start Tomcat:

The Tomcat logs can be checked in /var/lib/tomcat7/logs and the application war files can be copied in the /var/lib/tomcat7/webapps to install.

Configuring the BSC

Open the file /WEB-INF/pocsag-bsc.config located in the application directory where your application server deployed the war file and modify it. The file is commented and self-descriptive.

You can change parameters like the communication protocol used (REST or MQTT), the name of the BSC node, the configuration of the serial port where the BTS hardware is connected,  the address of the MSC node, etc.

After modifying this file, you have to restart the server to see the effects of the changes.

Testing and using the BSC

The best way to know if the BSC is properly configured is to open the MSC web interface, check if the BSC node registers to the MSC and send a message through it.
Probably at this point you don’t have a proper MSC configured, so you need a easier way to test if the BSC software is correctly installed and the connection with the BTS is also correct.

There is a test page in the url http://localhost:8080/OsomcomPOCSAG-BSC/testPOCSAG.jsp
This page is a simple form to fill with the RIC number, frequency, baudrate and message that will invoke the REST API to send a message to a pager.



If you are just messing with POCSAG and you are not planning to deploy a fully functional POCSAG network, maybe you can  skip the installation of MSC and you can just use this testing interface to send your messages.


Thanks to the open communication protocols and simple API provided, it is very easy to integrate the POCSAG network with your own apps and scripts.

In example, If you are using Linux you can invoke on some events this command to send a message through the REST webservice interface:

To integrate using the MQTT interface, you will need to use a MQTT client like Mosquito-client


TO-DO list for the next versions:

DEEP refactorization

The code is a mess. It was programmed in a very fast and dirty way, without thinking too much in applying good programming practices, design patterns and making easy future maintenances.

Now that the program is functional, I think that the next step is a deep refactorization to make the source cleaner, easy to understand and maintain.


Currently there is no security at all. There is no authentication to access to the BSC and MSC interfaces and the communications are in clear text, not encrypted. And what is worst… anyone can register a BSC in a private MSC and capture the data traffic.

It is obvious that with this security holes the Osomcom POCSAG can not be used in real-world applications.

Fortunately, this is easy to fix using a password to access to the MSC and BSC and ciphering the text exchanged between nodes.

“Anti-collision” when Transmitting

There is no control to avoid two very close BTS working in the same frequency to transmit at the same time.

If the BTS radio hardware could receive radio signals, it could check if the channel is busy before transmitting. However, the current hardware only transmits and can’t receive.

A easy solution is to organize the network in “BTS groups”  where the BTSs in each group are not close to other BTS in the same group and can’t disturb themselves when transmitting. The BSC/MSC software can organize the transmission in a way that only one BTS group is transmitting at any time.
I started to program this feature in the MSC software, but I didn’t complete it.

BSS board

I am working in a new hardware that includes all the BSS (BTS + BSC) hardware and software.This way, it will be cheaper and easier to deploy networks.

I will release more information about this in the next months.

Minor improvements

Some features are easy to code and could be very interesting to have

  • Multi-BTS
    Having several BTSs connected to one BSC is partially implemented but still some work is needed.
    Currently has a level 2. Higher than what we need.


The BTS or Base Transmitter Station is the device that transmit the POCSAG messages to the pager. It is the radio interface of the POCSAG network.


The current version of the BTS hardware is a small board with a pic 18F microcontroller with a firmware that receive commands through an UART/RS232 port, create the POCSAG message and transmit it using the ADF7012 UHF transmitter.

This board has not be designed to be used exclusively with OSOMCOM POCSAG but to be used as a generic low power radio transmitter. Other uses of this board include experimenting with 433MHz keyboards, car/garage remotes, data links, APRS, etc.
The board has been designed to be very cheap (less than 15$) and easy to develop with.


Osomcom POCSAG BTS board

Board features

  • CPU: PIC 18F14K22 @ 16MHz
  • Memory: 16KB Flash / 512 Bytes RAM / 256 EEPROM
  • Transmission frequency: selectable from 75MHz to 1GHZ (but some parts values may need to be changed. More about this later)
  • Supported modulations: FSK/GFSK/OOK/GOOK/ASK. (FSK is used for POCSAG)
  • Transmission bitrate: selectable up to 179.2 kbps (512/1200/2400 for POCSAG)
  • Transmission power: selectable up to 14 dBm (20mW)
  • UART/RS232 port
  • Debugging/programming port for ICD/PICKIT
  • Expansion port with 4 GPIOs
  • SMA connector for antenna
  • Power: 3.3 volts ; ~50mA
  • Size: 4.4 cm x 4.6 cm

Schematic description

Osomcom POCSAG BTS Schematic - Click to enlarge

Osomcom POCSAG BTS Schematic – Click to enlarge

– Power supply

The power supply has a very simple and standard design.

Power Supply

Power Supply

The 5 volts input is transformed to a 3.3 volts supply using  the MCP1700T-3302 low-drop voltage regulator from Microchip. C1, C2 and C3 filter the input and output power.

A diode protecting the input from a reversed connection could be handy, but I didnt put it in the design. I am just confident that the user is not that stupid…

– Microcontroller

The brain of the board is a Microchip PIC 18F14K22.



– The radio module

A ADF7012 from Analog Devices is used as radio module.

This handy UHF low-power radio transmissor supports FSK, GFSK, OOK, GOOK and ASK modulation at a maximum rate of 179.2 kbps and the integrated Power Amplifier can deliver up to 20 mW without using an external antenna driver.
An internal PLL with selectable divisor synthesize almost any desired output frequency in a range from 75MHz to 1GHZ using just a 4MHz quartz.

A SPI interface is used to configure the transmisor. Modulation scheme, output power, output frequency and  other transmission parameters are selectable through this interface.

In my opinion, due its versatility, flexibility and simplicity to use, this is one of the best sub-GHz integrated transmisor out there. However, the lack of documentation and examples make it a little bit frustrating to work when you are starting. The datasheet is sometime confusing and sometimes insufficient. For example, it doesn’t give a table or graph with the output impedance of the RF output. HOW THE HELL ARE YOU GOING TO MATCH THE ANTENNA IF YOU DONT KNOW THE IMPEDANCE? Of course… you can always use a network analyzer and measure it, but unfortunately I don’t have access to one, so I just did my best trying to guess the impedance at my working frequency using the schematics of the application examples. They are for different frequencies, but I did an interpolation and… it works more or less fine.

Radio module

Radio module

I don’t want to make a deep explanation of the design process and inner working of the radio module, but I will make a brief description of the function of the different parts. If you need more information, refer to the ADF7012 datasheet.

The Q1 4MHz crystal define the output frequency.
To be more exact, the crystal frequency defines the output frequency  resolution. The output frequency is a defined with the  equation

Fout = Fcrystal · (N/R)  · OD

being N a 8+12 bits fractional number, R a 4 bits integer number and OD (Output Divider)  is 1,2,4 or 8. The value of N,R and OD are selectable through the SPI interface.
In theory, almost any output frequency is selectable with almost any input frequency, but choosing a lower frequency crystal gives you more resolution and introduces less spurious noise.

In case we use FSK or GFSK, the crystal frequency also defines the frequency deviation resolution:

Fdeviation = (Fcrystal / R)  · (M / 4096)

M (Modulation Number) is a software selectable 9 bits integer number.

The L1 coil controls the VCO frequency. The value of the coil has to be chosen according to the desired output frequency. The current value of 8.7 nH is appropiate to work in the frequency ranges of 70-77.5 MHz, 140-155MHz , 280-310 MHz and 560-620MHz. If you would like to personalize the circuit to make it work in a different frequency, you have to refer to the datasheet graph and choose an appropiate inductance value.

The Loop Filter formed with C10, C11, C12, C13, C14, C15, R4, R5 and R6 filters the VCO tunning voltage. In practice, the bandwith of this filter limits the maximum transmision datarate. When using FSK, the bandwith of this filter should be  three times the bandwith of the data rate.

The easiest way to calculate the values of the filter is using the “ADI SRD Design Studio” software availabe for free in the Analog Device website.
For our current needs, a 30KHz filter bandwith has been implemented.

– The antenna matching network

As commented before, the RF output impedance of the ADF7012 at 150MHz is an unknow, so the antenna matching is not easy without the proper resources.

I don’t have a network analyzer to measure the output impedance so I did some guess and some try-and-error process. The result is not perfectly matches but is good enough as the transmisor signal range is more or less the expected for a 20 mW emission.

Antenna matching

Antenna matching

Be aware that L4, L6 and L8 are unpopulated. I put those coil footprints in the PCB just in case a fine tuning is required by adding another coil or capacitor in parallel.

If you need to modify the BTS schematic to transmit in a different frequency than 140-160MHz, you have to change this antenna matching network to adapt it to your needs.
If you want to work with 315, 433, 868 or 915 MHz, you can use the matching network recommend in the datasheet.

– I/Os and connectors



S1 is a push-button that can be used to launch in the firmware some tasks.

SV1 is a RS232 connector to communicate with the BSC or a host computer.  It uses 3.3v signals but is tolerant to 5v. You can use a RS232 TTL – USB bridge to connect the BTS to your computer BSC system.

SV2 is a General Purpouse I/O port. It has 4 free GPIOs that can be connected to any sensor or system. GP1 is also an analog input, so an analog sensor like a temperature sensor can be connected.

SV3 is the ICD debug port. The microcontroller can be programmed or debugged with an ICD, PICKIT or similar device.


The last version of the firmware can be downloaded here.

The firmware has been written in C using the MPLAB X IDE and the XC8 compiler in free mode. It is important to compile it using the version 1.20 or superior of the XC8. Earlier versions dont optimize the code and the binary will not fit into the microcontroller.

The main function of the firmware is to transmit POCSAG encoded messages. However, in the firmware source there is a complete library to configure and control the ADF7012 radio module, so it would be easy to modify the firmware to transmit using other digital protocols.



The best way to use the POCSAG BTS  is connecting it to a device or computer running the Osomcom POCSAG BSC software and let the BSC to control the BTS. However, if you need something simple you can just connect the BTS to your computer’s RS232 port  using a USB-RS232 converter and use a terminal program to send commands to the BTS. The current firmware puts in the RS232 port a command console  that can be used to configure the BTS and send messages.

The configuration of the RS232 is 9600 Bauds 8-N-1.

The current available commands are:


Send a POCSAG message to the specified RIC. The first parameter indicates if the message has to be send like an Alphanumeric message, a Numeric message or an Idle message.

An hexadecimal representation of the sent batches is printed.


The config command without arguments  prints a list of the configurable parameters and their current value. To set a new value, send the parameter name and the new value with the CONFIG command.

This is the list of the available parameters:

  • FREQ: Frequency in Herzs. If you set a frequency that is not reacheable by the BTS hardware, it will complaint with a ‘Init error’ message when it start to transmit (SEND, START_MS or TEST command).
  • DEVIATION: FSK deviation in Herzs. In POCSAG, the most common value is 4500.
  • BAUDS: 512, 1200 or 2400.
  • POWER: The RF output power. The value is in the range between 0 (-20dBm) and 32 (13dBm).
  • MS_SAVE_FREQ: Number of RICs between status saving when doing a ‘Mass Send’ (more info below)
  • MS_DELAY: wait time in milliseconds between the transmision of two batches of 8 messages when doing a ‘Mass Send’.


Saves the current config in the EEPROM. The configuration is restored when the board is powered.


Restores the config stored in the EEPROM.


Start a ‘Mass Send’. It sends a message with a single ‘A’ character to all the RICs between the START_RIC and STOP_RIC. It is useful to scan RICs, when you don’t know the RIC of your pager.

8 messages for 8 consecutives RICs are packed and transmited in a single POCSAG Batch. Between two batches, some time defined by the MS_DELAY config parameter is waited.
Every MS_SAVE_FREQ number of RICs scanned, the current status of the Mass Send is stored in the EEPROM. In case the power supply is disrupted, the firmware will automatically continue with the Mass Send from the last saved status.


Stops the Mass Sending.


Continue with the stopped Mass Sending.


Shows the current state of the Mass Send (current RIC and stop RIC)

– TEST [0|1|2]:

Transmits a continous test signal with the selected pattern: ‘000000…’ (TEST 0), ‘111111…’ (TEST 1) or ‘101010…’ (TEST 2).

I use this function to know if the ADF7012 is transmiting at the desired frequency and deviation.


Stops the transmition of the TEST signal.


If you have problems making the BTS to work, check the next things:

– Is every thing correctly connected/soldered? Double check the soldered parts. Are them the correct parts?

– Is the microcontroller programed?

– Is the board being powered with a 5 volts power supply? Anything between 3.7 and 6 volts should be OK.
You can know if the board is being correctly powered because one led will be light.

– Connect the BTS board to your computer using a USB-RS232 board. Open a terminal program and set it to 9600 bauds, 8-N-1. Power the board and you will see a welcome message (‘Osomcom POCSAG 0.3′). If you send any string, the board will respond with a help menu.

If you can’t make work the RS232 shell, you probably have a problem with the microcontroller. If you can get the shell but you can’t transmit anything, the problem is probably in the radio module.

– Check if there is any transmission. The best and cheapest way to do this is using an RTL-SDR dongle. I use it like an spectrum analyzer.
Open the command shell, configure the desired frequency and deviation and use the TEST 2 command to generate a test pattern signal.

If it says ‘Init Error’, the BTS can’t reach the configured frequency. Choose another frequency or if you are interested in transmitting in that one, modify the schematics (the VCO coil and the antenna matching) as suggested in the Hardware section.

Use the RTL-SDR to check if you see a image like this:

FSK modulation - '101010...' pattern - 4500 Hz deviation

FSK modulation – ‘101010…’ pattern – 4500 Hz deviation

The important thing is to see the two power peaks around your central working frequency. If you can see them  but you can’t receive any message in your POCSAG, your problem is probably that you don’t have the correct RIC, frequency or bauds of your pager.

– While transmitting the TEST 2 signal, check the signals in the ADF7012 pins:

  • DVdd (pin 1) and DVdd2 (pin 21): 3.3v
  • CReg1 (pin2): around 2.36 volts
  • CPOut (pin3): around 1.32 volts
  • TXData (pin 4): With a oscilloscope, you have to see the test pattern: a 3.3v square signal of ‘1’s and ‘0’s. If you don’t see it, check the connection between the the microcontroller and the ADF7012.
  • Muxout (pin 6): This is a multipurpose pin that can be programed to perform diferent tests. Check the datasheet about the different uses of this pin. In the firmware, it is used to detect when the PLL is locked, so this pin has to be at 3.3 volts.If it 0 volts or if using the oscilloscope you see that the pin value switches, the PLL is not being locked so the RF frequency can’t be generated. The problem can be that the configured working frequency is very close to the limits of the hardware or that the the is a hardware problem. Check if the L1 coil is correctly soldered and the inductance value is the correct. Check also the filter loop.
  • CE (pin 13): 0 volts
  • LE (pin 14): 3.3v
  • L1 (pin 15), L2 (pin16) and VCOin (pin 18): between  0.2 volts and 2.1 volts.
  • Rset (pin 23): around 0.6 volts.
  • CReg2 (pin 24): around 2.4 volts

– If the voltages are right, the problem could be in the antenna matching network. You will need a network analyzer to measure the output power, the SWR, etc.


The current board has a lot of limitations so I am currently working in a new version of the BTS hardware.

Some of the new ‘desired’ features are:

  • Output power: the current output power of 20mW is not enough. An external Power Amplifier will be added to achieve a 250mW output  power.
  • Analog modulations: The current hardware is very versatile because it can transmit in almost any frequency (changing some part values), in any data rate below 179 KBauds and in a lot of different digital modulations. However, I miss some analog modulations like FM. Wouldn’t be wonderful if the board could work as a NFM voice beacon?
  • Microcontroller: The pic 18F14K22 is has been already taken to its limits. After a lot of source optimizations, the current firmware occupy the 87% of the RAM and the 82% of the Flash memory. In order to add new features, a new microcontroller has to be used.
    I will need a lot of CPU power due to the analog modulation feature I want for the next hardware revision.I am still deciding if continue using a Microchip microcontroller like the DSPic or PIC32 or changing to ARM and using a Cortex M0+.
  • USB: Having to use the USB-RS232 bridge is not very convenient. The next revision will have a USB connection for connection and powering.
  • Ethernet: I am planning about integrating in the same hardware the BSC and the BTS so you can get rid of the Raspberry/computer to run the BSC software.
  • Bi-directionality: The BTS could have a transceiver radio module instead of a simpler transmitter to allow bidirectional communications.

Cheap universal radio transmitter / beacon

The purpose of this project was to create a universal radio transmitter that could operate in a wide range of frequencies and modulations, would costs less than 15€ and could work autonomously as a beacon thanks to a microcontroller or controlled externally through an USART.

This board has been used for implementing the Osomcom POCSAG BTS but other uses includes remotes, CW beacons, data links or APRS (using a hack for supporting AFSK).


The universal radio transmitter

Board features

  • CPU: PIC 18F14K22 @ 16MHz
  • Memory: 16KB Flash / 512 Bytes RAM / 256 EEPROM
  • Transmission frequency: selectable from 75MHz to 1GHZ (but some parts values may need to be changed. More about this later)
  • Supported modulations: FSK/GFSK/OOK/GOOK/ASK. (FSK is used for POCSAG)
  • Transmission bitrate: selectable up to 179.2 kbps (512/1200/2400 for POCSAG)
  • Transmission power: selectable up to 14 dBm (20mW)
  • UART/RS232 port
  • Debugging/programming port for ICD/PICKIT
  • Expansion port with 4 digital GPIOs and 1 analog input.
  • SMA connector for antenna
  • Power: 3.3 volts ; ~50mA
  • Size: 4.4 cm x 4.6 cm

Schematic description

osomcom POCSAG BTS - schematic