Category Archives: Orienteering

ROC – Radio Online Control

My orienteering club LOK (Linköpings orienteringsklubb) organized two events called Vårspringet during last weekend and I did among other things help with the online controls. In this blog post I describe the ROC, an online control solution based on a Raspberry Pi that we used for the first time.

Old online control solutions

For many years we have used two different kinds of online control solutions. The first one being concentrator boxes (“samlingsboxar”) with four serial port inputs where Sportident master units plug in. Our concentrator boxes have outputs that can drive at least 2 km of DL-1000 two-wire cable which brings the signals to the arena where they are received by special receiver boxes converting the signals back to proper RS232 serial port signals. This solution is obviously only applicable for online controls relatively close to the arena.

The other online control variant we have used are based on old Sony Ericsson mobile phones like M600i or P1i running custom programs (or apps if you will, but programs were not called apps when these were written by club members many years ago). In this solution, the SI master unit is connected to a serial-to-Bluetooth converter and the mobile phone receives the punch information via Bluetooth and sends it over GPRS to a server on the internet. The event administration program OLA polls the server and retrieves the punch information.

Trying something new – ROC

This year we planned on using a couple of the concentrator boxes, but also to retire the mobile phone solution and try out the Raspberry Pi based ROC “Radio Online Control” developed by Oskar and Erik Berg. This is a neat and pragmatic solution that makes use of several pieces of standard hardware and some not-so-standard software to create an online control that communicates via the 3G or 4G mobile phone network. Below is a photo of my setup where I put the hardware inside a metal cookie box dressed with some OSB board to keep things in place.

The ROC hardware built into a metal cookie box.
The ROC hardware built into a metal cookie box.

The hardware consists of a Raspberry Pi, a USB power bank, a USB-to-serial-port converter, an LED with series resistor, a piezoelectric buzzer, a 3G modem with SIM card, a Sportident master station and a number of USB cables. The ROC blog has recommendations on what and where to buy and how to connect things. In my case I had everything except the USB power bank and  the 3G modem with SIM card. I borrowed the USB power bank from a club mate and bought a new 3G modem as described below.

The software is very kindly provided for free as an SD card image one writes to an SD card and inserts into the Raspberry Pi.

Getting it up and running

At first, one connects the ROC to an Ehternet network so that it can be registered on the website. Configuration is done through the same ROC website and I would recommend a fairly detailed read of the ROC manual (only available in Swedish, use Google translate if you need) to figure out what should to be filled out and how. I failed to read the manual and ran into some trouble because of this later; see below.

A number of different 3G modems are supported as shown on the list on the right hand side of the ROC blog. I bought a Huawei E3351 modem in a package with a SIM card good for one month of data traffic through the operator “3” for 50 SEK at Kjell&Co. A pretty good deal I think.

At first I had trouble using the 3G modem and SIM card. The ROC did seem to connect to the server, but no punches got through and the connection seemed intermittent or flaky. I had the ROC connected to a monitor via an HDMI cable and got printouts every second that did not look right.

The ROC manual suggested that the problem might be that the Raspberry Pi could not supply enough current to the modem via its USB port, so I built a custom Y-shaped USB-cable that took current from the power bank while connecting the signals to the RPi. This did not help and I doubt it was necessary.

SIM card issues

I then tried the modem in a laptop and found an SMS on the SIM card that said that the month of data traffic on the SIM card was used up. Weird, since I bought it less than a day ago and the SIM card should be good for a month. I called the support at 3 and after 10 minutes of waiting for my turn, I talked to a support person who informed me that the SIM card had been used starting in October. Maybe someone at Kjell&Co had pulled the card out of its package and used it several months before it was sold to me? Or perhaps not since I think the PIN code was hidden under a scratch-off layer, so maybe it was 3 that had screwed up somehow? Anyway, the support guy seemed to believe my story and gave me a month of data traffic. After this, I still had some more issues and I suspected that my USB-to-serial converter with a Prolific chip was not supported.

The main problem however turned out to be that I had not read the manual carefully and therefore had failed to set up the APN (should be in my case) and PIN codes in the configuration form. Maybe I also had not configured the correct baud rate of the SI unit.

After some more trials and tribulations, I finally got the ROC to connect to the server via 3G, light up the LED, play a jingle on the buzzer and receive punches from the SI master station! Success!

I proceeded to install the hardware into the cookie box, but while doing so I seem to have zapped the IO pin on the RPi needed for the buzzer, so after this, only the LED indicates that it has managed to connect to the server and received the first punch. Fortunately this is good enough.

The web interface of the server shows time-stamped connections and punches from the ROC. This is extremely helpful when troubleshooting or when verifying that the ROC is up and running. One thing I have learned from working with online controls over many years is that diagnostics and verification tools are enormously important (often sorely missing, though) when debugging the problems one encounter. There always seems to be something that does not work right from the start.

Bluetooth adapters

As an extra convenience, I decided to use two Bluetooth-to-serial adapters (previously used for the phone-based online controls) to eliminate the cable between the Sportident station and the ROC. After some digging, I found the CD with configuration software and was able to pair the two units such that they automatically established a serial link of the proper speed (4800 baud in this case) when powered up in range of each other. This link seemed to work reliably for the remainder of the “project”. The adapter on the control side was powered by an old headlamp battery via a cable with built-in voltage regulator I built many years ago for the phone-based online controls. To power the adapter on the ROC side, I soldered together another cable that took 5 V from the USB power bank and connected it to pin 9 of the 9-pin DSUB connector while routing the RS232-signals to the RS232-to-USB adapter. The bluetooth adapters and associated hardware is not shown in the photo at the beginning of the post since they had not been added when the photo was taken.

A couple of days before the first event, the guy responsible for the event administration software OLA set up OLA to receive punches from the ROC while I hooked up the ROC and punched a few times. This did at first not work, but it was quickly discovered that some setting in OLA was incorrect and after fixing that, everything seemed to work fine.

All of the above took maybe two weeks or so of calendar time, so it was good that I started working on the ROC a couple of weeks before the events.

Success, failure and success during the events

During the Saturday event, the ROC worked brilliantly and without any hitches.

During the Sunday event however we experienced some issues that are hard to understand. When I first started the ROC on Sunday morning, it quickly connected to the 3G network and received punches. Perfect, just like  the day before.

But then we decided to set up a new event ID in the ROC configuration interface instead of continuing on the Saturday event ID. (This was most certainly not necessary.) After doing so and restarting the ROC, it did not react to punches, even though the connection to the 3G network was fine. More restarts did not help and neither did bypassing the Bluetooth adapters.

We then went back to the previous event ID in the configuration interface and after a few restarts the ROC started relaying punches again. Phew. Now we were in a hurry to get the ROC out in the woods to the control where it should do its task. Just like the previous day, we let it stay powered on to make things easy for the people installing it in the woods. When they were done, it did unfortunately refuse to relay punches once again, even though it was solidly connected to 3G.

As a final try to get it working, we sent out another guy to replace the SI station in case it had a broken cable or something. This did not help and the guy had to stay in the woods and report in passing competitors manually via SMS. After maybe 15 minutes something odd happened however. Punches started to stream in from the ROC! This continued to work for the rest of the event.

I still have no idea why the ROC worked intermittently during the Sunday event. It looked so good on Saturday and during the limited tests in the week before the events.


I think the ROC is a pretty neat online control solution, not the least because it is so inexpensive. In my case I spent only 50 SEK since I had the rest of the required hardware already. Pretty hard to beat. The time I had to invest was perhaps not quite as short as I would have liked, but this was partly due to my failure to read documentation and partly due to problems with the SIM card caused by the 3G operator or some other external party. Next time I am sure it will be much quicker.

There are some details that could perhaps be better documented and easier to troubleshoot, but for the cost of free it is hard to complain about the software. The instabilities we experienced during Sunday is a bit troubling and I would like to understand what the problem was.

We will most likely use at least one ROC on our events next year.


Here is a random list of things that might not be too clear from reading the manual:

  • If you want to log into the Raspberry Pi via SSH while it runs the ROC software, you can use the user name “pi” and the password you set in the web configuration interface.
  • It is unclear what serial port adapters are supported, but I would guess that most are supported since I could find no complaints or questions regarding this on the ROC blog.
  • Directly connecting Sportident USB masters to the RPi is also supported, although I have not tried this myself.
  • There are other networking options than using 3G in the case where the ROC is in WiFi- or Ethernet range of the finish. See the manual for details.

Sportident Station Reports Unrealistic Voltage

Today I discovered that one of the SI BSF8 stations (serial number 111515) on which I updated the firmware to 6.23 a few weeks ago was behaving strangely and that the voltage reported by SI Config was 1.64 V. With such a low voltage, the processor can hardly run and the beeper will probably not beep, at least not as loudly as it did.

This all sounds like a known bug that sometimes occurs after updating to 6.23. The Sportident release notes for firmware 6.23 says:

Very low battery voltage indicated
After booting to firmware 623, it can happen in rare cases that the device indicates a very low battery voltage. Config+ will show “(invalid)” for the battery voltage. This is a measurement error of the station. As a workaround, you should use the “Factory reset” command in Config+. This will reset the device and should fix the voltage value.

I opened the unit up and found that the sleeve of the battery was cracked, but that there were no visible signs of corrosion or other problems, unlike in a previous station. The idle battery voltage was 3.46 V.

Sportident station 111515 with a cracked battery sleeve.
Sportident station 111515 with a cracked battery sleeve.

I followed the recommendation in the release notes and used SI Config+ to do a factory reset of the station and after that the reported battery voltage was a much more realistic 3.17 V. A few minutes or so later the voltage was up to 3.25 V (a case of “voltage delay” in lithium thionyl chloride batteries).

I hope the station stays in the sane state and that the Sportident developers soon figures out and solves this bug.

Sportident Station with Pulverized Power Pins

While I was updating the firmware of many BSF8 Sportident stations to 6.23, I had a weird failure on a unit with serial number 112297. It may or mat not be related to the voltage measurement bug described on the last page of the release notes of the 6.23 firmware, If I recall correctly, the sequence of events was this:

  • The unit showed a very low voltage reading (2 V or so) and upgrading to 6.23 failed.
  • I opened it up to change the battery and measured the battery voltage with a DMM. It was indeed 2 V or thereabout.
  • Then the station died completely (I am unsure exactly when in the sequence of events this happened, maybe later).
  • I might then have desoldered the old battery and connected the station to an external power supply (3.5 V, limited to about 100 mA) to test it before I connected a new battery. I think I at first got it to work, but then it stopped working again.
  • I looked around the PCB under a microscope and noticed something weird at pin 60 of the microcontroller. Closer inspection showed that the pin was more or less pulverized. The processor datasheet said that it was one of the power supply pins (DVCC2).
  • I tried to repair it, but it turned out that no metal of the pin was sticking out of the package anymore, so there was nothing to solder to.
  • I then noticed that pin 100, AVCC, was also broken and that while pin 1 (DVCC1) was still in one piece, it also seemed to have been damaged since it was thinner than the other pins.

My guess is that a huge amount of current has for some reason flown through the power pins such that they have melted (!). I am pretty sure I did not hook up the external power supply with the wrong polarity and anyway it was current limited to 100 mA or so, so I do not think I caused this by reverse power polarity. Could it be that the processor entered into some kind of state that effectively shorted its supplies and thus consumed a large current?

I guess the reason for the bug behavior in the release notes (a voltage reading of about 2 V) might be caused by an unexpected large current consumption, so it is somewhat consistent with power pins getting destroyed. But it seems a bit unlikely that the relatively wimpy lithium thionyl chloride battery could deliver enough current for this to happen. And I am almost certain that the damage to the pins occurred before I connected an external supply. Quite mysterious.

Update on 2015-07-26

After a discussion through a few emails back and forth with Simon Harston, we have come up with a new hypothesis that could explain the state of the station while not requiring an unrealistically large current that could melt IC pins:

  • For some reason (maybe a manufacturing defect), the battery released corrosive gas/fumes.
  • The corrosive environment  inside the station may have been exacerbated by moisture leaking in.
  • Corrosive and conductive films formed at a number of places inside the station, including around the MCU pins.
  • Leakage current flowed through the film, particularly from the MCU pins with the most positive potential (the VCC pins) to the neighboring GND pins.
  • This current effectively made the VCC pins behave as sacrificial anodes in an impressed current system for cathodic protection and thus made them deteriorate, while the GND pins were unaffected.

If this hypothesis is correct, it explains why just the VCC pins were destroyed. Furthermore, it does not require a current that is probably much higher than the battery could ever deliver. The bluish debris that can be seen in some of the photos (e.g. on the bottom side of the board and near the resistor close to pin 1 of the MCU) might have gotten its blue color from copper ions from the corroding pins, provided the ions could somehow migrate from the pins to the other locations. The fact that the screws are clearly corroded supports the hypothesis that there was a corrosive environment inside the station at some point.

(End of update.)

Below are some pictures of the unit. Unfortunately, I do not have a really good way of taking pictures through a microscope, so most pictures are taken through regular lenses and the one taken through the microscope is blurrier than one could hope for.

The broken SI station.
Top side of the PCB of the broken SI station.
Bottom side of the PCB of the SI station.
Bottom side of the PCB of the SI station.
Bottom plastic cover with some mysterious blue material along the lower side.
Bottom plastic cover with some mysterious blue material along the lower side.
The processor with arrows pointing to the damaged pins.
The processor with arrows pointing to the damaged pins.
Closeup of pin 60 (after I desoldered the lower remains of the pin).
Closeup of pin 60 (after I desoldered the lower remains of the pin).
Pin 100 (AVCC) is broken.
Pin 100 (AVCC) is broken.
Microscope photo of pins 100 (left) and 1 (right). Pin 1 is narrower than the other pins.
Microscope photo of pins 100 (left) and 1 (right). Pin 1 is narrower than the other pins.
This battery with a cracked sleeve may have been in the faulty unit. I am not sure since I mixed up a number of discarded batteries.
This battery with a cracked sleeve may have been in the faulty unit. I am not sure since I mixed up six discarded batteries, two of which had cracked sleeves.