A comprehensive introduction to DMR is available to hams at no cost, thanks to the efforts of John Burningham <W2XAB>. His “Amateur Radio Guide to Digital Mobile Radio” won the 2016 Technical Achievement Award at Dayton Hamvention and the second edition was published in 2019. Even if you think you know how DMR works, this guide is full of useful information.
If your view of DMR is limited to the perspective of Pi-Star and Brandmeister or TGIF, this free book tells the rest of the story in its 27 pages. It is an easy read and will enhance your DMR knowledge.
I recently spoke with a fellow who was trying to use his hotspot on a frequency around 438 MHz. He wasn’t having much luck and with good reason. The MMDVM firmware blocks usage on all frequencies between 435 and 438 MHz. The block was implemented because 435-438 MHz is a suband used by the amateur satellite service and some amateurs noticed an increase of terrestrial interference with satellite communications.
Another ham that I spoke to is using a hotspot frequency that is also the input of several coordinated repeaters in my area. This is also not a good idea as it can also create interference, especially when operating a hotspot while mobile.
Here is my list of recommended simplex hotspot frequencies that is not likely to cause interference to other operators, repeaters, or satellites:
Most hams seem to set the admit criteria on their radios to Always for use with simplex hotspots. I strongly recommend that you use Channel Free instead to reduce the possibility of doubling.
Please wait one second after pressing PTT before speaking and wait one second after speaking to release PTT. This will ensure that there is no clipping of your first of last words.
All users of the 020 Network connections are required to have both a DMR ID and to be registered on the D-Star Gateway. It doesn’t matter if you don’t own a radio of that protocol. We are a multiprotocol system and by registering on both DMR and D-Star you are doing what needs to be done to be heard across all network connections.
Last August, I presented a solution for the “lost transmission” syndrome when using an MMDVM duplex hotspot. Several members of the 020 Digital Multiprotocol Group and I remain dissatisfied with our overall user experience. Granted, fewer transmissions are being lost than at first, but overall the number of transmissions during a longer QSO that fail to properly negotiate with the hotspot are higher than we’d like.
Earlier this week, 020 member Scott <KB2EAR> did some further digging and came up with aditional ideas found on the interwebs. I’ve taken these recommendations, added some others, and tested extensively. Here is my new set of recommendations for MMDVM duplex hotspot reliability when using DMR. This supersedes my article from August 29, 2019.
1) Update to the latest firmware.
2) Run the MMDVMcal procedure to minimize the BER
3) Set the MMDVMHost modem TXDelay=50
4) Set the MMDVMHost modem DMRTXLevel=55
5) Set the MMDVMHost DMR TXHang = 20
6) Turn off any mode other than DMR to avoid protocol scanning negotiation
I withdraw my earlier recommendation to reduce the DMR preamble. After much consideration, it seems to be unnecessary, with no clear benefit.
So far, using these setting on 2 different N5BOC duplex hotspots have yielded excellent results and reliability. Negotiation failures are now the rare exception. Tests were conducted with an Alinco DJ-MD5, a TYT MD-380, a CS-700 and a Hytera PD-365. Give these settings a try and let me know how they work for you.
Does anyone still make use of X10 powerline control devices? X10 has been largely replaced by more modern wifi based home automation devices, but I still have a few that control lighting.
I recently upgraded my main home/office server to Fedora 32. Fedora dropped python2 from new systems because python2 will be considered obsolete by the end of 2020. I have a serial based device called the X10 Firecracker which I use for wireless on/off control. The Firecracker is controlled by a python script run via crond, the system scheduler.
The script was written long ago by someone else in python2. While doing a post-upgrade checkout, I found that the firecracker.py script no longer functioned because I no longer had python2 installed on my system. So, it was time to port it to python3.
Fortunately, the porting effort was trivial. I have shared the results in my Github repository in case anyone else needs it. And if you’re still running any critical functions using python2 it is time to port them to python3.