YSF problems after last Pistar upgrades v.4.1.7 – 4.1.8

[IW4EHJ]

I tried but it doesn't work, the problem remains.

For now the only solution is to work around the problem with the temporary solution that has been identified.

[VK5FR]

I was alerted to this thread by a fellow VK helping me troubleshoot why my FT5D no longer would connect to the Duraspot 2.
I have exactly the same issues and am using the work around from the post by IK4SWW...thank you.

I hope they can address this issue and free me from 'Apply Changes' each start up.

Thanks for the tread.

73
Chris
VK5FR

[IW4EHJ]

Unfortunately the problem has not yet been resolved, we are waiting for it to be resolved.

While waiting for the solution, we made a change to the Pi-Star startup by forcing a restart of YSFGateway after 180 seconds from system startup by adding this line in the crontab:

@reboot sleep 180 && sudo systemctl restart ysfgateway.service

This way you avoid having to do everything manually, but I recommend removing the string once the YSF problem is resolved, in order to return to a clean boot or if you want to try to see if the problem is resolved after an update, just comment the string with # to disable the restart command momentarily.

For now this solution works or by using the SSH Button application for Android or similar you can give the command from a smartphone without having to enter the Pi-Star, this can be a solution to not change anything in the crontab and in any case very simple to do.

[MW0MWZ]

@reboot sleep 180 && sudo systemctl restart ysfgateway.service

If this turns out to JUST require YSFGateway to wait longer before startup, you can edit /lib/systemd/system/ysfgateway.timer and set the timer to a longer value.

I'd love to get some logs for YSFGateway from a fresh reboot to see if there is an obvious problem, or maybe from MMDVMHost to see if that is not able to talk to the YSF daemon or somthing - my issue, is of course, all of my hardware is working and not showing this issue.

[IW4EHJ]

I will also do this test, however from the logs it seems that MMDVMHost works regularly in the log I see all the steps and by doing a test on the ports I see the passage from the MMDVM port towards YSFGATEWAY but I do not get any response from the gateway when it blocks it no longer accepts anything from MMDVM and therefore you don't go to the network and you don't get any response if you try to do Wires-X, but once YSF is restarted everything is active again.

I tried to put the restart command at 120 seconds but it doesn't work because if I restart YSF when it works I have no effect so I have to wait for YSF to block and give the restart command so I put it at 180 seconds and it still works I will try to lengthen the delay and see if the problem arises! For logs it's not a problem I can send you the test via email without modifying crontab.

[IW4EHJ]

@reboot sleep 180 && sudo systemctl restart ysfgateway.service

If this turns out to JUST require YSFGateway to wait longer before startup, you can edit /lib/systemd/system/ysfgateway.timer and set the timer to a longer value.

I tested this solution but it has no effect. For now the only way is to restart the gateway.

[IW4EHJ]

After new tests and attempts we realized that the problem comes from the start of the dgidgateway which conflicts with ysfgateway so we tried to change the communication port in the dgidgateway configuration file so that it no longer communicates with ysfgateway and in this way it seems everything works or in any case it doesn't stop me anymore.

[W8NIN]

Additional info:

One one hotspot (MMDVM (GPIO) + Pi 3B) , I use the YSF parrot and I can key up, transmit, but get no audio on the transmission back from the parrot.

The other hotspot (MMDVM (GPIO) + Pi Zero 2 W) for some reason with what I think are the same settings, works fine with the YSF parrot and TGIF DMR boards. I was on a YSF Net today with this hotspot (irn.radio multimode net) and it worked initially, but I was not heard on subsequent transmissions. But now it is working fine on YSF2DMR TGIF TG 2021.

Looks like I'll use my DMR radio for a bit.

Regards,

W8NIN

[W8NIN]

Disregard the above.....this was user error induced. New code seems to be working correctly.

W8NIN

[W8DSB]

@andy, will there be a 4.1.9? I know 4.20 is out but for us with repeaters that have limited access I cannot just walk in and swap cards. I am hoping for a fix to the current version or a way to remote update 4.1.8 to 4.20