forum.pistar.uk

Pi-Star User Forum
https://forum.pistar.uk/

DMR Slot 2, overflow in the DMR slot RF queue

https://forum.pistar.uk/viewtopic.php?t=4138

Page 2 of 2

Re: DMR Slot 2, overflow in the DMR slot RF queue

Posted: Sun Jan 22, 2023 4:58 pm
by K3SZ
When N5BOC received one of the boards back, he mentioned it was a "sick puppy", so I would think that if my PSU voltage was low, so was his when he was testing it. I know a few of my 5V USB supplies get complaints when powering Raspberry Pi boards and in all cases I do use an add-on and inline power switch which may have a slight voltage drop -- but I have not confirmed this.

I have provided a link to a JPEG showing the screenshot of my live log when this problem was occurring on the first board, as well as some oscilloscope pictures showing the TCXO output before the coupling cap and two pictures after the cap -- one from each board. One sort of worked, the other not at all. The live log is from the one that sort of worked. The last picture shows the ADF7021 IC and the cap I was probing with the oscilloscope.

https://i.imgur.com/cr1D0zK.jpeg

[Post updated: 27-JAN-2023]

Re: DMR Slot 2, overflow in the DMR slot RF queue

Posted: Sun Jan 22, 2023 5:14 pm
by G8SEZ
It's always a good idea to ensure that your PSU can supply more current than the Pi needs, sometimes they can try to draw a spike of current and brown themselves out if the PSU rating is marginal.

Re: DMR Slot 2, overflow in the DMR slot RF queue

Posted: Sun Jan 22, 2023 7:19 pm
by KN2TOD
I'm thinking more along the lines of voltage sags, not brownouts, not uncommon around here, given the condition of our power lines. Not sure I would notice them much unless the lights flicker; would need to put a long-term power monitor up to verify but who has one of those just laying around? ;)

Most of my overflows seem to occur during late night and early morning hours, seemingly (conjecture on my part) occurring when some surrounding businesses fire up some of their processes. (Good time to charge up one's fleet of trucks?!)

As someone noted earlier: food for thought. Back to more monitoring and correlating data. Again, thanks for your thoughts.

Re: DMR Slot 2, overflow in the DMR slot RF queue

Posted: Tue Jan 24, 2023 4:47 pm
by AF6VN
If you have a spare power outlet on a UPS, you might try that to see if if moderates any voltage variation from the main lines.

Back around 1977/78, my college /mainframe/ tended to crash around 8AM each day, and had to be rebooted.

They finally tracked it down to the college PBS station (located in the same building) powering up for the day. They put in a large "motor/generator" to smooth out the spike (as I recall, an electric motor powered by main lines, large flywheel in the middle, connected to a generator -- the flywheel is what kept the speed smooth through power drain on the mains; pretty certain it wasn't a gas powered motor).

Re: DMR Slot 2, overflow in the DMR slot RF queue

Posted: Sat Feb 04, 2023 3:07 am
by KN2TOD
Well, I'm still unsure of the power fluctuations as a cause, mainly because I haven't been able to correlate to external sources of such fluctuations.

What I do see, on occasion, is nevertheless strange: here's an example:

Code: Select all

       :                :                 :                 :
M: 2023-02-03 14:13:14.088 DMR Slot 1, received network voice header from N0VZC to TG 31990
E: 2023-02-03 14:13:14.464 DMR Slot 1, overflow in the DMR slot RF queue
       :                :                 :                 :
E: 2023-02-03 14:13:14.464 DMR Slot 1, overflow in the DMR slot RF queue
M: 2023-02-03 14:13:14.464 DMR Slot 1, received network end of voice transmission from N0VZC to TG 31990, 8.5 seconds, 0% packet loss, BER: 0.0%

M: 2023-02-03 14:13:19.114 DMR Slot 1, received network voice header from N0VZC to TG 31990
M: 2023-02-03 14:14:03.178 DMR Slot 1, received network end of voice transmission from N0VZC to TG 31990, 44.3 seconds, 0% packet loss, BER: 0.0%

M: 2023-02-03 14:14:08.018 DMR Slot 1, received network voice header from N0VZC to TG 31990
M: 2023-02-03 14:14:35.373 DMR Slot 1, received network end of voice transmission from N0VZC to TG 31990, 27.7 seconds, 0% packet loss, BER: 0.0%

M: 2023-02-03 14:14:46.295 DMR Slot 1, received network voice header from N0VZC to TG 31990
M: 2023-02-03 14:14:47.609 DMR Slot 1, received network end of voice transmission from N0VZC to TG 31990, 1.6 seconds, 0% packet loss, BER: 0.0%

M: 2023-02-03 14:14:58.193 DMR Slot 1, received network voice header from N0VZC to TG 31990
M: 2023-02-03 14:15:05.427 DMR Slot 1, received network end of voice transmission from N0VZC to TG 31990, 7.5 seconds, 0% packet loss, BER: 0.0%

M: 2023-02-03 14:15:10.229 DMR Slot 1, received network voice header from N0VZC to TG 31990
M: 2023-02-03 14:15:10.707 DMR Talker Alias (Data Format 3, Received 3/10 char): 'N0V'
M: 2023-02-03 14:15:11.391 DMR Talker Alias (Data Format 3, Received 6/10 char): 'N0VZC '
M: 2023-02-03 14:15:12.127 DMR Talker Alias (Data Format 3, Received 10/10 char): 'N0VZC Mike'
M: 2023-02-03 14:15:24.906 DMR Slot 1, received network end of voice transmission from N0VZC to TG 31990, 14.9 seconds, 0% packet loss, BER: 0.0%

M: 2023-02-03 14:15:28.908 DMR Slot 1, received network voice header from N0VZC to TG 31990
M: 2023-02-03 14:16:09.139 DMR Slot 1, received network end of voice transmission from N0VZC to TG 31990, 40.5 seconds, 0% packet loss, BER: 0.0%

M: 2023-02-03 14:16:11.754 DMR Slot 1, received network voice header from N0VZC to TG 31990
M: 2023-02-03 14:16:51.206 DMR Slot 1, received network end of voice transmission from N0VZC to TG 31990, 39.7 seconds, 0% packet loss, BER: 0.0%

M: 2023-02-03 14:16:58.261 DMR Slot 1, received network voice header from N0VZC to TG 31990
M: 2023-02-03 14:17:29.096 DMR Slot 1, received network end of voice transmission from N0VZC to TG 31990, 31.4 seconds, 5% packet loss, BER: 0.0%

M: 2023-02-03 14:17:45.649 DMR Slot 1, received network voice header from N0VZC to TG 31990
E: 2023-02-03 14:18:27.761 DMR Slot 1, overflow in the DMR slot RF queue
       :                :                 :                 :
E: 2023-02-03 14:18:27.761 DMR Slot 1, overflow in the DMR slot RF queue
E: 2023-02-03 14:18:27.762 DMR Slot 1, overflow in the DMR slot RF queue
       :                :                 :                 :
E: 2023-02-03 14:18:27.762 DMR Slot 1, overflow in the DMR slot RF queue
E: 2023-02-03 14:18:27.762 DMR Slot 1, overflow in the DMR slot RF queue
M: 2023-02-03 14:18:27.762 DMR Slot 1, received network end of voice transmission from N0VZC to TG 31990, 51.7 seconds, 0% packet loss, BER: 0.0%

M: 2023-02-03 14:18:31.985 DMR Slot 1, received network voice header from N0VZC to TG 31990
       :                :                 :                 :
A series of transmissions (QSO's), except:

1) for those QSO's that log an overflow, the timings (length of the QSO) don't add up, start-to-end. The rest do.
2) not all QSO's log Alias Talker info, even though they're all from the same ID. (Presumably they are all from the same radio).

What it looks like is that the Alias Talker data is either 1) being logged as expected, or 2) being dropped all together, or 3) getting garbled and logged as overflows. Perhaps the route each QSO takes through the network is effecting the outcomes here. The intermittent overflows/talker data and possible routing variations: are they related?

Any thoughts, gentlemen?
All times are UTC
Page 2 of 2

Powered by phpBB® Forum Software © phpBB Limited