Out of range CC code indicated

User avatar
DG1GMY
Posts: 30
Joined: Fri Oct 01, 2021 3:54 pm
Location: Southern Germany

Out of range CC code indicated

Post by DG1GMY » Fri Nov 11, 2022 5:08 pm

"OpenRD5R auto switching to C19 during QSO"

I just came across a "new behaviour" on one of my RD5Rs today, running the latest beta (2022-11-02). TRX was standby via one of my dual slot MMDVMs with a few low frequented TGs subscribed on both slots.

After a QSO on one of the TGs started the C1 jumped to C19 on the display and QSO therefore was muted. CC Scan was set to "OFF". Only option to come back to C1 was a channel change or i.e. switch to FM-VFO and go back to DMR (or switch off the TRX for a moment). Yet within a few seconds (with the next QSO handover the latest) the C19 came back and the whole process needed to be redone. Trapped in a loop.

If CC Scan is set to "ON" the device seems to also go & stay on C19 but detects the correct C1 and let's the audio pass through accordingly. Yet within seconds the CC here goes back to C19 as well and audio is muted again. The loop continues.

Such "auto switching" does not happen all of the time. Yet it may happen and then persist for a while.

Not sure if this is more related to TRX <-> MMDVM sync issues or due to other reasons (it's not a new setup).

Also wonder why especially "C19"? :roll:

Any hint welcome!

G4EML
Posts: 919
Joined: Sat Nov 16, 2019 10:01 am

Re: New Beta version 2022 11 02

Post by G4EML » Fri Nov 11, 2022 9:13 pm

That's very strange behaviour. When you are not using CC Scan the colour code should never change. Also if you are really seeing C19 then it is an invalid value. CC can only be 0 to 15 because it is only 4 bits long.

It sounds like the CC value in memory is being corrupted by something. If it is a memory overwrite from elsewhere in the code it could be very difficult to find the cause. It really needs as much information gathered as possible.

You say it was on one of your RD5Rs, does it only happen on one of them?
Does it only happen when listening to a hotspot?

Colin G4EML

User avatar
DG1GMY
Posts: 30
Joined: Fri Oct 01, 2021 3:54 pm
Location: Southern Germany

Re: New Beta version 2022 11 02

Post by DG1GMY » Fri Nov 18, 2022 5:19 pm

G4EML wrote:
Fri Nov 11, 2022 9:13 pm
That's very strange behaviour.
[...]
Colin, thanks for getting back on this. Strange indeed! I am aware on valid 0-15 CC range, that's why I was wondering that "C19" even came up. I didn't have time for further tests since and unfortunately missed to create some footage when this occured. Also assumed some memory curruption and therefore reflashed/reprogrammed the device last week (and will load 2022-11-18 beta in a few seconds...). Let's see if it's coming back!

Yet I also remember something similar on my other RD5R (or maybe it was the GD77?) some months ago, so clearly on older FW. If I remember correctly all occurences where when listening to a 6-digit TG (i.e. DMR repeater's own ID as local TG). I use both RD5Rs 99,9% with my various hotspots, yet tried to reproduce the "C19" on a nearby "regular repeater" end of last week before reflashing. It did not come up again within a few hours of testing. Unclear if it might happen there as well over a longer period of time...

I only reported the "C19" to have this captured here - in case someone else may come across something similar...

Will proceed with testing the latest beta FW and provide additional insights as/if they occur...

Thanks again!
–Michael

VK3KYY
Posts: 7478
Joined: Sat Nov 16, 2019 3:25 am
Location: Melbourne, Australia

Re: New Beta version 2022 11 02

Post by VK3KYY » Fri Nov 18, 2022 6:37 pm

DG1GMY wrote:
Fri Nov 18, 2022 5:19 pm
G4EML wrote:
Fri Nov 11, 2022 9:13 pm
That's very strange behaviour.
[...]
Colin, thanks for getting back on this. Strange indeed! I am aware on valid 0-15 CC range, that's why I was wondering that "C19" even came up. I didn't have time for further tests since and unfortunately missed to create some footage when this occured. Also assumed some memory curruption and therefore reflashed/reprogrammed the device last week (and will load 2022-11-18 beta in a few seconds...). Let's see if it's coming back!

Yet I also remember something similar on my other RD5R (or maybe it was the GD77?) some months ago, so clearly on older FW. If I remember correctly all occurences where when listening to a 6-digit TG (i.e. DMR repeater's own ID as local TG). I use both RD5Rs 99,9% with my various hotspots, yet tried to reproduce the "C19" on a nearby "regular repeater" end of last week before reflashing. It did not come up again within a few hours of testing. Unclear if it might happen there as well over a longer period of time...

I only reported the "C19" to have this captured here - in case someone else may come across something similar...

Will proceed with testing the latest beta FW and provide additional insights as/if they occur...

Thanks again!
–Michael
I had a look at the code as well, and I can't see anything obvious which would cause this.

User avatar
DG1GMY
Posts: 30
Joined: Fri Oct 01, 2021 3:54 pm
Location: Southern Germany

Re: New Beta version 2022 11 02

Post by DG1GMY » Fri Nov 18, 2022 6:54 pm

VK3KYY wrote:
Fri Nov 18, 2022 6:37 pm
I had a look at the code as well, and I can't see anything obvious which would cause this.
Thanks Roger. I'll keep trying to reproduce - and I won't be unhappy if I fail ;)

VK3KYY
Posts: 7478
Joined: Sat Nov 16, 2019 3:25 am
Location: Melbourne, Australia

Re: New Beta version 2022 11 02

Post by VK3KYY » Fri Nov 18, 2022 7:32 pm

DG1GMY wrote:
Fri Nov 18, 2022 6:54 pm
VK3KYY wrote:
Fri Nov 18, 2022 6:37 pm
I had a look at the code as well, and I can't see anything obvious which would cause this.
Thanks Roger. I'll keep trying to reproduce - and I won't be unhappy if I fail ;)
LOL

OK.

I had look to see if I could find anything in the code which would cause this.

Mostly the variable is checked for values, and limited to only 0 - 15, but there are a few places in the code where the value is not checked.
This is becuse the checking is always on when the CC value is set.

So if, in theory, it can't be set to a value outside 0 - 15, then there should be no need to check when displaying the value, etc, that it is in range.

But the firmware is very complex, and runings a pre-emptive multi-tasking operating system, as well as having interrupt service routines. So sometimes unexpected things can happen becuase of strange alignments of timings

User avatar
DG1GMY
Posts: 30
Joined: Fri Oct 01, 2021 3:54 pm
Location: Southern Germany

Re: Out of range CC code indicated

Post by DG1GMY » Wed Dec 28, 2022 5:56 pm

Hi Roger, Colin – and everyone else reading here ;)

Hope you all had a great Christmas season! Thanks again for all your posts to clarify on potential cause...

The above described bug showed up again in recent days… This time I had the camera ready, so I am following up with some muted video footage as per below link.

https://cloud.dg1gmy.de/index.php/s/BqR3AnoASwzRARa

I have two RD-5R and both are showing the same strange behavior (yet not necessarily replicable on both devices at the same time). Both TRX are usually on latest beta FW (currently Nov 29). CC shown seems to be a random number outside of the defined range (C19, C31).

I could not reproduce the behavior on my other OpenXXX devices so far, so this seems to be “dedicated” to the RD-5R.

As noted in prior posts this is NOT a behavior that only started with latest beta version. I already came across this phenomenon >6-9 months ago. One of the RD5R is mainly for testing the FW, so I might have moved some bits into the wrong area some time… Just wonder why the 2nd RD5R now shows the same effect. Maybe it replicated via codeplug?

Please check the video first! Switching to i.e. VFO or another channel brings back the correct C1, yet as shown the device readjusts to the incorrect CC right away (muting the QSO accordingly). This is all with “CC Scan:Off”, which is the standard setup on all of my devices. TRX will stay on incorrect CC and remain muted without manual intervention. Yet it mostly appears as only ONE of the stations is causing the CC drift while the other station(s) could be heard as normal – if I manage to manually clear the CC before or during that station starts talking. Otherwise the green LED shows a signal from the hotspot but audio will remain muted due to wrong CC until I switch VFO, channel or initiate an off/on reboot…

Closer to the end in the video it shows the behavior with “CC Scan:On”. Strangely it discovers the correct CC (1) but loses it again right away and reverts back to incorrect C19 or C31. Also looping.

Various attempts to simply reflash the firmware (older versions up to current beta) and/or redo/reload the codeplug etc. didn’t fix the behavior. Any suggestion on how to “wipe” and restart from scratch are welcome ;) Yet, as this seems to be a “my specific problem only so far", I am mainly reporting on this to have it captured in the forum in case others come across a similar behavior. I have other devices that still work :D

Thanks for all the coding and supporting in 2022 and all the best for 2023!

Cheers
—Michael

G4EML
Posts: 919
Joined: Sat Nov 16, 2019 10:01 am

Re: Out of range CC code indicated

Post by G4EML » Wed Dec 28, 2022 10:07 pm

Thanks for the video. I will have a closer look tomorrow.

There is one thing I can immediately see that does not look correct or normal. When the error occurs, at the very bottom of the screen, there appears to be some extra pixels. These look like they may be the tops of a line of text that extends off the bottom of the screen. If the firmare is trying to write outside of the screen area then it could easily be overwriting and corrupting other variables.
If that is the TA text from the other station then what happens would depend on the content of the data.

I seem to remember that the RD5R has a slightly different screen to the GD77 so it may be there is some bug in the screen handling code that only affects the one radio type.

Colin G4EML

User avatar
DG1GMY
Posts: 30
Joined: Fri Oct 01, 2021 3:54 pm
Location: Southern Germany

Re: Out of range CC code indicated

Post by DG1GMY » Thu Dec 29, 2022 8:24 am

Good Morning Colin,

thanks for your feedback! I had noticed the „extra pixels“ quite some time ago but somehow attributed them to the overall beta status and your described difference between the various TRX displays. Your „eagle-eyed review“ on the pixels gave the hint to review my CPS standard procedure (Note: I follow the same procedure also for the GD77, RT3s and the DM1801 but haven't come across the "CC out of range effect" on these TRX so far).

I usually adjust the callsign database write parameters to a 32 char data record lengths and only download data region „26“ for all of my TRX, so plenty of memory for these ~ 19k contacts as of today. There are many IDs that have details >16 chars, so I assumed that the display will "show what's possible and simply cut of based on HW/FW capabilities", yet now it seems this could have cause memory corruption effecting the CC.

As you stated the TA may also add/overwrite data (depending on display options settings - my standard order is Ct/DB/TA) causing the described CC effect. Not sure how this combines with my previous 32 char callsign database data, yet at least this would clarify on why all my CC outside range drifts only appear when OM A is speaking whereas OM B (C, D…) does not make the CC „drift“ at all. CC drifts actually only appear for OMs that have „additional pixels“.

I have just updated both RD5R with 16 char data records for now to see if the out of range CC reappears. Need to wait for the “usual suspects” to show up on the QRG :roll:

Cheers
—Michael

G4EML
Posts: 919
Joined: Sat Nov 16, 2019 10:01 am

Re: Out of range CC code indicated

Post by G4EML » Thu Dec 29, 2022 10:05 am

Hi Michael,

I have never seen those extra pixels on any of my radios, but I don't have an RD5R and I also don't use 32 chars. It may well be a bug that only affects the one radio type.
I will Have a look at the code later today and try to spot where it might be happening.

The display is first generated in memory and then transferred to the real display, so there is the potential for memory corruption if the code tries to write outside the allocated area.

The operators name that appears when the other station transmits seems to be very close to the bottom of the screen. I don't remember it being that far down, so maybe there is just an error in where it starts to write the data.

Colin.

Post Reply