Getting started with the NTX2B and the Arduino – Part 1 The Basics

A while ago now I wrote an article for the UKHAS website on linking an NTX2 to the Arduino. This tutorial, available here : is still valid however there are other ways to modulate the NTX2 or the NTX2B to get RTTY.

In part 1 of this article I’ll discuss using PWM to generate the required voltages to modulate the NTX2B, the physical wiring, how to test it and sample code. Part 2 will extend this to transmitting RTTY and finally part 3 will discuss using this to transmit DominoEX.

Please follow this entire article the basic code allows you to demonstrate step by step that your circuit is working.


Getting your Arduino to transmit via the radio initially may seem daunting but its actually pretty simple. Please freely substitute the word “Arduino” for any micro-controller you wish to use. The example below works for 5V and 3.3V micro-controllers.

Please read this :

This may be the first bit of code you’ve come across with regards to creating a radio tracker. There is always the temptation to cut and paste it and away you go. And in isolation this may work. However should you then cut and paste further code without understanding what is going you will end up with an unworkable mess and something that is next to impossible for us to assist you with. Please take the time to work out what the code below is doing, redo it yourself, break it, fix it most importantly understand it.


You adjust the voltage on the NTX2’s TXD pin which adjusts its transmission frequency slightly. The difference in this frequency is called the shift. By doing this in a controlled fashion you can transmit 1’s and 0’s and therefore transmit meaningful data.

The NTX2 is a FM (Frequency Modulation) module intended to have a voltage applied to the TXD pin of between 0 and 3 volts. This voltage range changes the output frequency of the module by about 6KHz (i.e for a 434.200Mhz module 0V on TXD = 434.195Mhz and 3V on TXD = 434.202Mhz.

This means for each 1Hz change in frequency you need to change the voltage by 0.0005v (3 divided 6000) so to get a shift of 500hz you need to toggle the voltage applied to the TXD pin by 425×0.0005=0.2125v.

To get this voltage shift we are going to use PWM (Pulse Width Modulation). See this article for more information on PWM : The resolution of this is 8 bits which means the Arduino can change the voltage by 256 (2^8) steps. This means the maximum voltage of 5V can be broken into 5/256 steps or  0.0195v per step. The maximum input of the NTX2B is 3V therefore there is no point applying voltages of greater than 3V. As a decimal this means 3/5* 256 = 153.

In theory the standard shift of 425Hz equates to a 0.2125/0.0195 = 11, however in reality on an NTX2B a value of 10 gave a perfect 425Hz shift. Don’t get too hung up on getting the exact shift, any shift from 350-500Hz is fine.

Items Required

Radiometrix NTX2B
Arduino or similar micro-controller

Circuit Diagram

Connect Arduino 5V to the NTX2B VCC pin 5
Connect Arduino 5V to the NTX2B EN pin 4
Connect Arduino GND to the NTX2B GND pin 6
Connect Arduino pin 9 to the NTX2B TXD pin 7

Once done it should look like this (you don’t need an antenna in at this point) :

The Code

The code is similar to the Fade example built into Arduino (File->Examples->03.Analogue->Fade)

 Demo Code to Drive NTX2B via PWM

 Written by Anthony Stirk M0UPU

 This example code is in the public domain.

#define RADIOPIN 9

void setup() {
 setPwmFrequency(RADIOPIN, 1);

void loop() {
void setPwmFrequency(int pin, int divisor) {
 byte mode;
 if(pin == 5 || pin == 6 || pin == 9 || pin == 10) {
 switch(divisor) {
 case 1:
 mode = 0x01;
 case 8:
 mode = 0x02;
 case 64:
 mode = 0x03;
 case 256:
 mode = 0x04;
 case 1024:
 mode = 0x05;
 if(pin == 5 || pin == 6) {
 TCCR0B = TCCR0B & 0b11111000 | mode;
 else {
 TCCR1B = TCCR1B & 0b11111000 | mode;
 else if(pin == 3 || pin == 11) {
 switch(divisor) {
 case 1:
 mode = 0x01;
 case 8:
 mode = 0x02;
 case 32:
 mode = 0x03;
 case 64:
 mode = 0x04;
 case 128:
 mode = 0x05;
 case 256:
 mode = 0x06;
 case 1024:
 mode = 0x7;
 TCCR2B = TCCR2B & 0b11111000 | mode;

Excluding the setPwmFrequency procedure (all this does is set the PWM speed as quick as it will go to made the voltage presented to the NTX2B PWM pin as more “analogue”) this code simply opens pin 9. It then alternates the voltage on this pin by 10 every 1/2 second. You can plug an LED into pin 9 to see what its doing.

Load this code up to the Arduino.

Ok now take your radio and tune it into the frequency of the NTX2B module. You should hear the high and low tones. If you’re using an RTL + SDR# set the frequency to something above the frequency of the module, i.e in this example our NTX2B is transmitting on 434.200Mhz so I’ve set SDR# to 434.500Mhz. You can see a peak on the left of the spectrum analyzer at the top around 434.200Mhz :

If you’re unsure if this is the radio, turn it off. It will disappear. Zoom in the line using the zoom on the right. You may want to increase the resolution in the FFT Display at this point, with a resolution of 262144 you should see some distinct high and low tones separated by about 425hz :


Congratulations you’re transmitting. If you’re ever unsure if your radio is working you should step back to this extremely simple code to check the basic operation. Now move to part 2 of this article to transmit some meaningful data :

5 minute guide to making an GPS synchronised NTP Server based on a Pi

EDIT : I’ve confirmed the version of NTP provided in the Open Chaos download below isn’t susceptible to the DRDoS / Amplification Attack using ntpdc monlist command discussed here :

Working in IT I’m aware of how keeping accurate time is important, generally most of the time we will point our devices / equipment at however there may be situations where a local time source is preferable. This can be for a number of reasons,  where no internet is available, radio amateur’s doing meteor scatter etc.

David Taylor from has done a comprehensive write up of getting the Pi to work as a Stratum-1 NTP Server. Taking this work Hauke Lampe has created an image with all the hard work done. With no compiling to be done its possible to get a Pi working with as a Stratum 1 NTP Server in less than five mins.

First you need a Raspberry Pi GPS Addon board available at Hab Supplies. Secondly you need a patch antenna (see related products). Thirdly get the minimal SD-card image based on Raspberry Pi’s Raspbian “wheezy” distribution featuring PPS-enabled kernel and ntpd by Hauke here :

Pop the image on an SD Card. Plug in the antenna and the GPS board and power on the Pi.

Thats it really it will boot up and work as an NTP Server.


I run the following commands as well :

sudo apt-get update
sudo apt-get install raspi-config (Use Raspi-config to resize fs)
sudo apt-get upgrade
sudo apt-get install gpsd-clients

Please be aware if there is a new kernel it may over write the Kernel with PPS support in it. You can from here install SNMP, monitoring as per Davids page here :

A nice cheap very accurate time server for less than £100!

NTPi – Raspberry Pi as a Stratum-1 NTP Server Hardware Part 2

Having had a chat with a number of people about my previous LEA based NTPi board here a few things were apparent. Firstly designing a board to fit a Pi you’ve removed the composite header from was silly and not checking it on a stock Pi the board results in it not fitting. Secondly the LEA based board is probably more complex that most people need for a Pi based NTP server.

The new positioning modules from Ublox the MAX-7 series are cost effective high performance and provide the PPS output needed for accurate time keeping. I set about designing a simpler board around the MAX-7Q module.

The MAX-7Q positioning module features a RTC Crystal, very low power usage and high performance. Although not a true timing module it is more than adequate for a Pi based NTP Server. Its worth noting the module can, with a serial command, be placed in “Stationary” dynamic mode which is the default mode for the much more expensive timing modules.

Also of note is the PPS output can be, again with serial commands, be increased to an output of up to 10Mhz for other applications.

To keep the board simple it just features the MAX-7Q, a Raspberry Pi header, battery, power and PPS LED’s and provision for an SMA connected active patch antenna (puck) :


The MAX-7Q is connected via serial to the Pi and the PPS is connected to GPIO18 (pin 12). The design is such that it should fit in a case (I’ve only tested it in the Multicomp MC-RP001). The Pi GPIO’s are passed through to an unpopulated header should you wish to connect other items to the Pi. When in place the antenna cable exits between the USB and RJ45 connectors :

ntpi-2A simple snip of the case with some wire cutters allows the top to be attached :


Resulting in a nice tidy NTP Server. The made up boards can be purchased from HAB Supplies here

I haven’t intended this board to be used in Pi powered HAB stuff due to the way the Pi interfaces with radio the GPS needs to connect via I2C. This board connects the GPS via serial so please bear that in mind.

I also took the opportunity to fix the design fault with the LEA eval board and can also supply these with LEA-6T timing modules or LEA-5S modules as needed. The LEA eval board is designed as more of a multipurpose board featuring PPS and (where LEA-6T fitted) PPS2 outputs. SMA or u.FL inputs. USB to connect to a PC, Pi header to connect to a Pi, generic header for other uses. Board can be powered by header, USB or Pi header. The board does fit in a Pi case but its tight and the antenna exits over the HDMI :

ntpi-4If this board is of interest leave me a message and I’ll contact you to discuss your requirements.

NTPi – Raspberry Pi as a Stratum-1 NTP Server Hardware

David Taylor over at Satsignal.Eu has done a wonderful article on turning your Raspberry Pi into a Stratum 1 NTP server. A Stratum 1 NTP server is one that is connected directly to a Stratum-0 device such as a GPS. I made an initial device up based one of the Ublox GPS modules from Hab Supplies however with its passive antenna and limited wiring it had to be near a window to work.

Also the MAX6Q GPS modules used aren’t designed for timing applications, however that said I achieved a fairly reasonable level of accuracy of 6ms. I decided to make up a PCB to utilise the proper timing module the LEA-6T this would act as an evaluation board featuring USB for connection to a PC, separate outputs for the PPS and PPS2 finally it would feature a header to permit direct connection to the Raspberry Pi.

Osmocom have designed a PCB which is similar however I have enhanced it a little with a PPS LED, Raspberry Pi header and I changed the regulators as the LEA doesn’t need the larger regulators. Additionally the Osmocom part for the LEA had some very odd solder mask on it and had to be redone.IMG_1937Here you can see the board with an LEA-5S on for testing. Although it looks similar to the Osmocom part the board was designed from scratch this fits on the Pi :IMG_1934The case still fits on nicely (with a little modification!) :IMG_1935

I‘ve released this board as open source and its on Github here. I do have some spare PCB’s free which I can supply to your spec with either a LEA-5S fitted or the LEA-6T. PCB’s are £3.50 , boards assembled with LEA-5S are £40.00 and with the 6T £100.00. Send me a comment if this is of interest, these boards will be built to spec.

A Stratum 1 NTP server for £50 is a bit of a bargin!


A number of people have asked for some more technical details on the AVA tracker hardware. The full name for the board is PAVA/ATLAS and it is a prototype based on my existing PAVA boards developed with the help of James Coxon, Phil Heron, Nigel Smart, Ed Moore and Dave Akerman.

PAVA is a 70cms tracker board based on an ATMega328P Microcontroller, Ublox MAX6 GPS and a HopeRF RFM22B radio module. PAVA was born from a desire to make a tracker small enough and power efficient enough to be run from a single battery for enough time for a flight and possibly to reside in the neck of a balloon. To facilitate the use of the single cell a Texas TPS61200DRC boost converter is used.

The board was designed to initially run at 3.3v but have the option for running at 1.8v for increased power savings. 3.3v boards use a TPS61201 with a 0R0 in place. 1.8v boards use a TPS61200 with a 510k / 197k resistors to set the voltage. When running at 1.8v the AVR uses a 4Mhz crystal, 3.3v uses an 8Mhz crystal. Extensive work was done on the software and with a combination of the 1.8v hardware and the power saving in code the battery life was increased from 11 hours to about 47 hours.

2012-12-27 14.25.18

A combination of the the hardware and software meant the PAVA boards were a very light, robust and good base for future projects.

PAVA/ATLAS was born out of Project Swift. The Swift board was a powerful but large board designed to do concurrent APRS transmissions outside of UK airspace and transmit RTTY telemetry as well. Although a good board there were a number of issues with Swift, namely the power requirements, weight and cost. James Coxon proposed a light weight version that could do the same but potentially under a foil balloon.

Taking the existing design for the PAVA boards a modified version was made to facilitate mounting a Radiometrix HX1 transmitter piggy back on it. Retaining the existing 1.8v board additional features were added, the GPS was wired to the batteries for hot starts. The GPS has a FET based power switch so it could be turned off entirely. The HX1 was mounted on a separate mezzanine board.

With its own 5V step up that could be switched on and off from the AVR it only needed to be on when transmitting then it was turned off again. To get the voltage up to the right level a transistor was used. The HX1 board mounted on top of the microcontroller board. To ensure the GPS antenna wasn’t obscured by the HX1 the board was extended slightly.

The board is very prototype and there are a number of errors on it :

a) RFM22B must be pulled down not up. This is fairly easy to fix as SDN is right next to GND so you can bridge it with a 0603 10k.
b) HX1TXD pin fouls the ICSP header. This was just a stupid mistake, you end up bending the pin to get the programmer on.
c) Holes for the Samtec headers are too large.
d) A polygon priority mistake left VBATT connected to GND. Pretty much a show stopper fixed with some careful scalpel surgery.
e) HX1 APRS TXD is on pin 11 which is use by the RFM22B. Cut the track and rewired it to the other interrupt pin 3.

Microcontroller board on the left, HX1 board on the right:


Underside (RFM22B & GPS to be attached)IMG_1065

The board weighed in at 16g and could run for way over 24 hours from a pair of AA’s with the APRS transmitting every 2 mins.

Hardware is only half the story. To comply with the UK legislation the APRS transmitter could not be used in the air (this also applies to other countries in the EU). Taking geofencing code from Project Swift & work done by Steve Randall a map of Europe was built up using Google Earth ( See this map ) and converted to code. See this post for more info: Preparing for a European Floater.

Once the payload knew where it was it could disable the APRS transmitter to comply with the local legislation. Additionally it could generate the correct ITU prefix for the callsign. This code was tested on two PAVA flights without the APRS module attached to iron out any bugs. The first test indicated the UK Geofence wasn’t correct.

The code use is here :

The board will probably be redesigned as a single PCB.

European Tour – Success!

Day 1

What a weekend! I’m happy to report an extremely successful pair of flights for both PIE & AVA. For a write up on PIE please visit Dave’s blog at

The morning started in a muddy field in Cambridgeshire, we’d agreed to meet nice and early about 9am, it was a pleasant if windy day :


Eben & Liz from had come along to assist with Dave launching the Pi Camera, in tow was a reporter doing an interview and Graham G3VZV had come along as well.

The plan for the day was to launch two 1600g Hwoyee balloons with very slow ascent rates (we were aiming for 1.5m/s). The slow ascent rate would increase the chances of the balloons entering a float (i.e not bursting) at altitude and extending the flights. The trouble with low ascent rates is measuring the neck lift of the balloon is very tricky, near impossible in any sort of wind whatsoever. Here Eben holds one balloon whilst Dave filled the second one :


The neck lift on the balloons was about 300g with my payload coming in at 180g and Daves a little more. The balloons with so little gas in also act like large sails pushing the balloon down into the ground. Here Eben and Liz hold the balloons :


At about 11:44 UK time with the balloons filled we decided to launch, the wind was dragging the balloons horizontal as you can see from this picture from my perspective :


With a break in the wind we took a run and released both balloons (Thanks to Alex from for capturing the stream)

Daves rose slowly upwards and mine err didn’t. AVA got to about 160 meters and then stopped ascending. We watched as the payload just cleared the trees about 0.5km away, telemetry indicated the payload started to descend so we quickly threw everything in the car (sorry stream users that’s why the stream died).

Thankfully just as we were about to go chase it AVA decided to start ascending properly.This continued until just after 1pm at about 6200 meters in altitude where abruptly the 70cms radio packed up. We were unsure if it was just the cold affecting the transmitter, we wouldn’t know until it made landfall near the Netherlands where the second, APRS, transmitter would hopefully fire up.

At 15:30 as the payload entered the Netherlands airspace the APRS transmitter fired up and was igated up to The HABhub team quickly transposed this on to As the payload left the Netherlands and entered Germany the APRS continued to transmit.

Suddenly at 20:45 a Polish HAM SP3MCY started uploading telemetry from the 70cms transmitter, it had come back to life! At about the same time the APRS decided to stop working entirely (it wasn’t to come back for the rest of the flight). It was obvious something wasn’t happy as the 70cms kept stopping and then coming back. My code does regularly reboot the RFM22B so this is possibly what kept it working.

At about 22:00 stopped transmitting again. AVA had gone silent and dropped to about 22km in altitude as the gas had cooled down over night. With no APRS and no 70cms telemetry I decided to hit the sack happy the mission had been a success.

Day 2

I woke up at 7am and optimistically glanced at through blurry eyes. To my amazement, AVA was awake, over the Czech Republic and climbing slowly in the early morning sun. DL7AD had received the 70cms transmissions at 0615 UK time, for the rest of the flight the transmitter worked with no failures.

An hour later and AVA had receivers from Poland, Slovakia and Austria tracking it. Over the next few hours AVA climbed to a maximum altitude of 38984 meters, sadly it didn’t get back into a float and around 09:05 UK time AVA burst over Austria and started its decent.

With a rather leisurely decent the payload finally came to rest at the crest of an Austrian mountain 1600m above sea level. We really thought that would be the end of the story. Really I mean who would be able to recover that. We didn’t count on the Slovaks.

Enter Radim Mutina & friends from Based out of Slovakia Radim (OM2AMR) and friends decided to go attempt the recovery of AVA from Austria. The terrain map showed the scale of the issue :


However undeterred the STS Project team headed out. Using APRS to report their position we watched as they took the slow climb up to AVA’s landing location :

radim-5In honour of this we changed their icon to a superman as I thought it was apt! As we subsequently saw from the pictures this was not an easy recovery :


Finally the location of Team STS and AVA were on top of each other, after an initial panic the payload may be in a tree OM1AMJ relayed a message back that AVA had been recovered!


The payload was so high up even on the ground OM1ATS was still receiving it in Slovakia. The final landing position was 47.56405,15.91578.

IMG_6616From left to right  : Peter Vittek, AVA , Radim Mutina (OM2AMR), Juraj Marsalik (OM1AMJ) and behind the camera Brano Janicek.


For full images click here.

So all in an amazing flight covering a distance of 1256km in 22 hours and 29 minutes. My eternal thanks to everyone who turned out to track the payload, I won’t list everyone here as the post would be twice as long and I may miss someone as so many people have contributed to this project. I consider this launch more of a UKHAS group effort. Thanks to for giving us the streaming.

Finally how can you say enough thanks to Peter Vittek, Brano Janicek, Juraj Marsalik, Radim Mutina and Dano Radovic liaising between the team on the ground and IRC. You went  way beyond the call of duty spending all day recovering AVA and documenting it so well for everyone to see. Amazing guys, amazing!

UPDATE : Radio failure appears to have been caused by the insulating foam wedged between the two boards, as the foam had expanded due to pressure it had popped the HX1 board off the controller. Also a nice video from Team STS :

Update 2 : People have been asking for technical details on the transmitter being used. It was a custom design described here :

European Tour – Hopefully!

I am planning on launching from Cambridge on Saturday the 13th of April 2013. With updated code and a map of where APRS in the air is permitted the payload being flow will include the APRS transmitter :

IMG_1211With a pack of 6 x AA batteries (3.6V out seen in pink gaffer in the background ) the payload should have about a weeks power possibly longer.

Assembled in a hollow polystyrene ball with antennas for 70cms (1/4 wave) and 2 meters ( Slim Jim suspended underneth the payload) comes in at fairly portly (for me) 180g :


This will be suspended under a 1600g Hwoyee balloon filled with H2 for an ascent rate of about 1.5m/s. Watch from about 10am on Saturday :


To France! and back!

Dave Akerman kindly offered to launch a MAX7C based board for testing last weekend. I prepared the PCB and posted it out to Dave who sent it up under a 1600g Hwoyee with a slowish ascent rate. The plan was for a float but the balloon unfortunately burst rather than entered into a float.

It did however make it to France (just) :


it appeared the parachute tangled badly and it “landed” in a field at 15.9m/s (44mph) :

IMG_0883The impact although significant (it broke the battery off the board and bent the ICSP connector in the process) the transmitter continued operating. F5APQ kindly located the payload in a frosty field very early the next morning still transmitting :


Jacques kindly untangled the mess and returned the payload to me back in the UK ready to fly again :


So a massive thanks to F5APQ to going out of his way to do that.

Technically the uBLOX MAX7C performed as expected with no blips, the APRS Geofence correctly identified when it crossed into France, shame the balloon didn’t float but a good result in the end!

Ublox MAX7C

EDIT2 : These are now in stock and available at HAB Supplies

EDIT : The extremely long long times were very odd and I’m not sure something environmental wasn’t going on. I’ve subsequently tested both modules repeatedly and from cold inside (in a window) they are getting 3D locks from cold in sub 40 seconds consistently.

Finally the long awaited sample of the new offering from uBlox landed on my desk. The MAX-7C is the latest module from uBlox offering better power usage and performance. Additionally the MAX-7C can run from 1.65v to 3.6v meaning it can be used on both 1.8v and 3.3v boards with no problems. Additionally the UAV/RC crowd will love the 10Hz updates.

Downsides ? No more TCXO meaning lock times may be slower. I set up a testing environment mounting the MAX7 on a breakout with a chip antenna :


Along side was a MAX6Q for comparison. Firstly I ran the MAX6Q noting the power usage from 3.3v :

Aquiring 60mA (Average over 5 mins no lock)
Tracking 44mA (Average over 20 mins)
Cyclic      15mA (Average over 15 mins)

Its worth noting the GPS did seem to take an extremely long time to lock that evening, normally its nothing like 5 mins.

Now the MAX7 :

Aquiring 22mA (Average over 20 mins no lock)
Tracking 17mA (Average over 10 mins)
Cyclic    6mA (Average over 10 mins)

Conclusion : In the very brief test I did the MAX7 did take longer to get a lock than the MAX6, however once it was locked the performance was very similar, I couldn’t tell any difference. However the big difference is the power usage. Reducing the usage in cyclic by over 50% is a massive improvement. I can’t wait to run test one of these on a the PAVA boards.

Additionally I tested 10Hz mode which seems to be pretty good, however further testing is needed. Once I’m confident with it I’ll have these for sale on

Launch! Pico time!

When I sat down and designed the PAVA PCB I had in mind launching this under a small foil balloon. These are interesting for a number of reasons, firstly you don’t need a NOTAM, secondly under the right conditions they can float. Although alot of these foil pico launches have been done by members of the UKHAS community I decided it was time for me to do one.

Armed with some 36″ Qualatex balloons from Random Engineering I set about making a very small and light payload based on a single AA and the PAVA R7 PCB :

IMG_1061Coming in at 27g the antennas were made from the inside of CAT5 cables. The case was made from a hollowed out piece of insulation with additional thin insulation in close contact with the PCB. See here for further build images :

To fill the balloon I used a piece of thin tube. I’d been advised to aim for a neck lift of about 1g, to measure this I had a piece of blutac 1g heavier than the payload. I was suprised how quickly the balloon filled up and it may have been slightly over filled :


Launch was extremely windy :

I was happy to see it go as it was pulling towards the ground. Once in the air it floated up gently with an average ascent of about 1-1.5 m/s. Now in theory these things should float at about 4500m but PAVA didn’t it carried on upwards unfortunately too high for the balloon to remain intact. All of a sudden PAVA started to fall at an alarming rate.

Normally with Pico’s they are so light the balloon acts like a streamer slowing down the decent, however there was nothing slow with the 12m/s it hit the ground at. Fortunately it appeared to land in a field. About an hour later we started getting telemetry from the payload again, it seemed one of the people who had been tracking, 2E0KPI had decided to and have a look for it.

Despite the dramatic decent PAVA was still transmitting, however with fading light 2E0KPI was unable to locate the payload. He kindly agreed to go back the next day and have another look where he located PAVA, still transmitting, in a field. The reason for the descent rate was clear, the balloon had blown its valve entirely out :

03032013133A big thanks to 2E0KPI for locating the payload and to all the trackers. I’ll have another go at this soon. Congratulations to James Coxon M6JCX who launched an ATLAS/PAVA board around the same time. In a good demonstration on how to do it his balloon went on a 34 hour jaunt around the UK !