6 Things To Do With An Old Scrypt Miner

A while back I got in to Nyancoin and after an initial attempt to mine with a GPU bought a used Zeus Blizzard Scrypt miner. I ran it as a miner for a while and rapidly realised that while it was significantly better then the GPU and less likely to overheat my laptop it was never going to earn any sort of profit. After mining a few hundred coins I gave up and it just sat in a pile of electronic junk.

After getting interested in cryptocurrency again (getting hold of a bitcoin debit card and actually using it in the real world!) I thought it would be fun to get the old miner out and see what I could do with it. So here are 6 things to do with an old scrypt miner.

1. Nothing

To be honest this is probably the sensible thing to do with an old low hash rate energy hungry scrypt miner. The individual gold rush in scrypt mining finished a long time ago and now we have much more advanced miners such as the A4 which can do 280MH/s  compared to my lowly Zeusminer Blizzard at 1.3MH/s. You are never going to return a profit when investing in a a low powered miner these days and will always lose out financially.

2. Join a Professional Scrypt Mining Pool

Good examples of these are Prohashing and CleverMining, despite saying you are never going to recapture your expenses with a low powered miner you could still try. These pools through special algorithims compare a large number of alt-coins and mine the most profitable. At the time of writing I was able to earn about $0.04 a day on prohashing which means it would take 25 days to earn $1.

3. Lottery Mining

Mining cryptocurrency is all about finding a block, using a pool means that you all get involved and when one person finds the block you share it out (usually in proportion to what you have contributed). If however you set out on your own then your miner will keep looking for a block – if someone else finds a block then you get nothing and you start again however if you do find a block then you get to keep it all! Unfortunately the chances of finding a block on your own especially with a low powered miner are very low (and you may never find a block) – hence the term ‘lottery mining’. A good place to go for lottery mining is NiceHash or you can set it up directly at home if you run the mining software, and a local wallet. At the time of writing (14/12/16) finding a Litecoin block will get you 25LTC which is ~$90.

4. Support an alt-coin

There are a number of ways you can support a coin (and accept that you are going to be at a loss). Firstly scrypt based cryptocurrencies rely on miners as each block allows the processing of transactions. The more miners that are being run the better for the network supporting the coin. Lots of the smaller alt-coins don’t have big networks and can struggle to remain consistent. Running a miner either solo or with a pool adds your support – I have run my miner to help with Nyancoin by running it on xPool for a while.

If you want to increase the price of your chosen coin instead you could run your miner on Prohashing and mine the most profitable coins but setup your payout to be in your chosen coin. This will result in Prohashing buying up this coin to pay you back for the coin that you’ve mined and so will result in a steady stream of transactions in the exchanges.

5. Turn your miner to do good – e.g. Science

There are a few scrypt-based coins out there which have good intentions and by mining them you could could contribute to moving the human race forward. An example is mining Einsteinium who report that they use the cryptocoin to support scientific research, on their website it appears that have supported a number of students and researchers with their projects. Please however remember that whenever you get involved with a new coin make sure you do your research as you rely on a degree of trust between you and the leaders of the coin.

6. A glorified heater

Cryptocurrencies put out a lot of heat and so could be use to heat up your house, there are tales of people using the miners especially in a cold winter to remain warm and make a few coins…

Improving the Performance of UKHASnet


For a long period of time I’ve suspected that the UKHASnet network is underperforming, both on a local scale but also when we’ve tried long range tests such as high altitude balloons. The RF side of the network is suprisingly complex, far more then just bitrate and frequency and was originally setup based upon some previous trials and a little bit of ‘this works the best’ approach. Other systems that use the RFM69 radio module have used different settings but its a challenge to compare them as performance is influenced by a so many environmental factors.


I therefore set out to design and run an experiment to see if we could optimise our RFM69 settings and ideally make it back compatible with the current network (especially as some nodes cannot be reprogrammed with out significant effort).


To easily test the performance of a UKHASnet network it was necessary to make it as simple as possible, I turned off all my local nodes and then selected 2 nodes which we would use for the experiments.

Node 1 – AB (Ebulobo PCB, ESP8266 + RFM69HW)

Node 2 – AC0 (Ebeko PCB, STM32F0 + RFM69HW)

While different architecture they use similar code and they use the same RFM69Config.h which meant that they could be interchangeable.

The actual experiment involved setting up the 2 nodes with the same RFM69Config.h file containing the settings and measuring the number of packets they received. They were placed in seperate rooms on the same floor and had 1/2 wave whips attached, the nodes weren’t moved during the experiments and were reflashed with the new settings each time. Initially I just counted the number of loops of ‘b’-‘z’ they went through but then switched to counting the number of of packets transmitted and received allowing me to calculate how efficient the system was functioning. I’ve included both sets of experiments as the more data the better.


Experiment 1

SettingsVersionAB LoopsAB RxPer LoopAC0 LoopsAC0 RxPer LoopTotal Packet (approx)Total Rx%Rx
5Khz FDev, 2K baud, 10Khz BW1613121.8711716.765024838.1%
Standard + AFC Off3634757.8834843.570069599.3%
Standard + AFC On + Clear on each packet Off46599.87131.96507211.1%

Experiment 2

SettingsVersionAB TxAB RxPer PacketAC0 TxAC0 RxPer PacketTotal TxTotal Rx% Rx
Standard + AFC Off33883800.983883850.9977676598.6




Looking at the current standard settings it seems that only about 55-59% of the packets get through – this seems to confirm real life experience. The nodes themselves are only 1 room apart so you would expect a far better success rate. Switching off the AFC makes an enormous difference to the packets received – up to 99% of packets transmitted were received. I suspect that the AFC is easily thrown off by local interference and actually the wide shift means that actually you don’t need the AFC.

I did try using an alternative setting as suggested by the datasheet and found that it was even worse (though it did have the AFC still turned on).

What is nice is that turning the AFC off can nearly double the efficiency of a local network yet remains backward compatible with the current network settings. It is probably worth testing this simple change on other local networks to see if the results are replicable. If there is an improvement it would be worth trialling the high altitude balloon flights and long range ground testing again.

New Settings (RFMConfig.h):

#ifndef RFM69Config_h
#define RFM69Config_h

#include "RFM69.h"


/*PROGMEM */ static const uint8_t CONFIG[][2] =
 { RFM69_REG_03_BITRATE_MSB, 0x3E}, // 2000 bps
 { RFM69_REG_04_BITRATE_LSB, 0x80},
 { RFM69_REG_05_FDEV_MSB, 0x00}, // 12000 hz (24000 hz shift)
 { RFM69_REG_06_FDEV_LSB, 0xC5},
 //{ RFM69_REG_06_FDEV_LSB, 0x52},
 { RFM69_REG_07_FRF_MSB, 0xD9 }, // 869.5 MHz
 { RFM69_REG_08_FRF_MID, 0x60 }, // calculated: 0x80? 0x5F
 { RFM69_REG_09_FRF_LSB, 0x12 }, //0xBD
 // PA Settings
 // +20dBm formula: Pout=-11+OutputPower[dBmW] (with PA1 and PA2)** and high power PA settings (section 3.3.7 in datasheet)
 // Without extra flags: Pout=-14+OutputPower[dBmW]
 { RFM69_REG_12_PA_RAMP, RF_PARAMP_500 }, // 500us PA ramp-up (1 bit)
 { RFM69_REG_13_OCP, RF_OCP_ON | RF_OCP_TRIM_95 },
 { RFM69_REG_18_LNA, RF_LNA_ZIN_50 }, // 50 ohm for matched antenna, 200 otherwise
 { RFM69_REG_19_RX_BW, RF_RXBW_DCCFREQ_010 | RF_RXBW_MANT_16 | RF_RXBW_EXP_2}, // Rx Bandwidth: 128KHz
 //{ RFM69_REG_19_RX_BW, RF_RXBW_DCCFREQ_010 | RF_RXBW_MANT_24 | RF_RXBW_EXP_5}, // Rx Bandwidth: 10kHz
 //{ RFM69_REG_19_RX_BW, RF_RXBW_DCCFREQ_010 | RF_RXBW_MANT_16 | RF_RXBW_EXP_4}, // Rx Bandwidth: 31.1KHz
 //{ RFM69_REG_1E_AFC_FEI, RF_AFCFEI_AFCAUTO_ON | RF_AFCFEI_AFCAUTOCLEAR_ON }, // Automatic AFC on, clear after each packet
 { RFM69_REG_1E_AFC_FEI, RF_AFCFEI_AFCAUTO_OFF | RF_AFCFEI_AFCAUTOCLEAR_OFF }, // Automatic AFC off, clear off after each packet
 { RFM69_REG_26_DIO_MAPPING2, RF_DIOMAPPING2_CLKOUT_OFF }, // Switch off Clkout
 /* receiver timeout:
 * max packet length is 72 octets
 * (3 preamble, 2 sync, 1 length, 64 message, 2 CRC)
 * timeout interrupt is generated (value*16*Tbit) after RSSI interrupt if
 * PayloadReady interrupt doesn't occur so a value of 36 would correspond
 * to the packet duration but not allow for any other delays hence set to
 * 40
 { RFM69_REG_2B_RX_TIMEOUT2, 40 },
 // { RFM69_REG_2D_PREAMBLE_LSB, RF_PREAMBLESIZE_LSB_VALUE } // default 3 preamble bytes 0xAAAAAA
 { RFM69_REG_2F_SYNCVALUE1, 0x2D },
 { RFM69_REG_30_SYNCVALUE2, 0xAA },
 { RFM69_REG_38_PAYLOAD_LENGTH, RFM69_FIFO_SIZE }, // Full FIFO size for rx packet
 { RFM69_REG_6F_TEST_DAGC, RF_DAGC_IMPROVED_LOWBETA0 }, // run DAGC continuously in RX mode, recommended default for AfcLowBetaOn=0
 // { RFM69_REG_71_TEST_AFC, 0x0E }, //14* 488hz = ~7KHz
 {255, 0}


The Plot Thickens (Latest ESP8266 Issues)

Last week I finally got all the parts to put together the next batch of Ebulobo boards (0.4) but found that the new ESP8266 modules from China were slightly different and were very unstable in being flashed and running code. They were also drawing a lot of current both getting very hot and making the regulator hot. He is a bit of documentation of the various experiments I did to try and track down the problem.


  • Removed the antenna to see if there was a short and added a 1/4 wave antenna (I appreciate its not matched) – no change
  • Soldered up my last v0.2 Ebulobo board – same problem
  • Put together another v0.4 board with another ESP8266 from the batch – same problem
  • Measured current draw – ~300mA when getting hot however this was not consistent
  • While handling one board (powered) I found that applying pressure to the main ESP chip allowed the ESP8266 to function correctly and draw about 70mA – possibly a manufacturing problem with poor solder contacts? 
  • Examined the solder points under microscope (well, a reversed telescope eye piece) – appeared to be intact
  • Resoldered the passives on the ESP8266 – no change
  • Tried with a variety of settings (flash speed/size) – no change
  • @MinecraftM0b kindly soldered up some similar looking ESP8266-03 modules (with the non-branded chip antennas) and found that they worked fine.

Chip Details (Just for documentation)


  • RainSun Chip Antenna
  • Main IC: ESP8266EX 522015 P46N9
  • Flash IC: AH1521 25041B 26G540
  • Crystal 26.000MHz


  • Unbranded Chip Antenna
  • Main IC: ESP8266EX 482015 P48A15
  • Flash IC: BergMicro BG25Q80AISCC 1550
  • Crystal – 26.000MHz

Next Step

  • Ordered 2* ESP8266 off a UK seller on ebay, these boards have the original rainsun ceramic antenna. Soldered up another Ebulobo 0.4 board and was able to reflash immediately and the node started up with no issues. – doesn’t appear to be a PCB issue


I suspect that I’ve received a bad batch of ESP8266-03 modules, either a manufacturing problem or a small change which isn’t documented. I’ll probably finish up making this latest batch with ebay supplied ESP8266s and continue looking into why this batch didn’t work as it should. Hopefully its just this batch but if anyone else has similar problems I’d be interested to hear the details.

Possible ESP8266 Fake or New Pinout?

After the first run of Ebulobo boards I’ve been assembling the parts to make some more nodes. I’ve updated the PCBs making sure that there is a ground plane and put some labels on the pinout. Like last time I ordered 10 RFM69HW radio modules and 10 ESP8266 modules from China via Alibaba. As always you have to wait 6 weeks for the slow boat delivery and finally they arrived last week.


I assembled a board, plugged it into USB power and attached my usb/serial board, I was able to flash the chip with the Arduino/UKHASnet firmware but found that it would only boot occasionally. The wifi was intermittent, only occasionally I was able to connect to the device. Touching the board the ESP8266 was hot to touch (almost burning hot). To test that it wasn’t a change in my PCB that was causing this issue I used my last v0.2 PCB (original Ebulobo) and had the same issue.


Closer inspection of the ESP8266 the board looks very similar though it does have a different chip antenna, the original ESP8266 03 modules have a off white antenna with RAINSUN printed while these have a white non-branded antenna. Googling I couldn’t find any images of an ESP8266 03 with a non-branded antenna (though I wouldn’t be suprised if there are only a few original pictures and everyone just copies them – like this one).

ESP8266-03 lifted from Banggood
ESP8266-03 lifted from Banggood

Its difficult to know if the modules are fake (there are a few rumours online that it might happen) or that they’ve changed the pinout resulting in my PCB not working properly. Would be interested if anyone has experience with this problem.

I’ve ordered some more ESP8266 03 modules from another seller so will see if these have the same issue.

Solar/Capacitor UKHASnet Node


There are a number of ways of powering UKHASnet nodes, indoor nodes suit having a permanent supply such as power from a usb port or a wall wart/socket but for outdoor nodes you usually need a power source such as a battery or solar powered.

Solar power is both an awesome power source as its free and often just there but is also quite a challenge to use. Firstly you need the sun to be shining which means that at night we’ve got a problem and in the UK an overcast/cloudy day is not unusual. Next you need solar panels to ‘harvest’ the sunlight – not all solar panels are the same and I’ve learnt that its worth getting the biggest panel you can, there are some particularly good panels from Voltaic Systems but they are are obviously expensive so often people use cheaper Chinese panels usually from Ebay.

There are a number of ways you can use your solar panel, you can run your node directly from the panels however if there is drop in sunlight (e.g. a cloud) the node won’t get enough power, there will also be times where the sunlight is stronger and so the panel will generate more power which will be wasted. Therefore you can use a ‘reservoir’ such as a battery or a capacitor to store excess when there is lots of sunlight and release when there is a drop in sunlight. Charging batteries can be suprising complicated (and is a whole other blog post) while charging capacitors can be easy.

Charging Capacitors

The simplest design is to have a solar panel, a diode and a capacitor. The solar panel charges the capacitor which acts as a reservoir between the panel and the node. When there is sunlight current flows from the panel to the capacitor and node but when it is dark the current could flow back from the capacitor damaging the panel, a diode is usually placed in between to stop this happening. solarcap1A big capacitor like the one shown will take some time to charge up and so the node won’t boot immediately but it also means that the node will run for a little while after the sunlight goes. You could also use a supercapacitor in this situation see Working with Supercapacitors for more information.

One of the big problems is that even with a 6800uF capacitor this isn’t very much and the node will quickly run out if there is no sunlight replenishing the capacitor. You’ll need to work hard with various power saving settings to ensure that your node uses as little current as possible (i.e. having the RFM69 radio sleep in between transmissions). Another issue is that when the nodes’ microcontroller starts up it often uses a little bit more current then normal which can then drain the capacitor to the point where the voltage drops and the microcontroller can’t start, this ends up becoming a loop which it can only get out of if there is a lot more sunlight to get the whole thing over the hump and running. This problem means that you often need a good bit of sunlight to get things started and if its an overcast day you’ll never boot up.

Getting over the ‘hump’

I’ve spent time thinking (and experimenting) with ways of allowing the node to boot up easily (as once it has booted it can go into power saving/sleep modes and maintain itself). One way is to use a bigger solar panel so that when there is sunlight you get lots of current and so even if the node needs more then normal to boot it can still start. Another is to try to delay the node from starting (and drawing current) until the capacitor has charged enough to ‘survive’ the booting process. One of the latest versions of my UKHASnet boards has a ltc3525 step up DC/DC converter with output disconnect, this is a little SMD chip which can turn as low as 0.85V into 3.3V to power a node. It has a shutdown pin which when is held high will turn on the chip but when low disconnects the chip, the design is particularly nice as the high on the shutdown pin is a voltage >1V. We can therefore allow the main capacitor to charge up with the node disconnected and only reconnect it when the capacitor is sufficiently charged to cope with the demands of the node. This therefore avoids getting stuck in the loop of trying to boot and drawing too much current which results in the voltage dropping restarting the loop.

My initial design was to attach the shutdown pin to the main VCC line with a resistor divider.solarcap2 This would mean that as the main capacitor charged up the shutdown pin would have a proportionally lower voltage (e.g. main capacitor = 1.5V, shutdown line = 0.5V), the main capacitor would be at a higher voltage when the shutdown line went passed 1V and turned on the chip as well as the UKHASnet node. Even this didn’t work particularly well, the node would get stuck booting occasionally and it still relied on a lot of sunlight to get started.

Slowing down the SHDN

Ideally we want the capacitor to charge up and there to be a delay before the shutdown pin is >1V and boots the system. We could use another capacitor which would also charge up and as this takes time there would be a delay before the shutdown line passes its threshold. By this time the main capacitor should be well charged up and will cope with the start up of the system. To increase the delay we want the time constant to be longer so adding a resistor in series with the capacitor will do this. I’ve also added another capacitor to the main reservoir as I found that one wasn’t enough to cope with packet transmissions.solarcap3


The latest circuit is currently being used to power AD3, AD3 is able to start up off a lamp on my desk and was running pretty well balanced on the north facing window by my desk. It will boot easily in the morning when the sun comes up (earlier then my supercap node AI1) and will run until the early evening. During the day there is certainly more power then needed for a simple sensor node. I was able to add the ability to start repeating packets if the capacitor’s voltage was above 3.1V. Indoors it manages to repeat about 40% of the time and when outside around midday it repeats 100% of the time. The other option would be to instead charge a battery when there is excess power which could then be used to extend the node on time overnight.


  • Erebus PCB (LPC812, RFM69HW, LTC3525)
  • Solar panel (2* 69x110mm)
  • 2* 6800uF 10V capacitors in parallel makes 1.36F
  • 2* Diodes
  • 1* 470uF capacitor
  • 1* 22K Resistor
  • 1* 47K Resistor
  • 1* 3K3 Resistor

img_0290 img_0291



UKHASnet Antennas 1


Antennas in regards to UKHASnet is an area that is under explored. I have used a number of different types both homemade and commercial and am yet to find something that works well. Many nodes have a single wire antenna cut to a 1/4 wavelength (82mm) – often just put in place for testing and then never upgraded to something more. Its also suprisingly hard to test antennas as they are influenced by so many environmental factors and the equipment to test it scientifically is expensive. On the flip side the key is more how well they work so  I decided to start a simple experiment using my home gateway.


Antenna 1

Short section of RG58 coax with an SMA connector on one end. Stripped the outer insulation and shield to expose 82mm of the core and then attached the antenna with tape on my desk so that it wasn’t close to any other object. No ground plane was attached and so this antenna acted like a single wire antenna.

Antenna 2

Same setup but added 2x 82mm long radials soldered to the metal shield of the coax.quarterwavevsradials

The graph shows received packets by AB gateway, each colour is a different node and the y axis is RSSI in dB, the red line is the noise floor. As you can see the ‘green’ node, ‘orange’ node and ‘blue’ node all have a better RSSI then before, the ‘yellow’ node is right next to the gateway so probably is at its best already. By adding 2 radials the antenna is performing better.

Antenna 3

Same setup but now 4 radials (just to note the laptop is off).img_0285 Adding the extra two radials didn’t really make much difference to the performance. Out of interest I then detached the antenna and left the gateway running without an antenna. You can see a significant deterioration in performance for all the nodes as well as a smoothing of the noise floor as its less sensitive to nodes and local noise.quarter4vsno


From these simple experiments it seems sensible to put a ground plane onto a 1/4 wave antenna and you can probably get away with just 2 radials. Next step is developing directional antennas especially as I’m planning some long range links.


Ebulobo* 0.2 (ESP8266/RFM69HW Gateway) – Part 2

*current PCBs are being named after volcanoes beginning with ‘E’ – Wikipedia

As discussed in a previous post I’ve been working on a simple UKHASnet gateway and had managed to put together a prototype of a ESP8266 based gateway where the ESP communicates with the RFM69 via SPI. The original prototype was a ESP8266 deadbug soldered onto the back a RFM69 breakout board and once I had got the software working the next step was to transfer it all to a PCB to make it all more stable and solid.

The key part was to make it into a cheap, simple to put together board that could be the basis of future UKHASnet networks and I hope that a few will be available on hasnet.supplies.


  • ESP8266-03
  • RFM69HW
  • MCP1700 3.3v Voltage Regulator
  • 2* 1uF capacitors
  • 1* 10k ohm resistor
  • 1* 1k ohm resistor
  • USB Male connector (as a power source)
  • 5 pin 2.54mm header for programming

Requirements and Design

The aim was to use ESP8266 and reflash the onboard processor with the Arduino development environment to allow easy porting of the current UKHASnet code. The ESP would act as the main microprocessor and control the RFM69 over SPI. Any packets received by the RFM69 would then be uploaded by the ESP via wifi to the main servers on the internet acting as a self contained gateway.

To make it easy to power I added a USB male header to the board which when plugged into a usb socket (such as on the backs of wifi routers) would provide 5v. This would then be regulated by the MCP1700 down to 3.3v which would then supply the ESP8266 and RFM69. This is also a 2 pin header which breaks out Vin and GND in case an alternative source is used. ebuloboImage

Programming the ESP8266 is via serial and so GND, Tx and Rx are broken out to another header, to reflash the ESP8266 its necessary to pull GPIO0 to ground on boot and so GPIO0 is also included in the header to make it easy to add a jumper to set this up.

The ESP8266 also requires GPIO15 and GPIO2 to have pullup/pulldown resistors and so through hole packages were used. The whole board is either through hole or easy circuit board soldering and can be assembled in about 5 minutes.


The PCB was ordered from dirtypcb under their protopack deal which gives you 10 boards for $14, to speed up development I did opt for the slightly more expensive delivery option (as the china airmail can take up to 6 weeks) and the boards arrived after about 10 days.

The key expensive parts were the ESP8266 and RFM69HW which I ordered via Aliexpress from Hong Kong in bulk. Other parts such as USB header, MCP1700 voltage regulator, SMA connector and capacitors were ordered from UK sources such as Proto-Pic or from Ebay.


There was a delay in construction of the nodes as had to wait for the slow post from Hong Kong for the ESP8266-03 and RFM69HWs but once they arrived I was able to commence building. Initially I was having problems reflashing the ESP modules and it turns out that the groundplane didn’t get laid down (perhaps a problem in the gerber file creation) and so it was necessary to add the SMA connector to ensure that all the ground traces were connected. It was then easy to flash the nodes with the latest firmware, I still haven’t managed to add the configuration of the node setting via the EPS8266 web page and so instead that node ID is hard coded but could always be reflashed.ebulobo1

Setting up an Ebulobo board

All the current Ebulobo boards come pre-assembled, it is necessary to add an antenna for the RFM69 via the SMA socket and should work out of the box.

  1. On plugging the board into a USB socket the ESP will start up an open wireless access point called ESP***** depending on the ESP serial number
  2. Connected to this network with either a laptop, tablet or phone.
  3. A login should be triggered on connecting, if not then browse to
  4. This will bring up a webpage which allows you to select your home network and setup the Ebulobo node to use that wifi network to upload packets.
  5. Once selected the node will reboot and connect to your home wifi, any packets received will be uploaded to the internet. In the future it’ll will always connect to that wifi network.
  6. If you wanted to change the network you could turn off the old wifi network temporarily and then start the node, when it can’t find its regular network it’ll then start again by opening up the open access wireless point.


It might be necessary to reflash the node if there is new firmware or you want to change some of the settings such as the node ID or add in a location string. The easiest way to reflash the ESP8266’s firmware is over serial and these pins are broken out to the JP2 header:

  1. Ground
  2. Rx
  3. Tx
  4. Ground
  5. GPIO0

The first link pins 5 and 4 together with a jumper and then attach a serial port (i.e. FTDI USB/Serial convertor) to pins 1, 2 and 3. As described http://jamescoxon.net/?p=159 you’ll need to download the Arduino IDE and then the ESP8266 set of libraries and board definitions which can all be done through the main program.


Overall I’m pleased with the outcome of developing these boards, slightly disappointed that the ground plane didn’t come out very well but it doesn’t appear to be effecting the performance of the board. Next step will be to build a few more nodes and see if other people find them easy to use. Hopefully will make it easier to expand UKHASnet.

Future Improvements

  • Update firmware so that its possible to configure the node ID and location when setting up for the first time.
  • Fix the PCB and add a footprint for a sensor or two.
  • Add the ability to host a webpage which would allow people to transmit custom messages via the UKHASnet network.


The Problem with Summer – two unexpected issues with a UKHASnet network

In the last week I’ve noticed two strange errors occurring in my Suffolk UKHASnet network. The network has been running for nearly 1 year now without very much intervention and comprises of an Arduino/ESP8266 gateway node AA, a solar Arduino node AH2 and a solar supercap LPC812 node AI1. Over the winter the network has been running at bare minimum often in zombie mode overnight but with the recent good weather and lengthening days the nodes have spent more time in repeater mode and have actually begun to malfunction.

AA – Afternoon Naps

I recently noted that the AA gateway seems to stop working in the afternoons, this has an impact as it means no data from the network is uploaded to the servers. It is placed in a well insulated attic where a Moteino uses serial to communicate with ESP8266 using AT commands to upload packets.  It appears that every afternoon for the last week it stops working between approximately 1400 and 1900. On closer inspection during this time the RFM69 temperature is reaching about 40C and then the gateway cuts out. AA_TempEvery time it restarts in the evening it initially sends a very high temperature (e.g. 61C) and then returns to functioning as a gateway uploading packets throughout the night until the next day.

Interestingly looking at the temperature graph on the 06 May the node doesn’t reach above 40C (ignoring the noise in the measurement) and therefore continues to gateway data throughout the afternoon. For the last week the weather has been particularly warm, particularly 07 May and 08 May, AH2 (which is outside) reported 32C which would suggest that the gateway is getting too hot due to the environment (hot day + insulated attic) and something isn’t working at that temperature only resuming once it cools off.

Thinking it through I can think of 3 main reasons why its failing:

  1. RFM69 failing at high temperatures – this is a strong possibility, just before the node fully resumes activities it appears to report a high temperature. The datasheet suggests that the operating temperature is -20C to +70C and maximum temperature is +115C. Due to the slight unreliablity of the RFM radios themselves I wouldn’t be suprised that something wasn’t working.
  2. RFM69 drifting – its certainly been seen on high altitude balloon flights that the RFM69s crystals drift and this would result in the receiver freq not matching the transmission frequencies of other nodes. If it was drift you would expect as it drifted off frequency the rate of received packets would decrease before stopping rather than suddenly stop and looking closely at the data this didn’t appear to happen.
  3. ESP8266 not coping or drifting – the ESP8266 seems to be more robust then the RFM69, its quoted operating temperature is wider (-40C to + 125C https://github.com/esp8266/esp8266-wiki/wiki) and I haven’t found any reports with a simple google search of any issues at this temperature.

AA_Temp2Interestingly while writing this entry the rain arrived and the weather was a lot cooler, AA managed to work through the afternoon and looking at the temperature graphs it definitely didn’t reach the high temperatures of the previous day. I suspect that it is an RFM69 issue rather than an ESP8266 and it might be a single component is struggling at the higher temperatures. It will be interesting to see if this happens again as we move into summer, as its quite a rare occurrence in the UK to reach 40C I don’t think there is any point adjusting the AA node, if it becomes a persistent issue the solution would be to move the node out of the insulated attic.

AI1 – Alternating Days

AI1 is a supercap node, it comprises of a solar panel, diode, a large super capacitor and then a EtnaNode (LPC812 and RFM69HW). The solar panels directly charge the super capacitor which then acts as a reservoir to the node (there are no batteries). While the node doesn’t survive the night it is able to power up when there is sunlight and then run into the evening as the cap discharges. During the winter it has woken up every morning and as the days have lengthened it has survived further and further into the night. In the last 2 weeks I’ve noticed that it isn’t booting every day and on closer inspection it actually only boots on alternate days.AI1_Volt

One of the problems I’ve encountered with UKHASnet nodes especially those which are solar powered is that if the voltage supplied to the node gradually increases the microcontrollers often get stuck in locked state where they can’t fully boot up (I assume not all the parts of the micro are able to boot and so it gets stuck). To overcome this issue we use the brownout function to reboot the microprocessor at a particular voltage therefore forcing it out of the locked state. This has been working great during the winter as the capacitors have enough time to discharge low enough to reset the micro however with the lengthening days there now isn’t enough time. The micro remains in the locked state and when the sun comes up just continues to power it until the next night when it discharges enough to reboot.AI1_Volt2

It turns out that if the node makes it through to around 0200 it won’t boot the next day however if it only works until approximately 0100 it will. Looking at the graph from Grafana on 5/5/16 and 7/5/16 the node boots and runs to 0200 and therefore doesn’t boot the next day however on 9/5/16 it only reaches 0100 and so the next morning it boots, the profile is a bit different as it was cloudy but the node manages to run until 0200 and then doesn’t work the following morning.

In an ideal situation we would build a node that can survive through the night and therefore there isn’t any need to boot up in the morning as its still running. It might also be possible to adjust the brown out settings further but unfortunately the node is encased in an enormous blob of glue to there is no way to reprogram the micro. Therefore the node is continue to boot alternate days unless the lengthening days get to the point that they can power the node throughout the night or that we wait until the days shorten again to the point that there is enough night to cause a reboot.

ESP8622/RFM69 Wifi Gateway

Following the UKHASnet hackweekend there has been an increase in the popularity and extent on the UKHASnet network. I’m currently in the process of setting up a new gateway and repeater node in NE London. The repeater node is going to be solar powered and mounted on a balcony and while its hoped that this node will be in range of other gateways I thought it would be sensible to also install a gateway node. I recently caught up that the versatile and cheap ESP8266 can be reflashed with the an arduino environment and that with the correct ESP8266 module it is possible to access the SPI bus.



  • ESP8266-3 Module
  • RFM69HW
  • RFM69 Breakout Board PCB
  • MCP1700 3.3v Voltage Regulator


ThIMG_0663e initial prototype was deadbug wired onto the back of a breakout PCB, the RFM69 was soldered into its footprint apart from the Digital I/O pins which kapton tape was placed under. The ESP8266 module was connected up and the now spare header pins were used for a serial connection to the ESP8266. When using the ESP8266 it is necessary to setup the GPIOs in a particular manner to ensure it boots correctly.


  • GPIO0 – this pin is monitored by the bootloader, when it is pulled to ground the module will boot into the programming mode, if left floating it’ll boot into the main program.
  • GPIO2 – this needs to be pulled high via a resistor (such as 1K)
  • GPIO15 – pull this to ground via a 10k resistor

To connect up the SPI it was necessary to wire up

  • GPIO12 – MISO
  • GPIO13 – MOSI
  • GPIO14 – Clock/SCK
  • GPIO15 – NSS

After a lot of head scratching it turns out that I had mislabeled the pins on my newly delivered RFM69 breakout board and after reorganising the wiring I was then able to get the ESP8266 communicating with the RFM69 radio module.IMG_0662

To program the ESP8266 its necessary to have a serial connection:

  • Rx
  • Tx
  • GND
  • GPIO0 (pull to ground to boot into programming mode)


  1. First install the Arduino ESP8266 add-on using the Board Manager (Sparkfun Guide) and then select ‘Generic ESP8266 Module’
  2. Download the esp8266_gateway code.
  3. Currently it requires hardcoded gateway settings (though I hope to move this to WifiManager eventually). Rename NodeConfig-template.h to NodeConfig.h and then update the settings.
  4. Boot the ESP8266 with GPIO0 pulled to ground and then upload the code to the module.
  5. On booting the ESP8266 starts an open Access Point which you can log into and enter which network you want it to join.
  6. It’ll then reboot and start acting as a UKHASnet gateway, debug is outputted to the serial port.

 Future Plans

  • Next step is to get a PCB made (probably via Dirty PCB)
  • Adapt WifiManager to allow the UKHASnet gateway settings (therefore avoiding any hardcoded settings).
  • Get the gateway onto hasnet.supplies as a simple kit.

UKHASnet Hack Weekend 2016 – Isle of Wight

After the success of the first UKHASnet Hack Weekend it was all agreed to rendezvous again but this time stay in a single place to work on UKHASnet projects. We were able to hire a house on the Isle of Wight where 10 people assembled on the friday after successfully negotiating the ferry and then actually finding the hidden house itself.

Photo by Russ Garrett https://flic.kr/p/EyrqxL
Photo by Russ Garrett

Work began immediately on various UKHASnet projects, this included firing up the my 3d printer to make cases for UKHASnet nodes and a moxon antenna, multiple nodes were built, coded and debugged and it was a great chance to push the network as we ended up having multiple gateways. The original idea was to recreate the flotilla however due to poor documentation of the Xadow GSM module which I had hoped to turn into a floating GSM gateway it took too long to actually get it all working and wasn’t going to be ready for the Sunday morning activity day. Instead we decided to try and do some range testing of the RFM69 modules.

Range Testing

Previously (excluding using balloons) the longest ranges achieved using UKHASnet was about 1.5km but it was generally felt that it should be possible to push this to line of sight. We therefore decided to split into three teams and see if we could push how far UKHASnet could work. Before we left we setup 2 nodes with serial consoles to allow us to a custom data i.e chat text (designated with ‘:’).

Photo by Russ Garrett https://flic.kr/p/F4MudU
Photo by Russ Garrett https://flic.kr/p/F4MudU

One team graciously volunteered to remain at the house and set up a repeater node on a fibreglass pole in the garden (RUSS1). The rest of us divided into two, one team going up to Tennyson Memorial on Tennyson Downs, there they setup AJ2 (a LPC812 with GPS which had originally been planned to put in the sea) as well as having PF01 as their chat console. The other team jumped in my car and we initially drove to Compton Bay car park. We were using AJ1 a 3d printed moxon antenna with an LPC812 on a MK2 board with an RFM69HW set to 100mW. AJ3 was our chat console based on an EMF Camp TIlda badge acting as an Arduino Due with a RFM69HW wired to its SPI. Coordination was via VHF radio and once we had established that both teams were in position we fired up the network, after a little bit of hacking of the chat console we were able to send packets from Compton Bay up to Tennyson Memorial and back again with a range of 5.4km.IMG_0656

We then decided to see if we could push the range further and headed down the coast setting up above Blackgang Chine on the cliff top. We could just see in the distance the Tennyson Downs and were able to get up a reliable link between the two which was a range of 18.57km. Packets sent from Blackgang were then repeated by the Tennyson node across to the house a further 3.34km giving a total of 21.91km.


It was great to be able to get out and actually test the nodes and push the ranges to beyond anything we’d tried before. 18.75km was beyond what we expected to achieve but it showed that the range is really based on line of sight and if you can get a well placed node you could cover a significant distance. All the nodes performed well, even with a simple 1/4 wave wire antenna it was possible to cover a good distance and it was relatively easy to put together the moxon antenna adding a bit of directionality and gain. It also was really good fun being able to chat across the mesh network and has inspired us to work on some new cool projects using the technology. Hopefully we’ll be able to get some more nodes installed in significant places and start to really expand the network.