Hello,
I just added a duplexer and additional radio to my pi-star/RB-STM32 d-star hotspot and changed the mode to Duplex. Everything seems to be working as it should except for one quirk. If the hotspot sits for 5 mins (almost exactly), the first transmission doesn't pass the audio to the reflector OR the transmit radio. After that everything is fine as long as there isn't more than a 5 min idle time. I can see that the audio is received, but it doesn't forward it on.
Live Logs
Starting logging, please wait...
M: 2022-12-04 14:55:01.585 D-Star, received RF header from KK7BYQ /BGFK to CQCQCQ
M: 2022-12-04 14:55:04.190 D-Star, received RF end of transmission from KK7BYQ /BGFK to CQCQCQ , 2.6 seconds, BER: 0.0%, RSSI: -43/-43/-43 dBm
To put it another way I have to kerchunk the repeater to get it to start passing audio.
Update: I took this back to a simplex hotspot and it is doing it there now two. One thing that happened when I updated the configs to duplex it blanked out the modem and gave me a warning that my modem changed (which it hadn't) and that I had to re-select it from the list. Starting to suspect it is a modem driver issue
Any suggestions?
Byron
Pi-Star Transmit Falls Asleep After 5 mins in Duplex
Re: Pi-Star Transmit Falls Asleep After 5 mins in Duplex
The server is set to time out after 5mins. Log into your selfcare acc. Look at the sysop section (providing its a repeater, else itll be listed under hotspots) and set the TG's your interested in as static, so keeping them connected.
A simplex hotspot holds the tg semi static, a duplex hotspot is seen as a rptr and they get treated differently dependant on the server ur connecting with.
When you swap between duplex and simplex setup pistar expects a change of modem type, so don't panic in it asking for the modem type agn.
Sent via smoke signals from my SM-G935F M1DNS (Admin)
A simplex hotspot holds the tg semi static, a duplex hotspot is seen as a rptr and they get treated differently dependant on the server ur connecting with.
When you swap between duplex and simplex setup pistar expects a change of modem type, so don't panic in it asking for the modem type agn.
Sent via smoke signals from my SM-G935F M1DNS (Admin)
Andrew M1DNS.
Pi-star Admin Team.
Pi-star Admin Team.
Re: Pi-Star Transmit Falls Asleep After 5 mins in Duplex
Pardon, but this thread is in the D-STAR group, not DMR -- no "TG" to set static.
--
AF6VN
Dennis L Bieber
Re: Pi-Star Transmit Falls Asleep After 5 mins in Duplex
My bad...AF6VN wrote:
Pardon, but this thread is in the D-STAR group, not DMR -- no "TG" to set static.
I guess I Shouldnt go answering posts in the early hrs of the mornings.
Ignore everything I've written in my answer above regards TG's, servers and time outs.
Sent via smoke signals from my SM-G935F M1DNS (Admin)
Andrew M1DNS.
Pi-star Admin Team.
Pi-star Admin Team.
Re: Pi-Star Transmit Falls Asleep After 5 mins in Duplex
Update to this in case anyone else has the issue. I played with a number of settings to see what affect they had. I was sure a 10 min hang time would delay the problem for 10 mins but it didn't do anything. Pi-star would fail to rout the audio to the reflector and the TX radio after 5 mins just like before.
Strangely enough I turned on Time Announcements and the issue went away, not just for the 5 mins after the announcement but entirely. I left the announcements on the hour (instead of every 15 or 30 mins) and it seems to be fixed. As a test I turned them off and the problem immediately returned. If I knew more about how pi-star routed the traffic I might be able to find a setting deep in the config that affects this but I'm done playing with it. I'm sure if I created a fresh pi-star install the problem would resolve as well. I'll post an update if I do that.
Strangely enough I turned on Time Announcements and the issue went away, not just for the 5 mins after the announcement but entirely. I left the announcements on the hour (instead of every 15 or 30 mins) and it seems to be fixed. As a test I turned them off and the problem immediately returned. If I knew more about how pi-star routed the traffic I might be able to find a setting deep in the config that affects this but I'm done playing with it. I'm sure if I created a fresh pi-star install the problem would resolve as well. I'll post an update if I do that.
Re: Pi-Star Transmit Falls Asleep After 5 mins in Duplex
Hang time is pretty much meaningless if one is only using ONE MODE on the device.KK7BYQ wrote: ↑Thu Dec 08, 2022 2:27 pm Update to this in case anyone else has the issue. I played with a number of settings to see what affect they had. I was sure a 10 min hang time would delay the problem for 10 mins but it didn't do anything. Pi-star would fail to rout the audio to the reflector and the TX radio after 5 mins just like before.
It controls how long Pi-Star stays in "listening <mode>" before going to just "listening" (which means it is now scanning for traffic in all activated protocols).
--
AF6VN
Dennis L Bieber
Re: Pi-Star Transmit Falls Asleep After 5 mins in Duplex
Ok I couldn't let it go I found an old config and did a compare on the configs. (don't know why I didn't think of doing this sooner) I found that the gatewayType had changed from 1 to 0 in the expert config. A little research show that the settings for that value are as follows
0 repeater, 1 hotspot, 2 dongle, 3 starnet
I flipped it back to 1, turned the time server off and sure enough problem solved! I am certain I didn't change that value and in fact applying changes in the main configuration screen sets that back to 0. It seems that pi-star really wants the gatewayType set to repeater if the controller mode is Duplex. Maybe the duplex setting with a full stm32 board attached is the key? It's hard for me to believe that duplex hotspots have this issue.
Hopefully someone can guide me to why the gatewayType gets reset, or I will have to leave timeserver on and / or make sure to reset the gatewaytype anytime I make changes to the config.
Pro tip its good to download the configs once in awhile for reference when making changes.
Thanks,
Byron KK7BYQ
0 repeater, 1 hotspot, 2 dongle, 3 starnet
I flipped it back to 1, turned the time server off and sure enough problem solved! I am certain I didn't change that value and in fact applying changes in the main configuration screen sets that back to 0. It seems that pi-star really wants the gatewayType set to repeater if the controller mode is Duplex. Maybe the duplex setting with a full stm32 board attached is the key? It's hard for me to believe that duplex hotspots have this issue.
Hopefully someone can guide me to why the gatewayType gets reset, or I will have to leave timeserver on and / or make sure to reset the gatewaytype anytime I make changes to the config.
Pro tip its good to download the configs once in awhile for reference when making changes.
Thanks,
Byron KK7BYQ
Re: Pi-Star Transmit Falls Asleep After 5 mins in Duplex
Essentially: once you make a change using the "expert" configuration, you must make ALL future changes using the "expert" menu.
--
AF6VN
Dennis L Bieber
Re: Pi-Star Transmit Falls Asleep After 5 mins in Duplex
Finally figured this issue out and can now reproduce it at will. It wasn't the gateway type, and it wasn't my transition to duplex. In a nutshell if network traffic comes in shortly after an RF transmission the rftime timer will continue running and timeout (behind the scenes), which prevents the next transmission. Steps to reproduce are in the github issue.
https://github.com/g4klx/MMDVMHost/issues/756
Because of the order in which things must happen, it is sort of a rare event. But I think it is happening more than people realize, especially during net check-ins. I was doing my testing on REF55E (echo reflector) which sort of highlighted the problem because the echo reflector responds so quickly. (under 250ms). I don't remember having the problem on 55E a year ago when I was doing my initial testing. Maybe that reflector has had an upgrade and responds quicker now.
https://github.com/g4klx/MMDVMHost/issues/756
Because of the order in which things must happen, it is sort of a rare event. But I think it is happening more than people realize, especially during net check-ins. I was doing my testing on REF55E (echo reflector) which sort of highlighted the problem because the echo reflector responds so quickly. (under 250ms). I don't remember having the problem on 55E a year ago when I was doing my initial testing. Maybe that reflector has had an upgrade and responds quicker now.