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+.

After getting the the MMDVM up and running for access to D-Star and DMR Brandmeister networks I experimented with the touch screen of the Nextion TFT display upon request of DL5BQ. The idea was to have a standalone unit that can for example be shut down with a single key press. Currently this is realized with a push button and a Python script (see [1]).

But as we added a Nextion display with touch screen to the Raspberry Pi running the MMDVMHost the idea was of course to use the touch screen for input. The option are for example to shut the RPi down or to link to a specific reflector with a press on the button of the display. This would also save input pins and instead use the wiring to the display which is there anyway.

Click the image for a larger view.

In preparation for some software development work contributing to XLX reflector software I wanted to disassemble the UDP stream exchanged between D-Star reflectors and a reflector and a connected node respectively. My wish is to add the output of the user configuralbe 20 character message to the dashboard. If running well I would also replace the link to aprs.fi with an output of GPS data transmitted by the client if available. The current solution just links to the callsign which is not necessarilly the real current position.

Click the image for a larger view.