ysf/fcs doesn't connect. DG-ID shows 127 instead of 0.
Posted: Fri Dec 08, 2023 4:00 am
I have several mmdvm jumbospots. Some were purchased but most were built from my own pi zero w's and hat board kits. They seem to have always worked fine on DMR and D*. Occasionally on YSF/FCS mode across several versions of pi-star (4.1.2, 4.1.5, etc.) when I depress the Dx button to engage a connect to the home talkroom embedded in these mmdvm's config's, the jumbospots seem to get stuck into thinking I'm transmitting that I have DG-ID 127 selected, when I'm actually set to Auto DG-ID, that is "00".
When an mmdvm gets "stuck" this way, this has happened across multiple handhelds: more than one FT-70DR, and FT-1XDR, an FT-2DR, and an FT-3DR...plus mobile radios like a 100DR, 400XDR, and even a 7250DR. All of these radios work just fine 100% of the time with OTA Fusion repeaters and when working PDN with Yaesu's WiresX software.
When "stuck" in this rut, no connect occurs.
Don't get me wrong, though...a lot of wonderful work has gone into mmdvm's and pi-star, and I appreciate what this has done for the hams that have embraced using this digital voice mode. I'm sure it was a real engineering challenge to get WiresX Passthrough mode working as well as it does on these inexpensive platforms. But this issue is a real bugger when it occurs and I'd like to understand its genesis better.
I have been able to "unstick" some mmdvm's that have been resistant to connecting by rolling through the DG-ID choices, just simply rotating the knob or menu selection from Auto to 01 through 99 and back to Auto again. With connect attempts tried on these other DG-ID's a return to Auto (00) usually winds up in a connection, and it's solid. I can even power down the mmdvm and bring it back up a day or a week later and it doesn't give me the stuck at 127 "no connect error".
Sometimes, though, I initiate a connect request with a radio, and still see DG-ID 127 come up on the 0.9" monochrome screen momentarily and then it reverts to the correct DG-ID 00 to which my radio is set (Auto). A normal connect ensues and is solid.
To me this makes little technical sense. The "work around" stated above makes no sense to me either. But it sure does feel like the proverbial "race condition" or similar timing problem is occurring somewhere in pi-star or the mmdvm hardware. This is NOT limited to just the generic jumbospot mmdvm examples of product. I have a friend who has been using a ZumSpot for years on DMR and D*. Whenever he tried to use it on Fusion with his FT-2DR, that handheld would never connect to his ZumSpot. He always thought that it was his radio that was defective and taught him to hate Yaesu Fusion. Then I described the DG-ID 127 "no connect" issue to him that I have seen and he realized that this was exactly what his pi-star enabled ZumSpot was doing. He vindicated his radio with OTA testing in a WiresX environment.
It's also "fishy" to me that an invalid DG-ID of 127 is seven one's in binary, and exactly the inverse of Auto's DG-ID of zeroes.
Sorry about the wordiness of this posting, but it all boils down to:
1. Has anyone else experienced this phenomenon with DG-ID 127 "no connect" when its really Auto DG-ID of 00 that is running in the radio requesting the connect?
2. Has the reason this occurs been quantified? Is it a hardware or software race condition...or possibly...both?
3. Is there a fix or a foolproof workaround better than what I've described above?
Thank you for reading all of this. I would very much like to hear back from those in the pi-star community who have been deeper into the weeds than I have.
73,
Tony (W9MT)
Vail AZ USA
When an mmdvm gets "stuck" this way, this has happened across multiple handhelds: more than one FT-70DR, and FT-1XDR, an FT-2DR, and an FT-3DR...plus mobile radios like a 100DR, 400XDR, and even a 7250DR. All of these radios work just fine 100% of the time with OTA Fusion repeaters and when working PDN with Yaesu's WiresX software.
When "stuck" in this rut, no connect occurs.
Don't get me wrong, though...a lot of wonderful work has gone into mmdvm's and pi-star, and I appreciate what this has done for the hams that have embraced using this digital voice mode. I'm sure it was a real engineering challenge to get WiresX Passthrough mode working as well as it does on these inexpensive platforms. But this issue is a real bugger when it occurs and I'd like to understand its genesis better.
I have been able to "unstick" some mmdvm's that have been resistant to connecting by rolling through the DG-ID choices, just simply rotating the knob or menu selection from Auto to 01 through 99 and back to Auto again. With connect attempts tried on these other DG-ID's a return to Auto (00) usually winds up in a connection, and it's solid. I can even power down the mmdvm and bring it back up a day or a week later and it doesn't give me the stuck at 127 "no connect error".
Sometimes, though, I initiate a connect request with a radio, and still see DG-ID 127 come up on the 0.9" monochrome screen momentarily and then it reverts to the correct DG-ID 00 to which my radio is set (Auto). A normal connect ensues and is solid.
To me this makes little technical sense. The "work around" stated above makes no sense to me either. But it sure does feel like the proverbial "race condition" or similar timing problem is occurring somewhere in pi-star or the mmdvm hardware. This is NOT limited to just the generic jumbospot mmdvm examples of product. I have a friend who has been using a ZumSpot for years on DMR and D*. Whenever he tried to use it on Fusion with his FT-2DR, that handheld would never connect to his ZumSpot. He always thought that it was his radio that was defective and taught him to hate Yaesu Fusion. Then I described the DG-ID 127 "no connect" issue to him that I have seen and he realized that this was exactly what his pi-star enabled ZumSpot was doing. He vindicated his radio with OTA testing in a WiresX environment.
It's also "fishy" to me that an invalid DG-ID of 127 is seven one's in binary, and exactly the inverse of Auto's DG-ID of zeroes.
Sorry about the wordiness of this posting, but it all boils down to:
1. Has anyone else experienced this phenomenon with DG-ID 127 "no connect" when its really Auto DG-ID of 00 that is running in the radio requesting the connect?
2. Has the reason this occurs been quantified? Is it a hardware or software race condition...or possibly...both?
3. Is there a fix or a foolproof workaround better than what I've described above?
Thank you for reading all of this. I would very much like to hear back from those in the pi-star community who have been deeper into the weeds than I have.
73,
Tony (W9MT)
Vail AZ USA