OpenGD77

Colin

Thanks

I will look at the code

G4EML wrote: ↑

Mon Nov 25, 2019 4:16 pm

Did some testing of the backlight when receiving repeater beacons.
The backlight is actually triggered at the end of the beacon.

So what happens is the beacon starts, the green light comes on, the backlight remains off. (that's what I would expect to happen)
The beacon ends, the green light goes out, the backlight turns on.

It looks like the backlight might be being triggered by an update to the QSO data display even though there is actually no new data to display.

Colin

I'm finding it hard tracking down whats causing this, as I don't have a way to generate these signals

However, I think its going to be one or both of these

https://github.com/rogerclarkmelbourne/ ... 00.c#L1361

and

https://github.com/rogerclarkmelbourne/ ... 00.c#L1460


These set the display state back to showing the normal screen, and this in turn causes the screen to be re-rendered and the backlight to be turned on

However, in this case I think you're saying that the screen is not displaying any QSO data and does not need to be redrawn

On the Channel screen there is a variable
Which could potentially be checked and if the screen was still displaying the same thing it was last time, then we could simply not render the screen and not turn on the backlight

So rather than trying to change

https://github.com/rogerclarkmelbourne/ ... 00.c#L1361

Its probably more efficient to modify the Channel (and VFO) screens

static bool isDisplayingQSOData=false;

And change this to an enum of states, and then not render the new state if the display is on the same state

Well, actually its bit more complex, as if its displaying QSO data and its told to display QSO data again, that may be valid as the QSO data may have changed, but if its not displaying QSO data and is told to render QSO_DISPLAY_DEFAULT_SCREEN again, then that is probably redundant under some circumstances, but perhaps not all

Hi Roger,

Luckily I have a local repeater (not mine) that seems to be sending beacons every 15 seconds at the moment. So testing is easy. Most U.K. Motorola repeaters send beacons every minute. When the network was first set up most people were using Motorola or Hytera radios so roaming was quite heavily used. Now that most are using Chinese radios it is probably not so common.

By commenting out lines one at a time It actually appears to be line 1103 that is triggering the backlight.
I think that happens when the receive code times out as the repeater drops carrier.

Because the beacon does not contain any data or voice bursts there is no QSO data displayed. So your idea of only updating the display of it is not already displaying QSO_DISPLAY_DEFAULT_SCREEN would fix this.

Colin.

I Colin

I will need to make some changes to the code to differentiate the use of the function which updates the screen when it’s not displaying the QSO data, because the same function is called when buttons are pressed e.g When the TS or mode or channel etc is changed.

I think it just requires an argument to be added to the update function, but I will need to work out the best way to do this

Thanks

Roger

hi Team,
Any news about this bug?

I have not had time to fix it

Good morning all,
I want to warn you that the problem still exists even in today's latest version
73 de IU4LEG

Yes. Its still on the To Do list.

I will need to discuss it again with Colin.

We know what causes it, but we dont have a solution yet.

VK3KYY wrote: ↑

Sat Dec 14, 2019 6:58 am

Yes. Its still on the To Do list.

I will need to discuss it again with Colin.

We know what causes it, but we dont have a solution yet.

Ok Roger,
Thank you

i confirm that issue is solved with the latest version 7314ed7 Dec 25 2019.
Thanks to all developers.
Marry christmas de IU4LEG