DMR Slot 2, overflow in the DMR slot RF queue

Help with DMR issues
K3SZ
Posts: 5
Joined: Tue May 07, 2019 6:50 pm

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

Post 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]
Last edited by K3SZ on Fri Jan 27, 2023 3:53 pm, edited 1 time in total.
User avatar
G8SEZ
Posts: 553
Joined: Fri Apr 13, 2018 8:26 pm

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

Post 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.
--

Brian G8SEZ
KN2TOD
Posts: 264
Joined: Sun Nov 11, 2018 6:36 pm

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

Post 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.
AF6VN
Posts: 821
Joined: Fri Jul 20, 2018 1:15 am

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

Post 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).

--
AF6VN
Dennis L Bieber
KN2TOD
Posts: 264
Joined: Sun Nov 11, 2018 6:36 pm

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

Post 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?
Post Reply