MMDVM
Home Page Up DDAMTEK filters Digital TV Spectra MMDVM Repeater Levels Using DSD+ 1.09 GHz filters 145 MHz pagers

 

Digital Voice Hotspots

WARNING! - WORK IN PROGRESS - COMMENTS AND CORRECTIONS WELCOMED!

My own notes about configuring the MMDVM_HS_HAT digital voice hotspot using the excellent Pi-Star software and the radios which go through it.  This page is really my own notebook, and therefore a work in progress, but I hope it might eventually be a help for others.

Resources

D-Star

http://www.mdarc.org/activities/repeaters/dstar/linking
 


Configuring the Hotspot

Display

I added a 2.4-inch Nextion display based on information in the Pi-Star Wiki.  

You need to program the display's firmware by downloading a file and copying it to FAT32 formatted micro-SD card.  Choose your preferred display format and Nextion size and download from the .TFT files here.  There are files for the DB2OE, G4KLX and ON7LDS formats.  Although the PD0DIB page connects the display to the RPi, I expect that just the +5 supply is required, but perhaps it's better to terminate the data leads anyway.  Once the display is powered up with the card inserted, you will see it updating the firmware.  You can then power it down and remove the card.

You can connect the display to the MMDVM_HS HAT using the "modem" points.  I added in pins so that I could use the wires from the Nextion without cutting off the pre-supplied sockets.  Connect 0V and +5 V, and TX to RX reversed (i.e. TX display to RX HAT vice versa).

Using the Admin panel with the Pi-Star, select the display as Nextion, and the port as "Modem" as you are using the "modem" connection on the HAT.

Frequency

You need to choose a suitable in-band access frequency.  Mine was set to 431.075 MHz, although after careful checking I found that 431.0745 was closer to producing the correct output frequency.  Nevertheless, 500 Hz at 431 MHz is not a great error (and the device is in an unheated cupboard).


MMDVMHost  Configuration

Based on Pi-Star 3.4.8 ...

DMR Mode: Enabled
D-Star Mode: Enabled

etc. etc.


General configuration

Setting:
    Node Callsign: G9ABC
    Your DMR ID: 0235nnnn
    Frequency: 431.100 MHz
    Latitude: 56.0
    Longitude: -3.0
    Town: Edinburgh IO86
    Country: UK
    URL: Your QRZ.com URL or whatever
    Radio modem type: MMDVM_HS_Hat
    Node type: Private
    System time zone: Europe/London
    Dashboard language: englsh_uk


DMR

Setting:
    DMRMaster: DMRGateway
    Brandmeister Master: IBM_United_Kingdom_2341
    DMR+ Master: DMR+_DMR_SCOTLAND
    DMR+ Network:  (options blank, why?)
    XLX Master: XLX_000
    XLX Master Enable: off (why?)
    DMR CC: 1
    DMR EmbededLCOnly: off (why?)
    DMR DumpTAdata: on (why ?)


D-Star configuration

Need:
    Your callsign: e.g. G9ABC

Setting:
    RPT1: G9ABC B ("B" is the eighth character, and is B for 432 MHz band)
    RPT2: G9ABC G ("G" is the eighth character, and is for Gateway)
    Remote password: ****
    Default Reflector: REF001   C
    APRS Host: E.g. uk.aprs2.net
    ircDDBGateway language: e.g. English_UK
    Time annoucements: off (your choice, too distracting for me)
    Use DPlus for XRF: off (why?)

This is simply the reflector setting to start with, and to change reflector see your radio programming.  There's a list of reflectors here, which lists REF001C as D-Star's MegaRepeater in London.


Fusion

Settings:
    YSF Network: Room: UK DVMEGA (unable to test fully at the moment)

 


Programming your radio - examples

D-Star - Icom IC-7100

Name:
    E.g. "Local hotspot"

Operating Frequency:
    431.075 MHz

DUP:
    -DUP or +DUP, not OFF.  It appears that without duplex set the Icom will send the RPT2 field as "DIRECT*" which the hotspot doesn't recognise.  A "Repeater" style field is required, "CALLSIGN G", where <callsign> is what you programmed into your hotspot.  "G" for gateway.

Filter:
    I have this as 2.

Programming - it's convenient to program a number of channels:
    Set a channel for talking to your hotspot:
        CQCQCQ, G9ABC  B, G9ABC  G
    To link to a particular reflector
        REF001CL, G9ABC  B, G9ABC  G
        Note the "L" for Link.
        Here are some more examples:
        DCS005BL, G9ABC  B, G9ABC  G
        REF006AL, G9ABC  B, G9ABC  G
        REF079AL, G9ABC  B, G9ABC  G
    To unlink from a reflector
        .......U, G9ABC  B, G9ABC  G - 
        Note that the "U" must be in the 8th character position, preceded by spaces.
    To check using the Echo function:
        .......E, G9ABC  B, G9ABC  G - 
        Note that the "E" must be in the 8th character position, preceded by spaces.

Having programmed at least the above, you need to first select a reflector channel you programmed, then press the PTT for about half a second.  Then go back to the "talking" channel.  Your hotspot should remain connected to the chosen reflector.  Listen to check that you are on the expected reflector, and when there is a suitable gap call in.  To change reflector, first select the programmed Unlink channel, half-second PTT press, select the desired reflector channel, half-second press, then back to the talking channel.  It's actually easier to do than described, once you have the hang of it.

This is about the limit of my current knowledge, so comments and corrections are welcome!  Here's a screen-shot from the Icom programming software.


 
 

DMR - Radioddity GD-77

First, add the new channel, then a new zone (optional), to which the new channel is added.

To select other reflectors, use the Manual Dial function of the radio.  CPS 2.0.5.

Why, if my hotspot is set for slot 2, does my GD-77 work with the channel programmed as slot 1?

Direct Hotspot
Channel
  Mode: Digital
  Name: EE Reflector
  RX MHz: 439.71250 MHz
  Squelch: Normal
  TX: 430.71250 MHz
  Power: Low or High
  TOT (s): 300
  TOT Rekey Delay (s): 1
  Vox: off
  Admit criteria: Always
  Scan List: GB7EE-Scan
  Auto Scan: off
  Lone work: off
  Allow Talkround: off
  RX only: off
  Privacy: Off
  RX group list: Rx-9
  Color Code: 1
  Emergency System: System1
  Contact name: TG9
  Repeater slot: 2
  
Channel
  Mode: Digital
  Name: Micro-Node
  RX Freq: 431.07500 MHz
  Squelch: Normal
  TX Freq: 431.07500 MHz
  Power: Low
  TOT: oo (infinite)
  TOT Rekey Delay (s): 0
  Vox: unchecked
  Admit Criteria always
  Scan list: None
  Auto Scan: (greyed out)
  Lone Work: (greyed out)
  Allow Talkround: off
  Rx Only: off
  Privacy: Off
  Rx Group List: Rx-9
  Color code: 1
  Emergency System: None
  Contact name: TG 9
  Repeater Slot: 1
  
Zone
  Name: Edinburgh
Members....
  001: EE Reflector
  002: EE Local
  009: Micro-Node
  016: S21
 
Zone
  Name: Edinburgh
Members....
  001: EE Reflector
  002: EE Local
  009: Micro-Node
  016: S21
 
Rx Group List
  Name: Rx-9
Members:
  001: TG 9 (from digital contacts)
 
Rx Group List
  Name: Rx-9
Members:
  001: TG 9
   
Scan List
  001: Selected
  002: EE Reflector
  .. etc 
 
Contact => Digital Contact
  Name: TG 9
  Call ID: 00000009 (8 chars)
  Type: Group All
  Ring Style: None
  Call receive Tone: Off
Contact => Digital Contact
  Name: TG 9
  Call ID: 00000009 (8 chars)
  Type: Group All
  Ring Style: None
  Call receive Tone: Off

 

DMR - Retevis RT3

CPS: MD390 Radio Programming Software V1.36 TYT

Direct Hotspot
Channels Information
  Mode: Digital
  Bandwidth: 12.5 kHz
  Scan List: GB7EE
  Squelch: Normal
  RX Ref Frequency: Low
  TX Ref frequency: Low
  TOT (s): Infinite
  TOT Rekey Delay (s): 0
  Power: Low/High
  Name: EE2T9LOC
  RX: 439.7215 MHz
  TX: 430.7125 MHz
  Admit: Always
  Auto Scan: off
  Rx Only: off
  Lone Worker: off
  VOX: off
  Allow talkround: off
  Send GPS Info: off
  Receive GPS Info: off
  Private Call Confirmed: off
  Emergency Alarm Ack: off
  Data Call Confirmed: off
  Compressed Header: off
  Emergency System: None
  Contact name: Local TG9
  Group list: None
  Color Code: 1
  Repeater Slot: 2
  Privacy: None
  GPS System: 1
  
Channels Information
  Mode: Digital
  Bandwidth: 12.5 kHz
  Scan List: None
  Squelch: Normal
  RX Ref Frequency: Low
  TX Ref frequency: Low
  TOT (s): 180
  TOT Rekey Delay (s): 0
  Power: Low
  Name: MMDVM
  RX: 431.075 MHz
  TX: 431.075 MHz
  Admit: Always
  Auto Scan: off
  Rx Only: off
  Lone Worker: off
  VOX: off
  Allow talkround: off
  Send GPS Info: off
  Receive GPS Info: off
  Private Call Confirmed: off
  Emergency Alarm Ack: off
  Data Call Confirmed: off
  Compressed Header: off
  Emergency System: None
  Contact name: Local TG9
  Group list: None
  Color Code: 1
  Repeater Slot: 2
  Privacy: None
  GPS System: None
  
Zone Information
  Name: GB7EE
  Member: EE2T9LOC
  
Zone Information
  Name: Hotspot
  Member: MMDVM
  
Scan List
  Name: GB7EE
  Member: EE2T9LOC
 
 
Digital Contact
  Name: Local TG9
  Type: Group Call
  Call ID: 9
  Receive tone: Yes
Digital Contact
  Contact Name: Local TG9
  Type: Group Call
  Call ID: 9
  Receive tone: Yes

 

Fusion - Yaesu FT-70DE

Your callsign:
    G9ABC


Calibration

Why would you want to calibrate your hotspot?  To ensure that your hotspot is on the correct frequency, of course!  Others have suggested "tune for minimum BER", but that only matches the error in the hotspot to the error in your own handie-talkie (or whatever).  You do require an accurately calibrated receiver, of course, and one which is GPS-locked is strongly recommended.  You can check your handie-talkie in a similar way.  Stop here if you don't have a calibrated receiver!

Calibration is set in the TXOffset and RXOffset values in the Pi-Star Configuration, Expert, MMDVMHost menu option.  Looking at the Modem section, you will see TXOffset and RXOffset values you can alter - likely they both will currently be "0".  These are approximately the frequency difference you want the hotspot to be from its unmodified frequency, i.e. if the hotspot sends a 433.000 MHz signal 120 Hz high (on 433.000120 MHz), the offsets should be set to -120.  Normally, you would set both TXOffset and RXOffset to the same value.

Method

I used the MMDVMCal program which is available at github.  There is a variant already included in the excellent Pi-Star software which you can run from an SSH shell, and which does all the housekeeping of the Pi-Star services for you.  At the command prompt, type  pistar-mmdvmcal  and then you can list all the commands available by entering the "H" or "h" key.  The program allow many different tests, but a plain carrier was what I used, with the commands: "c" to make the hotspot send just a plain carrier, space-bar to turn the carrier on and off, and "q" to exit the program.  Note that the program ignores the TXOffset setting the Pi-Star configuration - was unaware of this to start with!

Notes

I used my GPS-locked receiver to watch the output of the hotspot as the TXOffset was adjusted, and I found that there are very brief bursts of tones at the start or end of each transmission in the different modes which are at the "carrier" frequency of the transmission.  It's obviously a modulated tone, or set of tones, but the central tone is obvious.  Some modes also show a null each side of the carrier (~3 kHz each side as I recall), and that be used as a coarser guide to correct setting.  I observe that the quantisation in the synthesiser is also becoming apparent at the tens of Hz level - i.e. you might not see the difference between a 119 and a 120 offset value.

Using that method I got my three hotspots within ~50 Hz of correct frequency, and I expect that they will drift more than that as ambient temperature varies, and the unit's CPU temperatures do vary with use as well (compare with and without the Pi-Star dashboard running, for example).

An Issue?

One issue which I've noticed before and affects at least two of my three hotspots is frequency jumping.  Several times I noticed that the frequency of the hotspot would jump ~30Hz lower and then back again, perhaps within a second or two.  Later I noticed that on subsequent transmissions either the lower or the higher frequency would be selected, and stay stable throughout someone's over.  I suspect this is undesirable behaviour for digital modes, and wonder whether it might be related to the quantisation effect I thought I saw in the synthesiser frequency selection?

Screen-shots

Here's an image of the calibration process with a DMR hotspot.  Note the area outlined in 
red which shows the short burst from the DMR at start-up having a central frequency 
almost exactly aligned with the centre of the waterfall display:
 
  
     DMR

 
Both D-Star and YSF have similar start tones. With the D-Star you can see the frequency 
jump I mentioned above with the two short red lines being slightly apart:

 
     D-Star

 
and here's the YSF start burst:


     YSF
 

Spectrum Analyser Screenshots

Here are spectrum analyser screenshots which I tried to grab near the start of a transmission to show the tones referenced above.  I set the analyser to record peaks to try and emphasise the tones.  I would like to have used a narrower resolution bandwidth but that meant a slower scan was needed, and some of the peaks would have been missing.  This is unlike SDR/FFT analysis where all frequencies are measured at once, rather than a sweep across the passband in a conventional analyser.  Ideally I would have liked some sort of single-sweep facility triggered by the tones, but if that analyser has that facility I don't yet know how to drive it!  The initial burst display would otherwise have been much cleaner.

All traces are with a 10 kHz span - so 1 kHz/division - looking at the 10.7 MHz IF output from an Icom IC-R8600 on a Rigol DSA-815 spectrum analyser.

DMR

Peaks at approximately +/- 1.2, 2.4, 3.6 and 4.8 kHz.

 

D-Star

Peaks at +/- 2.4 kHz and perhaps 4.8 kHz, and a deep notch at ~ +/- 3.5 kHz.  More like a sine-wave burst, perhaps, or simply that I caught the burst later and not so much of it?

 

YSF

Peaks at +/- 2.4 and 4.8 kHz, but a wider overall bandwidth (less of a drop-off at +/- 5 kHz).

 


Updating and settings for NTP and SNMP

You may like to use MRTG to monitor things like free memory, CPU usage and CPU temperature.

Updating

To update the pi-star you use two commands, making the disk writeable before running each.  Use PuTTY to log into the RPi from Windows.

rpi-rw
sudo pistar-update
rpi-rw
sudo pistar-upgrade

SNMP and NTP external access

I found that, by default, the security settings didn't allow SNMP or NTP access from devices on the local network.  tp fix this, you need to update the iptables:

rpi-rw
sudo iptables -I INPUT 3 -s 192.168.0.0/16 -p udp -m udp --dport 123 -j ACCEPT
sudo iptables -I INPUT 3 -s 192.168.0.0/16 -p udp -m udp --dport 161 -j ACCEPT
rpi-ro

Resetting SNMP temporary files

If you use SNMP "pass" commands, you may find that these stop working once the disk is read-only.  To reset that, you can use cron to run a job at e.g. 05:00 every day with the commands:

sudo mount -o remount,rw /dev/mmcblk0p2  /
sleep 1
sudo rm -rf /var/lib/snmp/.snmp-exec-cache && sudo ln -s /tmp/.snmp-exec-cache /var/lib/snmp/.snmp-exec-cache
sleep 1
sudo mount -o remount,ro /dev/mmcblk0p2  /

Even then, you will get some breaks in the logging - for example
 
 

 
Copyright © David Taylor, Edinburgh   Last modified: 2020 May 28 at 19:00