For the last 6 weeks, I’ve been intensively working on the Hotspot mode as part of the OpenGD77 firmware, and it is now finally with the Beta testers in Australia, Europe and the USA.
Note. Currently firmware seems to be stable but not completely bug free, so I am limiting its use to the Beta testers.
Hotspot mode converts a Radioddity GD-77, running the OpenGD77 firmware, into a DMR ONLY high power hotspot when its connected to a Raspberry Pi running PiStar.
No other hardware is required, just the RPi and the GD-77
In this photo I’m using a Raspberry Pi 3B+, but I’ve also tested with a RPi Zero W and it works just as well.
The GD-77 is connected to the RPi via its USB programming cable, and the only change that needs to be made in PiStar, is to change the modem type to any of the “Zumspot” compatible modem types e.g. the “Zumspot Libre”
One thing however you won’t see unless you modify you copy of PiStar is the “modem” name being displayed in the PiStar dashboard, because PiStar only supports displaying the firmware version for the specific “modems” in the list
I have modified my copy of PiStar to add the OpenGD77 Hotspot, and I presume if enough people eventually use their GD-77’s as hotspots, Andy may add the OpenGD77 Hotspot as a new modem type in PiStar, so that it will display correctly.
I’ve done rather shaky video showing the OpenGD77 Hotspot mode working with a Rasperry Pi Zero.
For those of you interested in the technical details, please read on..
Conceptually both Kai and I assumed that adding Hotspot mode functionality to the OpenGD77 firmware should not be too complicated, because we can access the DMR data from any transmission which the GD-77 receives, and can also transmit and audio and other data via DMR RF.
Unfortunately our assumptions about the difficulty in writing Hotspot mode were not correct, and a great deal of new code needed to be added to the OpenGD77 firmware to support Hotspot mode.
Before I continue, I think its worthwhile explaining how a normal PiStar hotspot works.
At the core of PiStar is a program called MMDVMHost, which was written my Jonathan G4LKX, which interfaces the original MMDVM modem hardware, to the Internet servers for DMR and other protocols.
MMDVMHost communicates with the “modem” using its own serial protocol, originally via USB Serial but now more commonly via GPIO serial on a Raspberry Pi to a MMDVM_HS Hat board, aka Jumbospot.
MMDVMHost handles the server connectivity and a loads of other functions, to seamlessly transfer the data, to and from the “modem” board.
I had assumed that the data being set between the “modem” hardware and MMDVMHost contained high level DMR data, including the transmitting stations DMR ID number and the Talkgroup number as well as the AMBE compressed audio data bytes. However, when intercepted some of the serial data being sent between the Raspberry Pi and my duplex hat board, (running in simplex mode), I realised that I was at least partially wrong about how MMDVMHost and MMDVM (or MMDVM_HS) work.
I expected to see data bytes containing my DMR ID (5053238) , as well as bytes containing the Talkgroup I was using (505), but the data between the hotspot board and the RPi did not seem to contain that data at all.
After some research, I found out that the data is in the “On Air” format, and that modem (Hat etc) boards only do minimal processing of the DMR 4FSK data which they receive before sending it to MMDVMHost
MMDVMHost then creates a packet of network data, which is a header containing the Source and Destination ID’s etc, followed by the raw “On Air” data.
At the other end of the system, e.g. any hotspots connected to the same Talkgroup; MMDVMHost, sends the On Air portion of the network packet of data to the modem, and the modem basically just remodulates the On Air data to 4FSK and transmits it.
The GD-77 hardware however, works completely differently….
The GD-77 has a dedicated IC ( Hongrui HR-C6000) which performs both the 4FSK demodulation and also completely decodes the DMR “On Air” protocol, so that the CPU in the GD-77 does not need to do this processing.
Note. This is the same IC that is used in radios like the TYT MD-380 etc and I Baofeng RD-5R and Baofeng DM-1801 etc
Except the MD-380 uses the older version, called the HR-C5000
Hence the only way to interface the OpenGD77 firmware to MMDVMHost was for the OpenGD77 firmware to generate the “On Air” format data that MMDVMHost and every other hotspot expected to receive.
This would have been an incredibly difficult task, except that MMDVMHost contains all the functionality that I needed to both encode to the “On Air” format and also to decode the “On Air” format, and because MMDVMHost is open source, I was able to incorporate the majority of its DMR processing functionality, into the OpenGD77 firmware.
Unfortunately, even though MMDVMHost contained all the necessary functionality, MMDVMHost does not use the functionality in the way that I needed to. For example, It normally decodes the “On Air” data, rather than encoding it, so I had to work out which bits of MMDVMHost I needed to encorporate in the OpenGD77 firmware and also how to use those parts, to do almost the reverse of what they normally do.
And just to complicate things, MMDVMHost is written in the C++ language in an Object Orientated way, whereas the OpenGD77 firmware uses the C programming language which does not support Objects or a number of other features of C++, like function overloading which MMDVMHost makes use of.
So all the source code files needed to be “ported” from C++ to C by making changes to around 50% of the code.
Consequentially, it took me 3 or 4 weeks to find the parts of the functionality in MMDVMHost which I needed to port, and to port them and integrate them into the OpenGD77 firmware.
Additionally, I had to implement the functionality to communicate via MMDVHost’s serial protocol, as well as integrate the new functionality into the existing OpenGD77 Tx and Rx functionality.
Needless to say this was quite a complex task, but after 50 hours of work, I was able to receive network data from MMDVMHost and get the GD-77 to transmit it via RF.
It took me another week to write the functionality so that the received RF DMR signal was sent to MMDVHost, and yet another week to add some missing functionality like Private Calling, and also the transmission of Talker Alias data when received from MMDVMHost as embedded data in the Voice audio frames.
Various versions of the firmware have been with the Beta testers for about a week, and they are still uncovering a few bugs, so currently I don’t feel its stable enough for general release. However I plan to make it part of the OpenGD77 firmware in the fullness of time.
If anyone has some specific questions, please post comments, as I have glossed over a lot of the complex technical details of how I made this work, as that would probably be incredibly tedious and also take many hours to document 😉