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.

After digging around on Twitter DB9MAT and me did some experiments with HBlink (see [1]). This is a nice little piece of Phyton code that implements some kind of homebrew protocol that can be used to link some MMDVMHosts together. After cloning the github repository on an Ubuntu 16.04 system I just had to install a Phyton library for bitstream operations. After that the binary hblink.py can be launched. Of course it needs some configuration.

As I could not visit the HamRadio this year I took various chances to see whats going on down there. I kept an eye on APRS to see what the visitors are doing. To visualize this a bit I created a little script that compiles a movie from screenshots taken every minute. The screenshots are taken from the Gnome Desktop showing the FireFox browser with the aprs.fi page from the location. A cronjob executes the binary scrot for taking the screenshot every minute. The result looks like this:

Click the image for a larger view.

The other day I read an article about some nice project using a Raspberry Pi as a WIFI access point generating a guest WIFI network. The key is generated randomly and presented as QR code to the user on a small TFT display. For protection purposes it is re-generated every 24 hours or the like (See [1]).

I tried to implement such a thing using 802.1X with predefined user and passwords placing the user into a separated VLAN. That failed because it required SSL certificates signed by an official Certification Authority which I do not have. The other option would be to integrate my own CA into the devices connecting the wireless network. So no option either.

Click the image for a larger view.

Some Windows software in my virtualized Windows XP machine stopped working the other day. It says that the validity period is over. Okay that should not be too hard to get around this issue. As the machine is running on a VBox anyway I looked for some solution to fake the BIOS time - and found something:

1

$ VBoxManage modifyvm "Windows Testsystem" --biossystemtimeoffset -126489600000

That simly changes the offset from the system time to the virtualized BIOS time. Note: It takes milliseconds as an argument. As I needed the time to be some 4 years a ago I calculated: 60*60*24*366*4*1000. That results in:

Click the image for a larger view.

Today I wanted to update my MMDVM to the latest firmware as some new features were added during the last commits. Firstly I upgraded the Arduino IDE to 1.6.9 and the board files to SAM 1.6.8. After that the firmware wouldn’t compile anymore. Ah yes, there was something to be manually edited in a platform.txt file.

After searching I found it to be in /home/$user/.arduino15/packages/arduino/hardware/sam/1.6.8/. The diff is here:

1
2
3
4
5
6
7
8
9
10
11
12

$ diff -purN platform.txt.bak platform.txt
--- platform.txt.bak 2016-05-13 08:42:00.993078492 +0200
+++ platform.txt  2016-05-13 08:42:08.744972003 +0200
@@ -78,7 +78,7 @@ archive_file_path={build.path}/{archive_
 recipe.ar.pattern="{compiler.path}{compiler.ar.cmd}" {compiler.ar.flags} {compiler.ar.extra_flags} "{archive_file_path}" "{object_file}"
 
 ## Combine gc-sections, archives, and objects
-recipe.c.combine.pattern="{compiler.path}{compiler.c.elf.cmd}" -mcpu={build.mcu} -mthumb {compiler.c.elf.flags} "-T{build.variant.path}/{build.ldscript}" "-Wl,-Map,{build.path}/{build.project_name}.map" {compiler.c.elf.extra_flags} -o "{build.path}/{build.project_name}.elf" "-L{build.path}" -Wl,--cref -Wl,--check-sections -Wl,--gc-sections -Wl,--entry=Reset_Handler -Wl,--unresolved-symbols=report-all -Wl,--warn-common -Wl,--warn-section-align -Wl,--start-group {compiler.combine.flags} {object_files} "{build.variant.path}/{build.variant_system_lib}" "{build.path}/{archive_file}" -Wl,--end-group -lm -gcc
+recipe.c.combine.pattern="{compiler.path}{compiler.c.elf.cmd}" -mcpu={build.mcu} -mthumb {compiler.c.elf.flags} "-T{build.variant.path}/{build.ldscript}" "-Wl,-Map,{build.path}/{build.project_name}.map" {compiler.c.elf.extra_flags} -o "{build.path}/{build.project_name}.elf" "-L{build.path}" -Wl,--cref -Wl,--check-sections -Wl,--gc-sections -Wl,--entry=Reset_Handler -Wl,--unresolved-symbols=report-all -Wl,--warn-common -Wl,--warn-section-align -Wl,--start-group {compiler.combine.flags} {object_files} "{build.variant.path}/{build.variant_system_lib}" "{build.system.path}/CMSIS/CMSIS/Lib/GCC/libarm_cortexM3l_math.a" "{build.path}/{archive_file}" -Wl,--end-group -lm -gcc
 
 ## Create output (.bin file)
 recipe.objcopy.bin.pattern="{compiler.path}{compiler.elf2hex.cmd}" {compiler.elf2hex.flags} {compiler.elf2hex.extra_flags} "{build.path}/{build.project_name}.elf" "{build.path}/{build.project_name}.bin"

This is now also part of BUILD.md in the official github repo. See [1].

References

[1] https://github.com/g4klx/MMDVM/blob/master/BUILD.txt

After discussion on a thread in the MMDVM group I hacked a little shell script that queries the DVmega for its firmware version. I got the details from the MMDVMHost code. That is sending 3 bytes to the unit and reading the response. For the version you need to send the bytes 0xE0 0x03 0x00 and read back the version information. That is done by the following shell script:

1
2
3
4
5
6
7
8
9
10
11
12
13

#!/bin/bash

set -m

PORT="/dev/ttyUSB5"

stty -F ${PORT} ospeed 115200 ispeed 115200 -crtscts

#cat -v < $PORT &
dd if=${PORT} bs=1 count=17 status=none | sed -e "s/$/\n/" &
echo -ne '\xE0\x03\x00' > ${PORT}
sleep 0.1
exit 0

I tested it with a DVmega on a BlueStack micro+.