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
ysf/fcs doesn't connect. DG-ID shows 127 instead of 0.
Re: ysf/fcs doesn't connect. DG-ID shows 127 instead of 0.
Ok, if this helps...here's another clue...
Today I was "playing radio" with my 3rd Gen iPhoneSE with personal hotspot switched on and Maximize Compatibility enabled to better handle the minimalistic WiFi interface in my 4.1.5 load. My mmdvm hardware is a Chinese gpio hat board with 0.96" monochrome display along with a pi-zeroW board version 1.1.
After waiting for the mmdvm to link to the iPhoneSE's cellular data connection (strong 5G signal), I attempted nearly a dozen times to connect to America KC Wide (YSF 32453) whilst I awaited my wife to come out of her physical therapy appointment. Upon each such attempt the FT-2DR's receiver remained silent and the display showed the now dreaded DG-ID 127 error. The radio was set to DG-ID 0.
On one more boot up attempt for the mmdvm, there was activity on America KC Wide's YSF 32453 talkroom and when the mmdvm woke up audio blasted from the FT-2DR's speaker and DG-ID 0 showed up in the display. I worked a station in a QSO after the current activity had ended.
This begs the question...why couldn't I connect with the correctly selected DG-ID of zero until channel activity correctly configured the mmdvm that way with active receive on the YSF talkroom selection?
To me this smells suspiciously of some register not being initialized correctly in the mmdvm hardware on the "local side", but gets properly set on the "network side" when the mmdvm wakes up with the channel already busy...and works fine until powered down. It seems to be a crapshoot whether it will work again on the next cold power up...or whether DG-ID 127 will silence the mmdvm again until channel activity fixes things.
This is weird.
Anybody? Any ideas for a fix or a workaround? It is likewise a crapshoot that the channel will be busy when my mmdvm wakes up.
Today I was "playing radio" with my 3rd Gen iPhoneSE with personal hotspot switched on and Maximize Compatibility enabled to better handle the minimalistic WiFi interface in my 4.1.5 load. My mmdvm hardware is a Chinese gpio hat board with 0.96" monochrome display along with a pi-zeroW board version 1.1.
After waiting for the mmdvm to link to the iPhoneSE's cellular data connection (strong 5G signal), I attempted nearly a dozen times to connect to America KC Wide (YSF 32453) whilst I awaited my wife to come out of her physical therapy appointment. Upon each such attempt the FT-2DR's receiver remained silent and the display showed the now dreaded DG-ID 127 error. The radio was set to DG-ID 0.
On one more boot up attempt for the mmdvm, there was activity on America KC Wide's YSF 32453 talkroom and when the mmdvm woke up audio blasted from the FT-2DR's speaker and DG-ID 0 showed up in the display. I worked a station in a QSO after the current activity had ended.
This begs the question...why couldn't I connect with the correctly selected DG-ID of zero until channel activity correctly configured the mmdvm that way with active receive on the YSF talkroom selection?
To me this smells suspiciously of some register not being initialized correctly in the mmdvm hardware on the "local side", but gets properly set on the "network side" when the mmdvm wakes up with the channel already busy...and works fine until powered down. It seems to be a crapshoot whether it will work again on the next cold power up...or whether DG-ID 127 will silence the mmdvm again until channel activity fixes things.
This is weird.
Anybody? Any ideas for a fix or a workaround? It is likewise a crapshoot that the channel will be busy when my mmdvm wakes up.
Re: ysf/fcs doesn't connect. DG-ID shows 127 instead of 0.
Hi.
DGID 127 is not an error code. When the radio (not hotspot) transmits the WiresX handshake request - which you initiate by holding down the Dx button - the radio truly does transmit DGID127. 127 is a special case, just for this handshake. IF the hotspot acknowledges, it will typically come back with DGID0.
Sometimes the hotspot will NOT acknowledge - since the wiresX handshake is a brief transmission. This can be due to the hotspot not fully listening, being in another mode, taking a second to configure to listen to YSF mode, etc. You may have better luck if you key the PTT for a couple of seconds to get the hotspot into YSF mode so it is ready to hear and acknowledge the wiresX handshake.
If you are joining a net using YSF gateway, the hotspot should transmit whatever DGID the other party is sending. Keep your radio on DGID0 to hear all callers. Conversely if you are using DGIDgateway, the remote caller DGID gets changed when the hotspot transmits, per your DGIDgateway mapping.
DGID 127 is not an error code. When the radio (not hotspot) transmits the WiresX handshake request - which you initiate by holding down the Dx button - the radio truly does transmit DGID127. 127 is a special case, just for this handshake. IF the hotspot acknowledges, it will typically come back with DGID0.
Sometimes the hotspot will NOT acknowledge - since the wiresX handshake is a brief transmission. This can be due to the hotspot not fully listening, being in another mode, taking a second to configure to listen to YSF mode, etc. You may have better luck if you key the PTT for a couple of seconds to get the hotspot into YSF mode so it is ready to hear and acknowledge the wiresX handshake.
If you are joining a net using YSF gateway, the hotspot should transmit whatever DGID the other party is sending. Keep your radio on DGID0 to hear all callers. Conversely if you are using DGIDgateway, the remote caller DGID gets changed when the hotspot transmits, per your DGIDgateway mapping.
Re: ysf/fcs doesn't connect. DG-ID shows 127 instead of 0.
Thank you for your reply. I was getting worried that me and my friend with the ZumSpot were the only ones with this anomaly.
I did not know that a Fusion radio in DN mode actually transmitted dg-id 127 when trying to initiate a wires-x style connect. I was under the assumption that if the radio was set to Auto or hard set to dg-id 0 on both transmit and receive, that zero was the transmitted and replied dg-id code. But when my YSF mmdvm is not "falsing" this way, I do see it say dg-id momentarily after the first connect request and settles nicely into returning a dg-id 0 afterward and stays that way on zero. So what you are saying makes a lot of sense.
My mmdvm's used on YSF/FCS are not set to multi-digital mode functionality. These devices are always be dedicated to only YSF/FCS. The one or two I use for D* are dedicated to that mode only, and the one for DMR is also only for DMR. In addition to that I use widely spaced simplex frequencies for each of these 3 modes in the 430/440 band for good frequency diversity so as each of the 3 mmdvm's, each running only one of these 3 modes within the same locale do not desense each other. So this concern you voiced should not be coming into play. The mode that should be heard by my YSF mmdvm's will also always be DN.
I've heard the horror stories of pi-zeroW's not being very quick on the trigger to switch modes if they are too busy scanning for validly decoded data in order to select one digital voice mode and stay with that mode whilst activity continues for that mode. Even the version 1.1 of the pi-zeroW is not too powerful to not get busied out with a lot of house-keeping and is likely to miss the required synchronization. The source of the consistent false decode to be returning dg-id 127 and its being stuck on that is likely due to that shortness of the decode. It did smell like some sort of race condition where pi-star was getting hosed or confused and not initializing the connection request properly.
I'll give your recommendation to key the PTT on my Fusion handheld for several seconds prior to trying for a connect the next time I "play radio" with my Fusion HT's, mmdvm, and iPhoneSE when I'm sitting in another parking lot with time on my hands.
Thanks for your most helpful input and information. I hope this work around is really that simple and also a solid fix.
73, Tony (W9MT)
I did not know that a Fusion radio in DN mode actually transmitted dg-id 127 when trying to initiate a wires-x style connect. I was under the assumption that if the radio was set to Auto or hard set to dg-id 0 on both transmit and receive, that zero was the transmitted and replied dg-id code. But when my YSF mmdvm is not "falsing" this way, I do see it say dg-id momentarily after the first connect request and settles nicely into returning a dg-id 0 afterward and stays that way on zero. So what you are saying makes a lot of sense.
My mmdvm's used on YSF/FCS are not set to multi-digital mode functionality. These devices are always be dedicated to only YSF/FCS. The one or two I use for D* are dedicated to that mode only, and the one for DMR is also only for DMR. In addition to that I use widely spaced simplex frequencies for each of these 3 modes in the 430/440 band for good frequency diversity so as each of the 3 mmdvm's, each running only one of these 3 modes within the same locale do not desense each other. So this concern you voiced should not be coming into play. The mode that should be heard by my YSF mmdvm's will also always be DN.
I've heard the horror stories of pi-zeroW's not being very quick on the trigger to switch modes if they are too busy scanning for validly decoded data in order to select one digital voice mode and stay with that mode whilst activity continues for that mode. Even the version 1.1 of the pi-zeroW is not too powerful to not get busied out with a lot of house-keeping and is likely to miss the required synchronization. The source of the consistent false decode to be returning dg-id 127 and its being stuck on that is likely due to that shortness of the decode. It did smell like some sort of race condition where pi-star was getting hosed or confused and not initializing the connection request properly.
I'll give your recommendation to key the PTT on my Fusion handheld for several seconds prior to trying for a connect the next time I "play radio" with my Fusion HT's, mmdvm, and iPhoneSE when I'm sitting in another parking lot with time on my hands.
Thanks for your most helpful input and information. I hope this work around is really that simple and also a solid fix.
73, Tony (W9MT)
Re: ysf/fcs doesn't connect. DG-ID shows 127 instead of 0.
I'm having the same issue, see my post today re: FTM-400 not connecting. Hotspot sees the DG-ID 127 but doesn't respond (did yesterday when first set up YSF and YSF2DRM).