n8qq
New Member
Posts: 6
|
Post by n8qq on May 9, 2018 5:53:06 GMT -8
Was just catching up on last week's net podcast and ran across W6KD's discussion about the VHF DVAP. Unfortunately, my VHF DVAP is still experiencing the FM tx lockup bug. The version of Pi-Star was last updated to 3.4.12 as recently as a week or two ago and it just happened again yesterday.
It has been connected to the ref006a reflector full-time for the last several months and the transmit gets locked on at least twice a week, sometimes more often. Whatever triggers the bug definitely occurs on ref006a with regularity, so you might want to give it a go there.
Now I wish I'd been watching it with more of mind toward troubleshooting, but the DVAP is the red-headed step child of my hotspot/access points and rarely gets much attention.
Brad N8QQ
|
|
|
Post by W6KD on May 10, 2018 18:33:12 GMT -8
Interesting. What version of RasPi are you running it with? I'm still going rock-solid 3+ weeks now with a RasPi 3 and the VHF DVAP, running PiStar 3.4.11
Most of my linked time with that system is on XRF720C and REF009C
Regards
|
|
n8qq
New Member
Posts: 6
|
Post by n8qq on May 11, 2018 8:36:58 GMT -8
It's a Pi Zero W.
Just moved it to a Pi 3 B and upgraded Pi-Star to current, and I'll see how it goes now.
Maybe I'll leave the id-51a's voice recorder on it and see which station is last heard before the lockup ... assuming it locks up again. Then again, I don't relish the thought of dusting off the ic-92ad heater-brick to use in the meantime. I am curious though...
|
|
n8qq
New Member
Posts: 6
|
Post by n8qq on May 14, 2018 8:16:18 GMT -8
After upgrading Pi-Star and moving it to a Pi 3 B Friday evening, tx was locked on again by Saturday afternoon.
I wonder if you might try sitting on ref006a for a few days or a week. I'm assuming that something in the data stream from some model(s) of radio or other device triggers the bug.
|
|
|
Post by W6KD on May 17, 2018 16:59:36 GMT -8
Are you using WiFi or wired ethernet to the Pi3? I'm using wired here.
Had mine on REF006A for a day or so...I did notice a lot of long-distance intercontinental connections, something I don't see often on XRF720 or REF009. Still, no lockup.
Also, what about power supply to the Pi? Mine's running off a 10-port Anker USB power brick, rated at 2.4A per port.
Conventional wisdom was always that some kind of incoming UDP stream anomaly is what triggers the issue.
Regards
Bob, W6KD
|
|
n8qq
New Member
Posts: 6
|
Post by n8qq on May 18, 2018 3:52:07 GMT -8
WiFi, both with the Pi 3's on-board wifi, and the usb wifi dongle with a Pi 2. Currently on a 5-port Anker USB brick with 2.4A per port.
It used to happen regularly via wired ethernet on various DStarRepeater/ircDDBGateway images before Pi-Star, with a generic ~2.5A wall power supply. Usually on ref001c.
I have to think somebody has already done some kind of actual troubleshooting on this but I can't find any mention of it via google. Maybe I'm not be hitting the right search terms. I know I found something about it once a couple years ago when first noticing it, but I don't recall it being any kind of technical discussion.
My inclination is to connect it to something with high and varied traffic like REF001C and then use the ID-51a Plus QSO recorder to figure out when the tx lockup occurs - and then figure out what triggered it by looking at the next station on the Pi-Star dashboard. And then follow up with that station in email to see what they're using, or look for other clues ... or something like that. But without really digging into the DStarRepeater/ircDDBGateway code and troubleshooting at that level, this all seems a bit superficial. I don't want waste the time if somebody has already ruled these things out.
Do you think there's any value in doing that? If so, maybe I'll do that and write up a summary of some findings.
Brad N8QQ
|
|
K2IE
New Member
Posts: 1
|
Post by K2IE on Jun 21, 2018 8:02:50 GMT -8
I first reported this issue to DL5DI via github as issue #117 on Jan 17, 2017. It seems to happen after a couple of hours on a busy reflector such as REF001C. It does not appear that the underlying issue has been investigated. When using the Dutch Star condv software, the DVAP is completely reliable. github.com/dl5di/OpenDV/issues/117
|
|