Category Archives: Computing

APRS activity in Ireland

In a conversation  late last year (at the TAPR DCC)  I was asked what is the actual level of APRS activity in Ireland.  Thinking about the answer for a while, I realised that I really didn’t know, and that got me wondering how to go about visualising it.

I quickly came across  Leaflet.heat, a Leaflet plugin plugin for generating heatmaps, so I  bodged together some python to grab packets of moving stations from the APRS-IS backbone and put them into a format Leaflet.heat can read.  After gathering about 6000 data points, here is what it looks like:

So, there you go, it is fairly conclusive that Cork city has the most ‘on-air’ APRS activity. This is followed by Waterford area, Galway area and then the main motorways.

Ham Radio… Now What?

I was looking for something to watch/listen to while tidying up my inbox today after being away for three weeks or so.  We took in the ARRL/TAPR Digital communications conference while in Florida. As I enjoyed this years DCC so much,  i went looking for last years DCC banquet speech.  Ward Silver, N0AX, gave an excellent talk on the direction the hobby should take for it’s second century.  I particularly liked his comment about contesting and being “able to heard the world turn”. Thanks to Gary Pearce, KN4AQ for attending the DCC and working so hard to make the videos available (feed the pig!).

Waiting for Pi

Boy it has been busy of late, not what I expected 2013 to be.  I’m way behind on a lot of things I had planned to get done this year, but who isn’t.

Today I got one item off the todo list. Back in September at the DCC, John Hansen, W2FS presented the TNC-Pi, a radio modem for the Raspberry Pi. John was kind enough to entertain my questions, and I purchased one from him. This morning, I dug out the kit, fired up the soldering iron and put it together, quite therapeutic I must say.


Looking forward now to getting a Pi, and getting it all going, assuming I’ve not messed up in the construction.

Happy Christmas!

Staying secure

Taken from Schneier on Security:

  1. Hide in the network. Implement hidden services. Use Tor to anonymize yourself. Yes, the NSA targets Tor users, but it’s work for them. The less obvious you are, the safer you are.
  2. Encrypt your communications. Use TLS. Use IPsec. Again, while it’s true that the NSA targets encrypted connections — and it may have explicit exploits against these protocols — you’re much better protected than if you communicate in the clear.
  3. Assume that while your computer can be compromised, it would take work and risk on the part of the NSA — so it probably isn’t. If you have something really important, use an air gap. Since I started working with the Snowden documents, I bought a new computer that has never been connected to the Internet. If I want to transfer a file, I encrypt the file on the secure computer and walk it over to my Internet computer, using a USB stick. To decrypt something, I reverse the process. This might not be bulletproof, but it’s pretty good.
  4. Be suspicious of commercial encryption software, especially from large vendors. My guess is that most encryption products from large US companies have NSA-friendly back doors, and many foreign ones probably do as well. It’s prudent to assume that foreign products also have foreign-installed backdoors. Closed-source software is easier for the NSA to backdoor than open-source software. Systems relying on master secrets are vulnerable to the NSA, through either legal or more clandestine means.
  5. Try to use public-domain encryption that has to be compatible with other implementations. For example, it’s harder for the NSA to backdoor TLS than BitLocker, because any vendor’s TLS has to be compatible with every other vendor’s TLS, while BitLocker only has to be compatible with itself, giving the NSA a lot more freedom to make changes. And because BitLocker is proprietary, it’s far less likely those changes will be discovered. Prefer symmetric cryptography over public-key cryptography. Prefer conventional discrete-log-based systems over elliptic-curve systems; the latter have constants that the NSA influences when they can.

If you haven’t already read the full post, you should.

Mirabox Kernel update

So the background is that I have a lovely little unit called a Mirabox but I need to update the kernel on it.   I spent a good bit of time looking at various forums and eventually managed to piece together enough information to get a 3.9 kernel to boot for me.

First, I installed a cross compiler, then I built a kernel, with default options, like so.

PATH="/home/build/smile/armv7-marvell-linux-gnueabi/bin:$PATH" make ARCH=arm CROSS_COMPILE=arm-marvell-linux-gnueabi- mvebu_defconfig

PATH="/home/build/smile/armv7-marvell-linux-gnueabi/bin:$PATH" make ARCH=arm CROSS_COMPILE=arm-marvell-linux-gnueabi- zImage

PATH="/home/build/smile/armv7-marvell-linux-gnueabi/bin:$PATH" make ARCH=arm CROSS_COMPILE=arm-marvell-linux-gnueabi- armada-370-mirabox.dtb

cp arch/arm/boot/zImage zImage-with-dtb

cat arch/arm/boot/dts/armada-370-mirabox.dtb >> zImage-with-dtb

./scripts/ -A arm -O linux -T kernel -C none -a 0x00008000 -e 0x00008000 -n 'Linux-marvell' -d zImage-with-dtb uImage

This kernel booted, but could not find a root filesystem. After a spending a bit of time looking, I could not find a NAND driver, so I opted for a filesystem on MicroSD instead.

Next, I replaced the kernel configuration with the one in this post, and rebuilt it. While that was building, I followed the instructions in this post, to create the filesystem on a MicroSD card.

Finally, I dropped the uImage created above onto a tftp server, loaded it with

tftpboot 0x6400000
set bootargs 'console=ttyS0,115200 root=/dev/sdb2 rootwait'

and the result is a working system.

root@dreamplug-debian:~# cat /proc/version
Linux version 3.9.0 (root@ubuntu-smile-build) (gcc version 4.2.0 20070413 (prerelease) (CodeSourcery 2007q1-10. Marvell 2009q3-11 20090730)) #2 Fri May 3 15:27:05 IST 2013

A very satisfying way to finish up before a long weekend!

Wardriving and D-STAR Digital Data

I’m slowly working towards doing some experiments with mesh networking (OLSR) and Icom ID-1 D-star Radios in Digital Data mode.  I’ve been wondering what coverage I would (should) see from a vehicle, back to one of the locations where I have an ID-1 in a fixed location (thanks EI3JB/EI8JA).

I got back from a trip today, grabbed an ID-1, an Omni Antenna, Laptop, a short bash script I wrote to ping and record replies along with a GPS position, and an old GPS-18 puck.   All the nodes have fixed IP addresses so the script is quite simple, ping host A, if A replies within 2 seconds, record the next position output from the GPS, try the same with host B, loop forever, nothing fancy or terribly accurate.

As I only have two nodes set-up, and without much preparation (shutting down chatty applications), I persuaded SWMBO to do a short (war)drive, while I kept an eye on the laptop.

This first picture below shows (the red dots) the coverage from Nicky, EI3JB’s place (roughly at the 8 in the R708 closest to the top). Note the few packets recorded in Tramore, shortly after I left my own place.

The second is obviously from my place, as it is much more centred on Tramore.

Nothing really ground-breaking in either picture, but useful to help visualise potential coverage nonetheless. There is a huge black-spot on the section of road just leaving Tramore, as far as Ballykinsella (L4061 on the map).  This is of no surprise, as it is a tough location  for 430Mhz signals to get out of. What was surprising though is the packets received from EI3JBs location out in Tramore.

Next steps are to get EI8JA up and running, and complete a more thorough survey.

Now though, it is time for a beer!

6Y0A and yfktest.

Well, we made it to 2013. First up on the radio agenda this year was the January Irish Radio Transmitter Society 80 Meter band Counties Contest.

I hadn’t planned to enter the contest this year, but, the day before, I suddenly found myself with that afternoon free. I was invited along to the QTH of Liam, EI8BLB to operate his station along with EI8JA and EI3JB.

I brought along my roadkill linux laptop with yfktest on it for logging.

Yesterday, I received a card from “Kappy” WA4WTG, for 6Y0A, confirming Jamica as a new one for me (thanks Kappy). Kappy collects stamps so I took a bunch of stamps I had from Christmas cards and other received QSL’s and sent them onto him. In return 6Y0A was the first card I received in 2013.

While recording the card in my log, I was thinking that it would have been useful to have yfktest ‘tick off’ the counties as we worked them in the contest last Tuesday. So I had a quick look at the code.

It turned out to be pretty straightforward, as there was examples there already that I was able to follow, so that change should be in the repository come the summer IRTS 80m Counties Contest.

A very happy new year and wishing you good DX for 2013.

Bodging yfklog

To borrow a phrase from Darren, G0HWW. I did a bit of bodging of yfklog over last weekend. I couldn’t figure out how to get the existing code to talk to, so after a bit of bodging with the Ham::Reference::QRZ; module, it now pulls the basic information from, name, address2 (Town), operator class, grid, iota, state, qsl manager, and pops them into the relevant places in the log. A productive few hours!

I’m hoping to do the same for and, when I have a patch ready, Bob,W9YA will hopefully submit my changes assuming he deems them useful.

Another minor modification I made was to change the sort order of the exported online log, threw a bit of php at it, and now my most current contacts appear at the top of the output file.