OpenGD77 Tier2 – Hotspot update

posted in: DMR, GD-77, Ham radio | 22

Some problems were found by several people with the initial test version 0.0.7 so all testers should update to the latest version 0.0.71 and retest

Some, but not all problems that people reported seem to be associated with the host sending Tx and Rx frequencies which were not the same.

This caused the underlying DMR subsystem to think the radio needed to operate in Tier2 Passive mode, like it does when connecting to repeaters.

A legacy of how the official codeplug works, there isn’t a parameter in the Channel data which specifies whether the radio is communicating with a repeater in in Tier2 Passive (semi duplex), or Tier2 Active (simplex operation).

The firmware can only check whether the Tx an Rx frequencies are the same or different, and if they are different the DMR subsystem is put into Tier2 Passive mode (where the repeater is the synchronisation master) and if the frequencies are the same, it goes into Tier2 Active mode (where the GD-77 is the synchronisation mater)

Strangely some programs like BlueDV seem to send Tx and Rx frequencies which have small offsets e.g. 7Hz in one case, but PiStar can also do the same thing, as there seem to be rounding errors in the calculations somewhere in the host system.

You may have noticed sometimes in PiStar, especially with Duplex hotspots, if you enter a frequency eg 439.125 but the page updates and you find the frequency has changed to 439.1249999 . And this casued a problem for the OpenGD77 firmware

Some of the problems in the host software, seems to come from the way frequency offsets are handled. The MMDVMHost communication protocol does not have a way to send the offset frequencies, but instead it simply adds the offset (or subtracts for negative numbers), the offset frequency from the main frequency, and sends the resultant frequency to the hotspot.

This is regardless of which type of hotspot you use.

But this does not cause a problem on the normal simplex hotspot boards, as they only ever operate in simplex mode and analyse the frequencies they are sent.

Anyway. The fix I have put into version 0.0.71 is to take the average value of the Tx and Rx frequencies that are sent by BlueDV or PiStar and use that for both the Tx and Rx frequency.

In the longer term, I probably need to overhaul the DMR subsystem so that the Tier2 mode (Passive or Active) can be controlled separately from relying on comparing the Tx and Rx frequencies, but thats a much bigger change and would potentially cause bugs in the normal operation of the radio.

There was another potential problem where the Rx bandwidth filters could potentially be left set to 25kHz of the radio was on a channel with that bandwidth prior to hotspot mode being entered, so I’ve also fixed that problem in version 0.0.71

I know that 0.0.71 does not fix the problems for everyone, but I’d advise all testers to update to the Tier2Latest as it definitely fixes 2 potential causes of problems

BTW.
I will simultaneously be rolling out other fixes in next few days, but hopefully they won’t impact on the Hotspot mode functionality

22 Responses

  1. Rick
    |

    > [on the host, if entering] a frequency eg 439.125 but the page updates and you find the frequency has changed to 439.1249999

    Users of such host controller software, please make sure there is a bug or issue filed for your host software (i.e not to use floating point calculations, at least without any proper rounding).

  2. Rick
    |

    Good to read that we seem to agree that the RX=TX detection hack doesn’t hit the nail in many cases. 🙂

    — Forwarded for others to read: (from https://www.rogerclark.net/opengd77-user-guide-updated/) —
    > Tier 2 Active or Passive mode selection, is hidden from the operator, and selected by the firmware depending on whether the Tx and Rx frequencies are the same

    I’m not sure if multiple peer devices on a simplex frequency can reliably work based only on this. Doesn’t only one (and not more than one) device have to operate in the active mode, and all others in the passive mode.

    Maybe it might work, if by default the devices are only “eligible” to become the active slot calibrator, whith tha actual slot calibrator getting elected amoung the peers automatically, and automatically replaced if the previously selected device disappears.

    But I could still see cases that would need to be able to manually configure only one specific, adequately located device to operate as a designated “master” slot calibrator, and other devices to not be eligible as a slot clot calibrator, to ensure for more reliability.

    The third thought concerns allowing for the “dumb” data burst (time-slot) repeater mode.
    When it is enabled on a single frequency, there are cases where does and does not make sense for the device to be the slot calibrator. It depends on whether the device has a central or edge position.
    And in the case when a device is set up for data burst repeater mode with a RX/TX frequency pair (one way bridge), I am not sure yet if it also may or may not make sense to operate as a slot calibrator on the TX frequency, or just allow to optionally repeat the calibration that comes in (to be enabled only in one direction).

  3. Roger Clark
    |

    I had to fire up my duplex hat yesterday to do some testing, and PiStar did the thing where it had the rounding error on one of the frequencies.

    They must doing something like storing the frequency in MHz as a floating point number, rather than in Hz, or tens of Hertz

  4. Roger Clark
    |

    I have now added an internal function to override the DMR mode configured when the Tx/Rx frequency is set, and I am using it for the Hotspot.

    It will be used in my next Tier2Latest release, so that people who seem to need to run some strange Simolex offset freqs can make the Hotspot work with their other radios.

    Unfortunately I don’t see an easy way of allowing operators to directly control this, because virtually no one realises that the DMR operates in 2 distinct modes, I.e Active and Passive.

    So this control will need to still be automatic based on frequency

  5. Stefano
    |

    Hi, many thanks to Roger for his precious work and time spent… I saw the good steps forward in tier2 mode, so I wanto to try to ask if could be possible, in future, to put TWO gd77 with their TWO programming cables connected to the same raspberry/pistar and act as a “normal” repeater: one gd77 for TX side and the other for RX. The idea was already posted also here, as pistar probably has to be part of the work: https://forum.pistar.uk/viewtopic.php?f=24&t=2191
    Or, possible sync matters between tx and rx???
    Thank You once more, Stefano IZ4FXT

  6. Roger Clark
    |

    I’m not sure if this is possible

    PiStar would need to be modified and also I think possibly the Tx and Rx radios need to be synchronised to around 10uS accuracy, which would probably be technically impossible on Linux as its not a RTOS

  7. steven
    |

    hello how can I have this version, tester thanks
    stevens.mouveaux@sfr.fr

  8. Roger Clark
    |

    See the forum

    http://Www.opengd77.com

  9. Rick
    |

    > Tx and Rx radios need to be synchronised to around 10uS accuracy

    It might be possible for one radio to listen to the time slot calibration broadcasts on the frequency of the other.

    However, if the chipset is that fast, it might as well be capable to just switch to the TX frequency and resend the data frames received on the RX frequency. (A stand-alone two frequency repeater, that operates similar to a single frequency timeslot repeater. In contrast to the single frequency repeater, it would require a two frequency channel configuration on the user devices though.)

  10. Roger Clark
    |

    Yes.

    It may be possible to run one of the radios as Passive and the other as Active.

    And Yes. SFR is on the To Do list 😉

  11. Rick
    |

    Hi Roger,
    great!

    Above I was speculating though, about whether a *single* GD-77 without any pi-star could also work as a stand-alone repeater, doing data frame RX on one frequency and TX them on another frequency. (If swapping the timeslot info in the data frame is required, or if they can be left as is, might have to be tested.)

    PS: Would it still help you if I try to draw battery icons in that font editor?

  12. Roger Clark
    |

    Re:Icons

    I think Daniel now has all the graphics under control, I don’t know if he is doing icons but I think he may be.

    I’ll ask him.

  13. Rick
    |

    Oh, that “FMN” label didn’t look anything recognizable to me. Maybe NFM or nFM for “narrow FM” rather?

  14. Roger Clark
    |

    I will add this to the forum and github issues

  15. Francesco it9ybi
    |

    Hi Roger, I’m Francesco it9ybi from the city of Messina. I wanted to ask you if the gd-77 hotspot system had the ability to pass text messages sent from the DMR system to other IDs. I noticed that the classic hotspots do not allow this transit of DMR messages and I was hoping that the new gd-77 hotspot system could accept the sending of messages and a call to the DMR ID. Thank you 73

  16. Roger Clark
    |

    Not yet

    Unlike the simple hotspot boards the DMR chip inside the GD77 completely decodes the DMR 4FSK signal .
    So the Hotspot mode has to reconstruct the entire DMR frame for any data type it supports before sending that encoded DMR fame to PiStar

    And at the moment because the OpenGD77 does not support text messages the hotspot does not support them

  17. Francesco It9ybi
    |

    OK thanks for the info. Congratulations on your great work for this hotspot

  18. Anonymous
    |

    Is there any way that the GPS will be working in the near future?
    Thanks

  19. Roger Clark
    |

    GPS in TA data ??

  20. steven
    |

    Hello i can’t find the latest hotspot version

  21. Roger Clark
    |

    Hotspot mode is in both the Tier1 and Tier2 but has bugs in the Tier2 firmware.

    If you just want to use the radio as a Hotspot use the original Tier1 firmware.

    https://github.com/rogerclarkmelbourne/OpenGD77/raw/Tier1/firmware_binaries/daily_builds/firmware.sgl

  22. steven
    |

    hello Roger thanks you for your job

Leave a Reply