Page 2 of 3

Re: Experimental Contacts cache system

Posted: Mon Jan 27, 2020 9:26 pm
by F6GVE
At the moment testing for only some minutes and I must say that when a TA has been displayed once, it is displayed instantly the following times. Impressive

Re: Experimental Contacts cache system

Posted: Mon Jan 27, 2020 9:26 pm
by m1dyp
here's a strange thing.......

sometimes my pi star hotspot forgets TG 9 and revers to TG 0

when this happens, the GD77 decodes audio but doesn't display any signal strength or TA info

is it just me ?

Re: Experimental Contacts cache system

Posted: Mon Jan 27, 2020 10:59 pm
by VK3KYY
m1dyp wrote:
Mon Jan 27, 2020 9:26 pm
here's a strange thing.......

sometimes my pi star hotspot forgets TG 9 and revers to TG 0

when this happens, the GD77 decodes audio but doesn't display any signal strength or TA info

is it just me ?
No signal strength is a strange one.

The OpenGD77 gets the signal strength from reading the RSSI/NOISE register in the RF chip

Re: Experimental Contacts cache system

Posted: Mon Jan 27, 2020 11:40 pm
by m1dyp
only when the PI is on TG 0

Re: Experimental Contacts cache system

Posted: Tue Jan 28, 2020 12:25 am
by VK3KYY
OK.

TG 0 is not a valid number. There are parts of the OpenGD77 which ignore that TG, so perhaps that includes the RSSI meter ;-)

Re: Experimental Contacts cache system

Posted: Tue Jan 28, 2020 12:33 am
by m1dyp
thanks, i wish i knew how to stop it happening, i have just looked at BM selfcare and added 4400 to the static list, time will tell if that cures the TG 0 issue i have. Midnight 30 here bed time 4 me :)

Re: Experimental Contacts cache system

Posted: Tue Jan 28, 2020 5:58 am
by VK3KYY
Guys

I found a bug in the contacts cache, if you add a Contact form the menu in the GD-77 and that Contact has to be put into the codeplug after the end of all the other contacts.

Quite often if you add a Contact in the CPS, you'll notice that the Contact does not go to the end of the list, it gets put in between 2 existing Contacts.
The Contacts cache has to mimic this behaviour, and that was / is working, but if there are no gaps in the codeplug memory between existing contacts, the new contact must be put at the end, and I had a small mistake which caused the Contact to overwrite the first contact rather than being put after the last Contact.

I also noticed that some of the user interface files, including the Contacts menu screen, did not have compiler optimisation enabled, and more importantly the file which handles the Last Heard list, which is used or all TG and DMR ID / Callsign + Name displays, was not optimised for size / speed either.

So the attached version now has compiler optimisation on all the user interface.


PS. Re the bug on the Orange button.
It seems to be a pre-existing bug and has not been caused by these changes.

And it still needs to be fixed.

Re: Experimental Contacts cache system

Posted: Tue Jan 28, 2020 6:10 am
by F1RMB
Hi Roger,
VK3KYY wrote:
Tue Jan 28, 2020 5:58 am
Guys

I found a bug in the contacts cache, if you add a Contact form the menu in the GD-77 and that Contact has to be put into the codeplug after the end of all the other contacts.

Quite often if you add a Contact in the CPS, you'll notice that the Contact does not go to the end of the list, it gets put in between 2 existing Contacts.
The Contacts cache has to mimic this behaviour, and that was / is working, but if there are no gaps in the codeplug memory between existing contacts, the new contact must be put at the end, and I had a small mistake which caused the Contact to overwrite the first contact rather than being put after the last Contact.

I also noticed that some of the user interface files, including the Contacts menu screen, did not have compiler optimisation enabled, and more importantly the file which handles the Last Heard list, which is used or all TG and DMR ID / Callsign + Name displays, was not optimised for size / speed either.

So the attached version now has compiler optimisation on all the user interface.


PS. Re the bug on the Orange button.
It seems to be a pre-existing bug and has not been caused by these changes.

And it still needs to be fixed.
I just quickly looked at the scan on orange, and the following patch would fix it (I don't have time to raise a PR right now):
It's untested.

Code: Select all

diff --git a/firmware/source/user_interface/uiChannelMode.c b/firmware/source/user_interface/uiChannelMode.c
index 08b393a..62f2e67 100644
--- a/firmware/source/user_interface/uiChannelMode.c
+++ b/firmware/source/user_interface/uiChannelMode.c
@@ -1039,6 +1039,8 @@ static void handleQuickMenuEvent(uiEvent_t *ev)
                {
                        case CH_SCREEN_QUICK_MENU_SCAN:
                                startScan();
+                               menuSystemPopPreviousMenu();
+                               return;
                                break;
                        case CH_SCREEN_QUICK_MENU_COPY2VFO:
                                memcpy(&settingsVFOChannel[nonVolatileSettings.currentVFONumber].rxFreq,&channelScreenChannelData.rxFreq,sizeof(struct_codeplugChannel_t) - 16);// Don't copy the name of channel, which are in the first 16 bytes
@@ -1093,6 +1095,8 @@ static void handleQuickMenuEvent(uiEvent_t *ev)
        else if (((ev->events & BUTTON_EVENT) && (ev->buttons & BUTTON_ORANGE)) && (gMenusCurrentItemIndex==CH_SCREEN_QUICK_MENU_SCAN))
        {
                startScan();
+               menuSystemPopPreviousMenu();
+               return;
        }
 
        updateQuickMenuScreen();

Re: Experimental Contacts cache system

Posted: Tue Jan 28, 2020 6:21 am
by VK3KYY
Daniel

Thanks.

I will try to patch it either using patch or manually

Re: Experimental Contacts cache system

Posted: Tue Jan 28, 2020 6:29 am
by VK3KYY
Thanks

I've manually patched.