I few weeks ago, the Duplex MMDVM hotspot board, I ordered from an eBay vendor in China, finally arrived.
There appear to be 2 different types of duplex boards available on eBay.
One which seems to be a direct copy an open source design, and the version of board I ordered; which looks looks like the one I received
This board to be inspired by this open source design, https://github.com/phl0/MMDVM_HS_Dual_Hat ,
But looking in detail, at the board I received, it’s considerably different from the open source version, and is probably only similar at schematic level.
All the duplex boards use the standard format Raspberry Pi “Hat” and can be connected to a RPi 2,3 or Zero ( or Zero W).
The board is wider than a RPi Zero, and fits neatly onto the top of a RPi 3B (or 3B+)
I had a RPi 3B which I was not using, so I decided to use that as the host board, and I downloaded and installed the latest version of Pi-Star.
Using educated guesswork…
On the Pi-Star configuration page, I selected the “Duplex Repeater (or Half-Duplex on Hotspots)” as the “Controller Mode” and selected “MMDVM_HS_Dual_Hat” from the “Radio/Modem Type”
After applying these settings, I was able to enter a separate transmit and receive frequency. I chose two frequencies 6 MHz apart on the 70cms band, which is used by a repeater about 1000km from me, but not used for any local repeaters.
The board was supplied with two small, cheep looking antennas, which I presume are designed for the 433 MHz ISM band, and using these directly screwed into the SMA connectors, I found was the hotspot did not seem to work very well
This is probably because of the desensitization of the Rx by the Tx.
I’ve seen some YouTube videos where people have used 90 degree adapters attached to the SMA sockets on the board, so that the antennas can be rotated to stick away from each other , but as I didn’t have any SMA adaptors, I simply disconnected the Tx antenna connected the Tx output to an external antenna which is on the roof of the house.
Using at least one external antenna resolved the desensitization problem, and the added benefit of connecting the Tx connector to an external antenna, is that the range of the hotspot should be increased so that it can be accessed from the garden, and up to around 250m down the street!
Unfortunately as soon as I tried using the hotspot to have actual QSO”s, I received reports that my signal was abruptly cutting out after about a minute. In some cases the audio would make a sort of squawk sound as it cut out.
I conducted a some tests and the timeout appeared to be almost exactly 60 secs
Initially I suspected that there was a 1 minute timeout somewhere in the configuration, however after finding and changing any configuration setting which looked like a timing value of “60”. I came to the conclusion that perhaps there was a problem in the firmware which perhaps has a 1 minute timeout for these duplex boards
By coincidence, around this time, I spoke to Steve K2GOG, who told me that he encountered similar issues on his duplex hotspots, but had fixed the problem by using passive cooling on the TCXO, and on the processor on his Raspberry Pi.
Unfortunately, when I tried the a similar solution, by using a PC CPU cooling fan… It made absolutely no difference.
At this point I decided to raise an issue on the firmware GitHub repository, of Andy CA6JAU in the hope that he could shed some light on the problem, and after a few days, Andy confirmed that there was some sort of problem with the firmware, as he could reproduce the problem on his duplex hotspot, but was surprised that on one had noticed the bug before now.
Fast forward a week, and Andy had tracked down the problem, but it wasn’t completely good news.
The reason that the hotspot cuts out, is related to differences between master clock frequency in the hotspot and in the radio. Over time, while the radio is transmitting and the hotspot is receiving and re-transmitting, the hotspot Tx gets far enough out of sync with the radio until a point where the connection is dropped.
The Rx ADF7021 performs “clock recovery” on the incoming signal, but there is no way to transfer this synchronized clock into the Tx ADF7021, as the ADF7021 does not have a clock output.
Andy had managed to modify his firmware, to attempt to detect if there was an offset in the incoming and outgoing data, and cope with some miss-alignment, but all this did is delay the inevitable time when the radio and hotspot were so out of sync the connection gets dropped.
The good news however, is that the time before the hotspot cuts out, has been extended from 1 minute to around 4 minutes (on most radios), and since a lot of DMR repeaters and servers have a 3 minute timeout, the server timeout will occur before the hotspot timeout.
And as this timeout is effectively reset at the start of each over, the problem has effectively been solved.
Andy released firmware version 1.4.7, a few days ago, and all PiStar users can install it by logging into the SSH terminal and using the normal command to update their firmware.
Now, just when you thought this article was complete, I have to report yet another, unresolved problem with these duplex hotspots…
My TYT MD-380 would not connect to the hotspot at all!
Discussing the problem with Andy, he initially thought the problem was the overall latency between the signal being received from the MD-380 to when the hotspot responded (transmitted) back to the MD-380.
In an attempt to resolve this problem, I downloaded the source code for the firmware and the compiler toolchain, onto my Raspberry Pi, and modified the Make file, to use maximum code opimisation (using the -O3 option), as this normally yields a reasonable increase in speed – but can sometimes stop code working completely.
However after recompiling the firmware with this level of optimisation, it didn’t make any difference to the MD-380 problem.
My next step was going to be an attempt to overclock the STM32F103C8 MCU on the hotspot, because although its official maximum speed is 72Mhz, I have overclocked them to 128Mhz with no side effects, apart from the MCU getting a few degrees warmer.
Unfortunately when I looked at the code, it wasn’t going to be that easy to change, as the firmware now uses the STM “Standard peripheral library”, which does not have nice macros’ like the Arduino STM32 core does, to set the PLL multipler, or adjust the baud rate of the UART etc
Luckily before I got stuck into reading the 1000+ page programmers manual for the STM32, in order to work out the correct bit patterns for PLL multipliers etc, Andy got back to me and said that he had a work-around for the MD-380 by increasing the Tx deviation.
The setting that needs to change is in the Expert MMDVM Host page of PiStar and is called DMRTxLevel. Normally this is set to 50 and needs to be increased to around 55 to allow the MD-380 to connect.
I made this change and instantly found the MD-380 would connect, however I noticed that every so often that the PiStar dashboard indicated that the MD-380 was on Timeslot 1 when it was actually transmitting on Timeslot 2.
At the time of writing, there is no other work-around for any MD-380 users who’s radio won’t connect to the hotspot. So its best to keep an eye on PiStar when you are transmitting, to make sure that you are on the TS you expect.
Because if the hotspot is looking on TS1 and you are transmitting the audio on TS2, then the network gets no audio at all.
As I’m now quite happy with my duplex hotspot, as it works fine with my GD-77, I have started to do range testing, but that will be a subject of another blog post.