After describing how to get notified of system criticalities via pager I wanted to have my DAPNET transmitters monitored via Nagios. A basic description can be found under [1]. Firstly you need to set up the plugin check_http_json. The source and installation hints can be found on [2]. That enables Nagios to query the DAPNET master using a JSON request and process the result.

A little different to the manual by RWTH Aachen I also configured the hostname of the master in /etc/nagios3/resource.cfg in order to have it not depend on the hostname of the Nagios host.

After settinp up a DAPNET client for the POCSAG Amateur Radio paging network I was looking for some good source for interesting information to be sent to my pager. I already had a Nagios monitoring solution set up in order to monitor several D-Star service and repeaters in my area. So I wanted to get Nagios to inform me as soon as one of these services changes state to critical.

Click the image for a larger view.

The solution is to implement a second method for nagios to send a notification. The original method to send an alarm via email was left as it is.

After discovering that the HamserverPi release 1.5 is actually a Debian wheezy based system and therefore not supporting RustPager ([1]) I manually set up a Debian Jessie lite on my Raspberry Pi to serve as web server for the HamNet. RustPager compiled fine after two hours of full CPU load.

As I had set up an APRS server for HamNet use I also wanted to do that on the Jessie lite system. Apparently there are no .deb packages to install from the package tree. So I tried to compile it manually mainly following Hessu’s guide on [2]. A problem occured with the statically linked library libevent.a. This is how I managed to get along with this error.

By the time the fan of my IC-2820 became really noisy. And as it runs from time to time automatically it can be disturbing although the unit is mounted under my table here. My friend DL5BQ was so kind as to look for a replacement part. And as I did not want to just cut the wire but leave the original part as it is I looked for the connector. The replacement is a Pabst 0412 fan that comes with a 5,25” PC connector. I replaced it with a 1.5mm two pin JST ZH connector.

Click the image for a larger view.

After building the MMDVM shield by Toufik F0DEI I tried to flash the MMDVM firmware using the MMDVM Makefile and executed “make deploy”. That command failed and the output said something about that it could not open the port. After looking through the openocd config files I discovered that it looks for a device with 0x0483/0x3748 as VID/PID.

But in my case the board showed up with 0x0483 0x374b. After changing this in /usr/share/openocd/scripts/interface/stlink-v2.cfg the deploy command worked like a charm and transferred the firmware successfully. By the way: This was done on an Ubuntu 16.04 with openocd v0.9.0 installed from the official repositories.

I am running an ICOM IC-2820 at home for D-Star repeater use. It has the D-Star unit built in and the GPS antenna was connected. The GPS module seems quite deaf at it takes ages for it to get a satellite fix. And what also was annoying is that the reported GPS position suffers from (small) drifts over time. That results in a bunch of point on aprs.fi maps and similar. So I was looking for a way around this issues and made a proof-of-concept.

Click the image for a larger view.

After running out of available serial ports for sniffing purposes I ordered a 4-port serial adapter with FTDI FT-4232H chip. That is basically an USB-RS232 adapter with four ports built into one device. That should be sufficient to run slsnif or jpnevulator in order to debug or reverse engineer serial protocols. After plugging the device there is the usual gambling about which device has what device name. For standard FT-232 chips I have some custom udev rules that create symlinks for various purposes. That should also happen to this quad port adapter.

A while ago I published some shell code that allowed for detection of the firmware version on DVmegas. That did not work realiably. So I made a small C snippet based on the MMDVM code by Jonathan G4KLX. The source can be found under [1]. It should compile on any Linux system without errors.

While looking around the MMDVM project I found a nice utility that allows for programming the Arduino Due from the console (see [1]). That is interesting because up to now I had always been on site to upgrade my MMDVM firmware. As I do not have a graphical environment running on the Raspberry Pi driving the MMDVM installing Arduino IDE is not an option.

Instead I can build the new MMDVM firmware with the Arduino IDE on any other computer and export the compiled sketch as binary file. That can be done using the “Sketch” menu within the Arduino IDE.

During some experiments with programming my DP3600 I experienced issues with my network connection when the radio’s programming cable is plugged to the USB port. This was also reported by Andreas, DL5APR when he plugged his DM series mobile radio in. The result is that no internet or local LAN connections are possible any more. Analyzing this reveals that it registers a new network device on my Ubuntu 16.04 host operating system. For some reason it claims the same IPv4 address as my eth0 device. That results in a broken routing table and all network stuff is interrupted.