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 t4f.org/bsc topic to receive messages from the MSC and it will post messages to the t4f.org/msc 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/catalina.properties, 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


The ITU recommendation for the POCSAG standard doesn’t talk about the architecture of a POCSAG network. It only talks about the protocol.
It is task of the manufacturer to decide what architecture use when implementing a POCSAG network.

Without any other reference, I decided to use a VERY SIMPLIFIED version of a GSM network as model. If you know how works a GSM network, you will recognize some names and terms I use here.


The most important part of the Osomcom POCSAG network is the BTS.

The BTS or Base Transmitter Station is the device that transmit POCSAG messages to the pager/beeper.
It is a small board (4cm x 5 cm) with a UHF transmitter and a microcontroller. The microcontroller includes the software that creates a POCSAG package and controls the UHF transmitter to transmit the package.
The BTS is not connected directly to the network but to a BSC trough a UART (RS232) connection. The BTS is dumb in the sense that the only thing that does is transmit the message received from the BSC to the pager and nothing else. All the “network intelligence” is provided by the MSC and the BSC.

For more information about the BTS hardware and firmware, check the corresponding section.

The BSC or Base Station Controller is the system that provide intelligence to the BTS and connect it to the network. One BSC normally controls one BTS but in larger networks or networks working in several radio bands, the BSC can control two or more BTS.
The BSC is connected to the rest of the network using MQTT or a REST web-services interface. The MSC will use these protocols to control the BSC and sending messages.

Currently the BSC runs in a Java Virtual Machine, so any computer or system with Java, TCP-IP and a serial port to connect  to the BTS could host the BSC. Any cheap and old PC will work, but ideally a Raspberry should be running the BSC software. Raspberry is cheap (<30$), small, low powered and has enough computer power to run the software.

For more information about the BSC software and how to install it, check this.

The system formed by one BSC and the BTS (one or more) that controls is called BSS or Base Station Subsystem.
The BSS can be considered like a transmitter node and the basic unit used to create the POCSAG network. You will use as many BSS as needed to create the signal coverage area you have planed.

Currently this BSS are composed of a custom electronic board (the BTS) connected to a Raspberry or other computer (the BSC), but in the future I will design a single cheap board that will run the entire BSS.

At last, all the BSC in the network are connected to a MSC or Mobile Switching Center that contains most of the logic of the network.

The MSC provides tools to register users (subscribers) to the network, create groups of subscribers, and send messages. It also manages the BSS of the network. All this can be done thanks to a web interface, MQTT and a REST API, so integration with third-party software can be easily done.

The MSC also runs on a Java Machine. Raspberry or similar cheap ARM board is again the best choice. The MSC can also run in one of the BSC machines so no other computer is needed.

For more information of the MSC software and how to install it, check the MSC section.

Osocom POCSAG Architecture

Osocom POCSAG Architecture

All the componentes of the network have been designed to operate independently, that is… you dont need all the componentes to send messages to your pager.

For a very simple network you dont need the MSC. You can send messages using the testing web interface of the BSC. Of course, you will not be able to distribute the message to other BSSs and will not be able to create groups or use other more advanced features that provide the MSC.

For a even more simple network, you dont even need the BSC! You can connect the BTS to your computer trough the RS232 and send the messages using the commands described in the BTS section. This can be useful to make tests or to connect the BTS to an arduino for sending you messages in case some event happens.


Let’s analyse different scenarios.


The simplest case is when you use just a BTS to create a test network.
In this situation, you will be able to use the RS232 port in the BTS board to send messages to a pager using its RIC number. Check the commands available in the BTS section in order to know how to operate with the BTS through the RS232.

No other network intelligence is provided as no BSC or MSC is present, so the funcionality is limited. However, this configuration is very useful to test your pagers or doing small experiments.

One simple BSS (One BTS + one BSC)

Adding to the previous configuration a raspberry PI or any computer with Java with the BSC software, we will have an full BSS system.

The BSC will provide a network interface and a REST (WEB services) interface to send messages. A test web interface provide a easy way to send the messages to pagers.

Please, refer to the BSC section in order to know how to install the BSC software in a computer and how to connect the BSC to the BTS.

One BTS + one BSC + one MSC

In the same computer or raspberry pi board we have the BSC software installed, we can install the MSC software.

Thanks to the MSC we will be able to create subscribers and groups, so no need to memorize RICs.

This is the most recommended configuration for testing purposes.
Keep in mind that with a single BTS, you can’t expect a big signal coverage area. The current BTS board transmits with 20 mW, so don’t expect a coverage range longer than 50 meters. I am planning to add a power amplifier in the BTS board to transmit up to 24dBm (250mW), but meanwhile if you need longer range, you will need more BTSs

Read the MSC section to know more about the software and how to configure it.

One MSC and several BSSs

Probably you will need a longer coverage area, so you will have to add more BSSs. The MSC will manage the BSCs and it will synchronize the BTSs to avoid collisions when sending messages.
In the MSC section, you can read how to manage the BSCs to create bigger networks.

Introduction to Osomcom POCSAG

Osomcom POCSAG is a free implementation (open software / open hardware) of a POCSAG network that allows to acreate 100% functional pagers (AKA beepers) network.

It has been designed in order to minimize the cost in time and money of the network deployment and to simplify the process of extending the network capabilities.

Thanks to a mesh of cheap base transmitter nodes composed of a Raspberry PI and a specific designed radio board is easy to provide coverage to small and medium areas. A master node controls the network status and synchronize the message transmission process.

What is a pager?

If you dont know the relationship between these two objects

Age Test

you probably won’t know what is a pager:


For those who have born in the last 20 years, pagers (also know as beepers) were the most common personal communication device from the 80’s to the end of the 90’s.
A pager is a small electronic device able to receive messages sent by a network operator. When a person wanted to contact you, he had to call to the network operator phone and tell your subscriber number and the message. In few seconds the message was received in your pager.
This was a one-way direction communication, so the person that sent the message normally gave a (fixed) phone number where could be reachable for a reply.

Beside the simpleness on the system, it was very reliable and very extended. It was only superseded by the mobile phones when these became cheap in the mid-late 90’s and the mobile phone networks had as much coverage as the pager ones.

Still nowadays there are some niches were the mobile phones cant substitute the reliability of the pagers. Is not uncommon to see pagers in hospitals or fire and police departments.

What is POCSAG?

There are in the market different pager solutions like TAP, Golay, ERMES… but the most common and extended was – with the permission of FLEX – the POCSAG system.

POCSAG (Post Office Code Standardization Advisory Group) was originally created by the British Post Office, but later adopted internationally and adopted by the ITU (International Telecommunication Union in the 1982 as the ITU-R M.584-2 recommendation. It was soon adopted in most of the countries with several providers offering nationwide coverage or at least metropolitan coverage.

For more details about the POCSAG protocol, you can google for “POCSAG” or “ITU-R M.584-2″ but the most important technical details are:

  • It works in a single frequency channel, normally around 140MHz, 430MHz or 900MHz.
  • The protocol was designed to minimize the pager power consumption by keeping it sleeping most of the time.
  • The modulation was 2-FSK with a ±4.5 kHz shift.
  • The supported baud rate was 512, 1200 or 2400 bps
  • The messages can be numeric, alphanumeric or just a ring tone.
  • Each pager has a unique number that identify it in the network: the RIC or Radio Identity Code. This RIC is 21 bits, so the network has capacity to address up to 2,097,152 pagers.
  • Some pagers have several RICs, some of them shared with another pagers. This was a simple way to create groups. If a message is send to the shared RIC, all the pagers in the group will receive it at the same time.

Another common pager protocol is the propietary FLEX from Motorola. This project is not aimed (at the moment) to offer FLEX support as I dont have all the information I need.

What is OSOMCOM?

OSOMCOM is a recursive acronym that means “Osomcom iSnt OsMoCOM” as a tribute to the OSMOCOM project.
The OSMOCOM or “Open Source MObile COMmunications” is ) is a collection of Open Software projects that implements a variety of communications systems, from GSM to DECT, TETRA or others.

As I consider myself a “fan” of the OSMOCOM project and I share the goal of creating a open implementation of a mobile communication system, I decided to call the project OSOMCOM POCSAG as tribute.
In the other hand, the word OSOM-COM pronunced in Spanish sounds very close to the English “AWESOME-COM” and… we all know that this project is OOOOOOSOM!!!

In any case, I don’t have any relation with or endorsement of the OSMOCOM people and you should not contact them for anything related with the OSOMCOM POCSAG.


Then… what is OSOMCOM POCSAG about?

As I introduced before, OSOMCOM POCSAG is a free/open implementation of a POCSAG that allows to implement a real and functional network.

This network features:

  • Multi-node network that allow to extend easily the coverage.
  • Possibility to work as a private closed network or as an open public one. As a public network, anybody could install a node in his home and register it in the public network to extend its coverage (similar concept to the FON and FONERA WIFI network).
  • Supports:
    • 512, 1200 and 2400bps transmission
    • Alphanumeric, numeric and ringtone messages
    • Multi-channel transmission (can transmit in different frequencies)
  • Simple anti-collision system to allow the overlapping coverage of close nodes working at the same frequency.
  • Groups support to allow mass sending.
  • RIC scanning (useful for discover an unknow RIC or for spamming)
  • Web interface to manage subscribers, groups and nodes and to send messages.
  • Public web API (REST interface) to operate with third-party applications and implement new features (ex: email-to-POCSAG bridge).
  • VERY CHEAP hardware. Each node transmitter cost around 15€ (plus 20€ for a Raspberry PI or similar board).

The network consist in one or more transmitter nodes, each of them is composed of a radio board that implements the full POCSAG stack and a low cost computer – like the Raspberry PI – that connect the node to the rest of the network using TCP/IP and a web API.

The network is controlled by one master node that manage the nodes and send them the messages to transmit. The master node also runs an admin web interface to manage the network, the subscribers and sending messages.

For more information about the network architecture, check the architecture section.

But… why create a POCSAG network?

May be you are thinking “Pagers? That is sooooo 90’s!”. Why do we want to make a pager network if we have mobiles?

Real hackers use pagersIf you are too young to know what is a pager, you probably haven’t seen the 1995 ‘Hackers’ movie

All jokes aside, why do we need a to create a POCSAG network?

Well… because we can! Do we, geeks and hackers, need another reason?

The possibility of running a different communication network and learning a lot about it is enough motivation to work on the project. You can’t imagine the excitement of seeing my 1998 pager beeping again after 15 years!

In addition, there are still some cases where a POCSAG network can be useful. Pagers have some advantages over the mobiles phones:

  • Less battery consumption. One AAA battery can power a pager for one whole month. How many hours does your SHIT-Phone 5 last?
  • Less bandwidth consumption. One single 15KHz wide channel can offer service to up to 2,097,152 pagers. How many tens of MHz does the GSM network use? The lower bandwidth the less the operator has to pay to the government for the radio spectrum.
  • One-way communication means smaller receivers. Pagers don’t need a powerful transmitter to reach the operator towers, so they can make smaller devices.
    This also means that the towers can be more separated. In fact, one single tower could cover a 40km range area.
  • Immediate reception even when multicasting to a group shared RIC. There is no ringtone, no busy signal, no delay.
    That is the reason why firefighters or doctors are still using pagers.
  • There is no acknowledgement of receipt and no way to know if the pager is connected. Tracking is impossible. This can be very interesting in cases when you dont want to be located.

As an example of use, private pager networks are still very common in hospitals.Small transmitters are installed in every floor and pagers are handed out to the doctors and nurses on guard. In case of an emergency, a message is send and received instantly in all the pagers so the closest doctor can handle the emergency.
Imagine implementing the same feature using a mobile network. Have you ever measured the time that pass from the moment you press the “SEND SMS” button to the moment  the message is received? No less than 10 seconds. And because the SMS are not multicast, if you want to send to the message to in example 15 doctors,  you will need 10*15=150 seconds to inform all the personnel. Not feasible.

Is this legal?

It depends on what frequency you use to operate the network.
Each country has its own laws regarding the use of the radioelectric spectrum and you should consult them before running any POCSAG network. Transmitting radio signals in a non licensed band could be a punishable offence.

In most of the countries is illegal to transmit a radio signal in a frequency if you haven’t paid for a license to do so. However, there are some exceptions.
As orientation (but I insist… you have to check your country’s law!), most of countries have some free bands where you can transmit without any license (but with some power and bandwith restrictions). These free bands includes the famous ISM (Industrial, Scientific and Medical applications) band at 433MHz, 867MHz (915 MHz in USA) and 2.4GHz where all the cordless devices like wireless earphones, wireless phones, bluetooth, WIFI… works. A POCSAG network working in this ISM bands will be probably legal and will not require any license.
Fortunately nowadays is easy to find in USA old pagers that work at 925-935MHz, very close to the ISM band. It shouldn’t be hard to modify them to work in the ISM band.

In some cases, it is possible to operate without a license in some frequencies out of the ISM band if you limit your power and band usage. In theory, these transitions are for experimental purposes. Maybe is possible to operate a small private network in your installations using the original frequency of your old pager operator. This way you don’t need to modify the pagers to work in other frequency. Again, check your local regulator and be sure you don’t disturb any legit transmission before sending anything to the air.

At last, you can always ask for a license. If you don’t have any commercial intention, you probably can get a temporal license for experimentation and for free.

But… I have seen other POCSAG projects out there. Why this one is special?

Yes, it is true. There is a lot of POCSAG projects in Internet, but all of them are encoders or decoders. They encode or decode the POCSAG protocol but those projects don’t cover the transmision of POCSAG message. All of them relay in a external ham radio device to transmit the encoded signal and that radio can be really expensive.

Those projects aren’t either real functional networks. They are good enough to transmit test messages to a pager but you will not be able to create real networks because they can’t, in example, manage users, groups, multi-node architecture or they don’t have a nice GUI

The aim of this project is to create all the hardware and software needed to have a real full POCSAG network, not only for experimenting.

OK! You convinced me. What do I need to run my own POCSAG network?

First of all, you need to decided in what frequency are you going to transmit. In the previous section I wrote about the legality of choosing different bands. YOU are the only responsible of transmitting in an inappropriate band without a license.
Osomcom POCSAG software and hardware permit to transmit in any frequency. The hardware permits even to change the transmission frequency on-the-fly, so you can operate in several channels.

Plan your coverage area. With the power restriction you have on the transmitter nodes, calculate how many nodes you will need. At least, you will need a transmitter node and a master node. To save some money, you can run the master node software in one of your transmitter nodes.
For the details about how to create a node, read the Architecture section.

At last, you will need the pagers.
You can buy easily them in ebay or similar, but be sure that they are POCSAG and not FLEX. Some models (specially Motorola and NEC) were sold on both systems. Check the serial number to be sure if it is POCSAG.
Check also the operation frequency. If the pager works in a different frequency, you can rework the receiver board to change it. If the pager worked originally in the same band and a close frequency, may be you only have to change the crystal oscillator and adjust one or two varicaps. There is old information out there in Internet explaining the process for different pagers.
If the band is a very different one, you will need to change the filters and the antenna adaptation stage too. Buy another pager instead!
The RIC of your pager is also important. Sometimes it is written in the pager or you can read it accessing a hidden menu but if not, you will need to read it using an special software, to extract it from an EEPROM dump or to do a RIC scanning. More information about that in this section.

Videos and photos

Here you can find some videos and photos of the OPEN RFID Tag.


“Toilet paper” versions

Before going to a PCB prototype, I tested several designs and firmwares using a breadboard. In order to make the antenna, I used a toiler paper cardboard.

This photo shows some hand-made antennas and a USB  RFID reader made with a breadboard and a stripeboard.

Using this early prototype to clone my RFID garage key:


Version 0.1

Once the firmware was totally developed, I made a PCB with a printed antenna.

This DIP prototype lacks of some features like the AGC (Automatic Gain Control), so I had to solder some components “in the air”.

The video shows the “general purpose firmware”, version 0.2.

Version 0.2

SMD version with a new antenna design and one more LED.

This would be the final version, but I found a problem with the ACG just 5 minutes before sending it to manufacture.

Version 0.3

Like version 0.2 but with a “missing” component. This is a small batch of manufactured PCBs. You can get one.

Using it to clone a HID card:

With the “on-the-fly cloner” firmware:



Coming soon.

Introduction to my Business Card

After 4 years working in an international IT consulting company, I have decided that now it is time to change my current professional career.

The world of the business software (for banking, insurance, services…) is boring, monotone and it is not  challenging enough for me. I would like to redirect my labor situation toward a field more related with the electronic engineering, which is my real passion.


Unfortunately, if the opportunities to work in electronics were scarce and poor (specially with ASIC or RF design, my two favorites  areas), now with the current economical crisis… finding a job (or even an internship) in this field is almost impossible. Or at least, I had no luck so far even considering that I am open to work anywhere in the world.



First impressions matter

In this hard scenario, the Human Resources recruiters receive hundreds of resumes a day from people competing for the same position.

With this avalanche of CVs is impossible for HR to make a full assessment of each candidate. Therefore, the first filtering criteria that is usually applied is the presentation: If your resume does not cause a good impression to the recruiter from the first moment, you will be automatically discarded, regardless of your qualifications.


Any chance to make your CV stand out from others must be seized. A good cover letter and a good presentation is essential, but do not ensure you that will catch enough attention from the reader.
Is at this point when I had the idea to design my own business cards to attach with my resume or give in interviews.


This card, in order to be “flashy”, had to meet the following requirements:

  • Contain my contact information (Captain Obvious to the rescue!).
  • Convey professionalism.
  • Serve as an example of my engineering skills.
  • Have some use besides being a business card. This way, it would prevent to be throw away at the first opportunity.

At first I thought about making a version of my Open RFID Tag with one side of the PCB printed with my contact details and a firmware preloaded to emulate some RFID tag containing the same contact info.
I discard the idea because  few HR recruiters must have an RFID reader in their offices or homes, so they could hardly see the card working.

At the end I opted to do some kind of USB-device card.



My business card

The result is a card with the size of a credit card (85.6 × 54 mm, although thicker) with two punched corners.
In the center there is a “window” to accommodate the microcontroller soldered bottom-up. Otherwise, If the micro was soldered on the PCB (bottom-down), the card would have been very thick and could not be stored comfortably in a pocket wallet.

The front side has my contact details and  the back side has all the electronic parts soldered.

Front side, with the contact information  (phone number censored in the image)


Back side, with the soldered parts.


The corners can be torn apart, exposing an USB connector that lets you plug the card directly to your computer


Corners torn.


The card plugged to the computer



When the card is connected, the computer recognize it as a mass storage unit and will open automatically (Autorun.inf) my resume, cover letter, portfolio, website or any other document.



The main purpose of the card is to work as an USB memory.

The firmware uses the internal flash of the microcontroller, so the capacity  of the mass storage unit is only 24 KB max. Enough to put a cover letter and resume in HTML.
If more memory is needed, the current PCB and circuitry supports  an external 8-pin SPI (or I2C) flash memory chip (up to 32MB!). Interesting for providing the project documentation or code!

In addition, the microcontroller firmware includes a bootloader that allows you to run small programs stored in the USB drive. These programs add functionalities to the card.

At the moment, the following applications are available:

  • Datalogger:
    Capture digital signals.  Capturing modes (without compression / worst case):

    • 8 channels @ 500KHz
    • 4 channels @ 1MHz
    • 2 channels @ 2MHz
    • 1 channel @ 4MHz.
  • Oscilloscope :
    10 bits of resolution. Capture modes:

    • 4 channels @ 67.5KHz
    • 2 channels @ 125KHz;
    • 1 channel @ 250KHz;


These other applications are under development:

  • USB to RS232, SPI, I2C or CAN adapter (bridge)
  • General purpose I/O port for controlling electronic devices and circuits.


Moreover, all the microcontroller pins are available thanks to a Molex connector (not soldered), so the card can also be used as a trainer board for the PIC 24FJ64GB002. Useful for those who wants to enter into the world of microelectronics and embedded systems.


Clearly, it is not the cheaper business card in the world (about 5 euros/piece for a small batch order), but it is a (relatively) small price for having a card in your pocket that has more CPU power than the computer that led the man to the moon.


Technical specifications

  • 16 bits microcontroller PIC 24FJ64GB002  @ 32 MHz (16 MIPS)
  • 64 KB of Flash and 8KB of RAM. External SPI or I2C memory optional (up to 32MB)
  • Up to 11 digital I/Os available (Four of them tolerant to 5 volts)
  • Up to 4 analog channels.
  • ICSP port for debugging and programming. The 3 pins of the ICSP connector can be also used as GP I/Os.


Applications, source and schematics

Click on the image to download the schematics:



I will release the apps and sources under a GPL (or similar) as soon as I solve some questions regarding to the licensing.
The firmware uses part of the Microchip USB stack implementation, whose source is royalty free but is not licensed under an Open Software License. I need to know the limitations of this license before releasing the code.