Experimental Contacts cache system
Re: Experimental Contacts cache system
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
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 ?
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
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
only when the PI is on TG 0
Re: Experimental Contacts cache system
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
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
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
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 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.
- Attachments
-
[The extension sgl has been deactivated and can no longer be displayed.]
Re: Experimental Contacts cache system
Hi Roger,
It's untested.
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):VK3KYY wrote: ↑Tue Jan 28, 2020 5:58 amGuys
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.
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
Daniel
Thanks.
I will try to patch it either using patch or manually
Thanks.
I will try to patch it either using patch or manually
Re: Experimental Contacts cache system
Thanks
I've manually patched.
I've manually patched.
- Attachments
-
[The extension sgl has been deactivated and can no longer be displayed.]