Week 10 – Many Solutions & DMR

Last week, I had three problems, two of which I couldn’t fix.

Problems & Solutions

Problem 1 was solved by recompiling the Nextion Driver and reinstalling it by hand.

Problem 2 was that the repeater wasn’t starting up as quickly as it does at home. I thought this was caused by the enterprise WiFi at my university. I’m fairly certain that was the problem. This issue seems to sort itself out, if you’re patient. I’m certain the issue is due to the time it takes the Pi to authenticate with the enterprise WiFi. I did add a button to restart the WiFi from the Nextion display. It is two simple commands.

I added a button to the display’s “System” or utilities screen and made it execute the following commands.

sudo ifdown wlan0 && sudo ifup wlan0

Basically this turns off the wlan0 interface and turns it back on.

Problem 3 was that I couldn’t always access the PiStar dashboard over the WiFi. That problem wasn’t really a problem. Again it had to do with the time the Pi takes to authenticate with the WiFi. I found that if I wait about a minute or two after the display shows the IP address, then go to the displayed IP address in a web browser, the PiStar dashboard appears as it should.

As for the issue with the self-assigned IP address over the ethernet connection, it doesn’t appear to matter. The two devices will communicate with one another given enough time.

A problem I ran into this week was that the repeater board doesn’t always initialize and connect to the software on the raspberry Pi, this is fixed by stopping and starting the mmdvmhost service, which can be done from the Nextion display.

Enable & configure dmr

The first thing I did was enable DMR and I did this from the expert settings for MMDVMHost instead of the main configuration tab. The reason for this is that when you configure from the main tab and click apply changes, you can lose settings you set in the expert MMDVMHost page.

    1. Navigate to the expert editor for MMDVMHost.
    2. Scroll down to DMR.
    3. Your settings should look like this:
    4. What do those settings mean?
      Enable – On (1) or Off (0)
      Beacon – Turn on (1) or off (0) beacon or a transmission that happens every so many minutes/hours to tell others your repeater exists.
      ColorCode – A number for your repeater, typically 1, but may be different. A radio set to a color code of 1 cannot talk to a station with their color code set to 2.
      SelfOnly – Limit DMR communication to your own callsign only (a Private hotspot)
      DumpTAData(1) – Talker Alias data (person’s name/location/callsign) are dropped (0) – Talker Alias data (person’s name/location/callsign) are sent to the RF stations. This can cause issues with some radios, but I set mine to off (0).
      ModeHang – The number of seconds the repeater should stay listening for DMR over RF after the end of a transmission.
    5. Next scroll down to the DMR Network section of MMDVMHost.
    6. What do these settings mean/do?
      Enable – Turns on the DMR network/gateway to the internet.
      Address – The IP Address of the Master Server you’re using. I used Brandmeister 3108 and found its IP address on the Brandmeister website under “Masters.” I believe this is only visible after you’ve logged in with your callsign and Brandmeister password.
      Port – This is the port on the server you’re connecting too. Leave this as the default.
      Password – The password to the Master Server. The default for most Masters is “passw0rd”. That’s a zero in place of the letter “o”.
      Slot1 – This turns on or off slot 1. DMR transmissions are sent in one of two “Time Slots.” Repeaters can receive and carry on two completely separate conversations with one on each time slot.
      Slot2 – This turns on or off time slot 2.
      ModeHang – This is the number of seconds the repeater should remain in DMR mode after the end of a network transmission.
    7. Click “Apply Changes”

Add Brandmeister panel

  1. Next I added the Brandmeister control panel to the repeater’s admin dashboard. I followed these instructions.
  2. This is what the Admin Dashboard looks like after adding the Brandmeister control panel. This screenshot was taken before I changed to the US Brandmeister 3108 Server which is why it says “BM United Kingdom” as the DMR Master.

 

Week 9 – Many Problems

This week, I downloaded a Nextion Display layout created by PD0DIB and modified it to include a system control page and an information page. After trying out the Nextion Driver Installer created by ON7LDS, I could get the screen to display information one time, but after switching pages, the data would disappear. To solve this problem, I looked at the Nextion Driver Installer script and followed most of the steps manually. Doing it this way also allowed me to switch the displayed CPU temperature from celsius to Fahrenheit. This pretty much solved the issues with the display.

In the Nextion Driver Installer Script, I followed this section:

if [ "$ND" = "" ]; then
    echo "+ No NextionDriver found, trying to install one."
    compileer
    $SYSTEMCTL
    $NDSTOP
    $MMDVMSTOP
    killall -q -I MMDVMHost
    killall -9 -q -I MMDVMHost
    if [ "$CHECK" = "PISTAR" ]; then 
        cp $DIR"/mmdvmhost.service.pistar" /usr/local/sbin/mmdvmhost.service
    fi
    if [ "$CHECK" = "JESSIE" ]; then 
        cp $DIR"/mmdvmhost.service.jessie" /lib/systemd/system/mmdvmhost.service
        cp $DIR"/mmdvmhost.timer.jessie" /lib/systemd/system/mmdvmhost.timer
        cp $DIR"/nextion-helper.service.jessie" /lib/systemd/system/nextion-helper.service
        if [ -e /etc/systemd/system/nextion-helper.service ]; then
            echo "+ there is already a link /etc/systemd/system/nextion-helper.service"
            echo "+ I'll leave it like that."
        else
            ln -s /lib/systemd/system/nextion-helper.service /etc/systemd/system/nextion-helper.service 
        fi
    fi
    cp NextionDriver $BINDIR
    echo "+ Check version :"
    NextionDriver -V
    checkversion
    helpfiles
    echo -e "+ NextionDriver installed\n"
    echo -e "+ -----------------------------------------------"
    echo -e "+ We will now start the configuration program ...\n"
    $DIR/NextionDriver_ConvertConfig $CONFIGDIR$CONFIGFILE
    herstart
    exit
fi

Basically all I did was the following:

  1. Stop MMDVMHost with “sudo service mmdvmhost stop”
  2. Download the Nextion Driver from github into the /tmp folder
  3. rpi-rw
    cd /tmp
    git clone https://github.com/on7lds/NextionDriver.git
    cd NextionDriver
    
  4. Compile the driver by running “make”
  5. Then you should end up with a binary called “NextionDriver”.
  6. Copy the binary into /usr/local/bin with
    sudo cp NextionDriver /usr/local/bin/NextionDriver
    
  7. This was all done AFTER running NextionDriverInstaller.sh on its own. So, my installation had all the helper files already installed before I ran through these commands.

Problem 2

The hotspot/repeater doesn’t startup right away like it does at home. I’m guessing this is because of the enterprise WiFi at my University. Sometimes the repeater starts right up and works perfectly and other times it does not work.

Problem 2 Solutions

  1. Create a simple script to reset the WiFi connection on the Pi and create a button on the Nextion Display Layout that would allow me to run this script.
  2. Use the same script, but have it run after the Pi is completely booted and add a line to restart the MMDVMHost service.

Problem 3

I could not always access the PiStar dashboard through the ethernet/crossover cable or through the University’s WiFi. Again sometimes I had no issues and other times it would not connect. At first I thought this was due to having both the ethernet and the WiFi running on the Pi, but after removing the ethernet, I had the same issue. I’m growing more suspicious of the enterprise WiFi. As for it not working over the crossover cable, I believe this is due to the fact that the computer is addressing itself with a self-assigned IP address (a 169 address). The problem appears intermittent.

Problem 3 Solutions

  1. Use the solutions for problem 2 as I believe the two problems may be related.
  2. Create a static IP on the Pi and the Computer for the ethernet connection.
  3. Change the PiStar firewall rule for the dashboard from “Private” to “Public.”

Going Forward

  1. Enable DMR and configure it.
  2. Install the Brandmeister control panel on PiStar.
  3. Program the DMR Radio.
  4. Create a blog post about programming the DSTAR and DMR radios.

I also wanted to create a 3D printed case for this project, however I am not sure I will have enough time to do that, especially with encountering these problems.

Week 8 – Setting TX & RX Offset

After setting up the MMDVM duplex hotspot board, it is necessary to adjust the transmit and receive offsets in the MMDVMHost expert editor section. Basically this corrects the transmit (TX) and receive (RX) frequency of the board, if they’re not on frequency.

I went to a fellow amateur radio operator’s house recently to test my board with his HP 8920A Service Monitor. According to this ham, the service monitor is about 30 years old and cost around $30,000 new. Every 2 years he has it calibrated to NIST standards and it is accurate to +/- 1 Hertz.

The back of the board recommends a TX and RX offset of 500 and then tells you to adjust until the BER or Bit Error Rate is less than 5%. With my friend’s help, I tested the output frequency of the repeater/hotspot board without setting any TX offset and the transmit frequency (FRQ) was about 442.999300Mhz. So I adjusted the TX offset to 500 and retested the transmit frequency. It appears to be getting closer, showing a frequency of about 442.999700Mhz. So I bumped the TX offset up to 800 and that brought the TX frequency up to approximately. 443.000000Mhz, which is right on frequency.

Setting the RX offset is a bit more difficult because there isn’t really a way to test that within Pi-Star. So, I transmitted to the repeater board with my DSTAR handheld and found that I had a bit error rate of 0.1% which really doesn’t need to be fixed.

0.1% Bit Error Rate

I set the RX offset equal to the TX offset (800) and that brought the bit error rate down to 0.0%, which is perfect.

0.0% Bit Error Rate

I also worked on installing the Nextion Display Driver, however I’m encountering problems with it. The screen layout disconnects from the MMDVMHost software every time the screen changes. I need to work on this a little bit more to solve that problem. I’m thinking the problem is the layout I used. I was testing with a layout from another ham that displays a lot of information and I think the screen has trouble keeping up with the amount of data. I will detail this process in my next post.

Week 6 – Hardware

Last week I decided to purchase a little board called an MMDVM_HS_HAT_DUPLEX. What I purchased is a cheaper clone, but it should work about the same as it uses the same firmware. Essentially it is a tiny low-powered repeater on a single circuit board. It is designed to be a personal duplex hotspot.

MMDVM_HS_HAT_DUPLEX

The board has an STM32 microcontroller and two ADF7021 radio microchips. The board should produce about 10mW of RF power output. The board has a number of LED’s to indicate various things such as, power, carrier operated squelch (COS), Push-To-Talk (PTT), and an LED for each digital mode the board is capable of such as DSTAR, DMR, YSF, P25, and NXDN.

MMDVM Digital Mode LEDs

The board is a hat so it sits directly on top of the Raspberry Pi and uses the Pi’s GPIO pins to communicate with the Pi-Star Software.

MMDVM & Raspberry Pi GPIO Connection

Fully assembled, this is what the Pi looks like with the MMDVM Duplex Hot Spot board attached.

MMDVM_HS_HAT_Duplex on Raspberry Pi 3b

The other piece of this project that I decided to add, was a screen. It has not arrived yet. This will solve the problem of not knowing the IP address of the Pi to connect to the dashboard. I did some reading and the MMDVM Duplex Board is capable of working with a small OLED display OR a Nextion touch screen. I opted for the touch screen which will give me more options for controlling the device. On most of the forums and Facebook groups for DSTAR hotspots, other hams seem to recommend the 3.5″ display most often. I opted for a slightly smaller 3.2″ display, specifically the¬†NX4024K032_011R.

Nextion Display

It’s slightly cheaper than the 3.5″ screen and slightly smaller. This is an enhanced version with more flash memory and more RAM than the basic models.

Nextion Editor Layout

This display is a Human Machine Interface that is programmed using a piece of software called Nextion Editor. It’s a What You See Is What You Get (WYSIWYG) editor. The coding to make the screen work seems pretty simple, however I have not looked at the code in the Pi-Star software that actually sends the information to the screen.

Here I found a guide on using the Nextion Editor software, which I’m sure will be useful for creating my own display interface. Here is another guide on creating a screen layout/interface that is specific to the MMDVM and ham radio. The interface is designed, saved to an HMI file, and then compiled into a TFT file, which is then uploaded to the screen. You can upload the TFT file via a USB to TTL serial adapter or by using a microSD card with the TFT file on it, inserted into the microSD card slot on the Nextion Display.

USB to TTL Serial Adapter

You may also find *.TFT files that other amateur radio operators (hams) have made available on a few different MMDVM Hotspot groups. These files (as long as they’re made for the exact screen you’re using) can be downloaded to your computer and uploaded to your screen. If you can get the *.HMI file which is typically available with the *.TFT files, you can edit the HMI file in Nextion Editor to suit your needs and then upload it to your screen. Here is an example interface from the second guide that another ham has created.

UI sample from PD0DIB

Next week I’ll set up the MMDVM to work with the Raspberry Pi and update the MMDVM’s firmware.

Week 3 – DSTAR Repeaters

Last week, I decided to use a software I’ve worked with in the past, called Pi-Star to setup a digital multimode amateur radio repeater. This week I did a bit more research on DSTAR and found some diagrams to hopefully explain things a little better. If you aren’t familiar with what a ham radio repeater does, there is a diagram below.

Basically a repeater listens on one frequency and simultaneously retransmits what it “hears” on another frequency. Typically a repeater is at an elevated location (i.e. a mountain top, tall building, etc), running a high performance antenna system and higher power output.

How does a digital repeater work? It works in much the same way as a regular repeater, however with DSTAR, there is often an internet link via a computer added to the repeater as shown below.

The diagram above is of one digital mode called DSTAR, but most digital modes work similarly in respect to the hardware required. In a DSTAR repeater there is a radio connected to an interface board which is then connected to a computer (usually either a PC or a Raspberry Pi). The computer makes and manages the connections through the internet to other repeaters or reflectors (conference servers). The computer makes these connections based on commands sent over the radio, sent through a remote control application, or sent through a web interface. An example of the Pi-Star web interface for the KC3ESS DSTAR repeater that I help manage is included below.

The dashboard lists the timestamp of the transmission, the target (where the transmission is intended to go), the RPT 1, and RPT 2 callsigns.

The target of a transmission tells the computer what to do, so CQCQCQ means that the transmission is intended for everyone to hear, REF030CL tells the computer to link to reflector 30C, and _______U, tells the computer to unlink from the current connection.

The RPT 1 callsign is the callsign of the repeater/hotspot/reflector that the transmission is being received by and forwarded to the internet from. In this photo the RPT 1 callsign, KC3ESS_B means that the transmission is going through the KC3ESS repeater and the B means a frequency in the UHF 70 centimeter band (420Mhz to 450Mhz). The callsign may also be REF063C which means the transmission is being received over the internet from reflector 63C.

The RPT 2 callsign is the destination callsign. In the photo above we have, KC3ESS_G, which means the destination of the transmission is the internet gateway on the KC3ESS repeater. Essentially that tells the computer connected to the KC3ESS repeater to send the transmission over the internet. If this were set to KC3ESS_B, the transmission would never leave the local KC3ESS repeater.

The target or URCALL field, RPT1 field, & RPT2 field all work together to route the DSTAR transmission to the appropriate location within the DSTAR network.

I also created a Gantt Chart for this project with a list of tasks.

Photos link to their respective sources.

Week 2

This week I continued my research on digital repeaters and software. I’ve decided to use a Raspberry Pi with the Pi-Star image, which contains software used to setup, configure, and maintain a digital repeater. It’s the most complete package I’ve seen and is widely recommended by other hams running digital repeaters. I have worked with this particular software package before so I have some understanding of how it works and how to use it. It basically contains many pieces of software which work together to manage and control a digital repeater. It can also be used to control digital multimode hotspots (duplex or simplex hotspots).

Pi-Star contains the popular digital radio software created by Jonathan Naylor, G4KLX: ircDDBGateway, DSTARRepeater, DMRGateway, and MMDVMHost. It also contains a complete dashboard and can support a wide variety of hardware. MMDVM stands for Multi Mode Digital Voice Modem.

The Raspberry Pi is a great piece of hardware for projects like this due to its cost, reliability, availability, and small size. I will be using the one I have already, a Pi 3B.