-
F1RMB
- Posts: 2747
- Joined: Sat Nov 16, 2019 5:42 am
- Location: Grenoble, France
Post
by F1RMB » Sat Feb 22, 2020 3:08 pm
Hi,
KV0A wrote: ↑Sat Feb 22, 2020 1:48 pm
VK3KYY wrote: ↑Fri Feb 21, 2020 11:26 pm
Sometimes the beep volume gets set back to 3dB
It's not that it doesn't get saved, but it gets reset to 3dB as soon as the menu option displays. Like change it to -3dB or something and exit the menu. It will get saved. but go back to the menu to change something else and as soon as that option is displayed it will reset to default. It's like whatever draws the menu option is fetching the value from the wrong place.
So It's like this executes:
Code: Select all
case OPTIONS_MENU_BEEP_VOLUME:// Beep volume reduction
snprintf(buf, bufferLen, "%s:%ddB", currentLanguage->beep_volume, (2 - nonVolatileSettings.beepVolumeDivider) * 3);
soundBeepVolumeDivider = nonVolatileSettings.beepVolumeDivider;
break;
And something is up with that soundBeepVolumeDivider = nonVolatileSettings.beepVolumeDivider; like nonVolatileSettings.beepVolumeDivider no longer contains the correct value or something, and soundBeepVolumeDivider gets reset as soon as it displays.
Hmm... I just tinkered with it again and maybe it was only happening because I hadn't turned the power off yet so the settings had not gotten saved yet. perhaps the fix is to change (2 - nonVolatileSettings.beepVolumeDivider) * 3 to (2 - soundBeepVolumeDivider) * 3 and save/update the nonVolatileSettings elsewhere?
Not sure of the right solution since I'm not familiar enough with the code.....
Anyway it's not doing it anymore after I power cycled, though I'd sware I had power cycled it at least once before.
Edit:
Ok maybe I figured out what I was doing wrong. Maybe I hit the red key not the green key and this happened:
Code: Select all
else if (KEYCHECK_SHORTUP(ev->keys,KEY_RED))
{
// Restore original settings.
memcpy(&nonVolatileSettings, &originalNonVolatileSettings, sizeof(settingsStruct_t));
setMicGainDMR(nonVolatileSettings.micGainDMR);
menuSystemPopPreviousMenu();
return;
}
So the settings got restored to their previous values, but soundBeepVolumeDivider was left the same. I think maybe the only thing missing is to reset soundBeepVolumeDivider = nonVolatileSettings.beepVolumeDivider after the memcpy()
Nice catch. You're right, soundBeepVolumeDivider isn't restored on cancel.
Cheers.
---
Daniel
EDIT: I raised the PR with the bugfix, Thanks Robert.
-
iv3bvk
- Posts: 10
- Joined: Sun Jan 26, 2020 3:29 pm
- Location: Fontanafredda (PN)
-
Contact:
Post
by iv3bvk » Sat Feb 22, 2020 5:33 pm
Great job!
The 2/21/2020 release is working fine!
All the best
-
VK3KYY
- Posts: 7613
- Joined: Sat Nov 16, 2019 3:25 am
- Location: Melbourne, Australia
Post
by VK3KYY » Sat Feb 22, 2020 8:43 pm
I will merge the PR to fix the beep restore problem, and also Colin has sent me a possible improvement for the CC filer disabling to help remove some of the spurious noise
-
kd2lh
- Posts: 312
- Joined: Mon Dec 02, 2019 2:44 pm
Post
by kd2lh » Sun Feb 23, 2020 12:38 am
Daniel, I attached the DMESG files from the Hotspot mode dumping back to regular GD77 mode a couple of posts ago.
I should have some ferrite core filter torriods later in the week and I'll test with those in place.
I'm now testing with the GD77 out of the charger base in case that is what is generating the noise that is interfering with USB. Within an hour, this also has failed. The DMESG file is attached.
Marc KD2LH
Last edited by
kd2lh on Sun Feb 23, 2020 3:36 am, edited 4 times in total.
-
kt4lh
- Posts: 273
- Joined: Sun Jan 12, 2020 4:27 am
Post
by kt4lh » Sun Feb 23, 2020 2:02 am
I saw the weird issue with the volume on sticking on a few firmware versions ago and I thought I'd cancelled out of something, but I was sure I had not. I set it to the normal -6 or -9 or whatnot, finished setting the options here, went to display options and it was loud again. Went back in and that was the only setting I had to change.
Kind of weird, first and last time I've seen it though!
-
VK3KYY
- Posts: 7613
- Joined: Sat Nov 16, 2019 3:25 am
- Location: Melbourne, Australia
Post
by VK3KYY » Sun Feb 23, 2020 3:28 am
If you mean the beep volume, there is a bug with this, which will be fixed in the next experimental version.
-
F1RMB
- Posts: 2747
- Joined: Sat Nov 16, 2019 5:42 am
- Location: Grenoble, France
Post
by F1RMB » Sun Feb 23, 2020 8:12 am
Hi Marc,
kd2lh wrote: ↑Sun Feb 23, 2020 12:38 am
Daniel, I attached the DMESG files from the Hotspot mode dumping back to regular GD77 mode a couple of posts ago.
I should have some ferrite core filter torriods later in the week and I'll test with those in place.
I'm now testing with the GD77 out of the charger base in case that is what is generating the noise that is interfering with USB. Within an hour, this also has failed. The DMESG file is attached.
dmesg3.zip
Marc KD2LH
I looked at all your dmesg files, and it's just like what I've experienced: the USB hub has been disabled and reenabled.
Let's see if the ferrite improve things.
Cheers.
---
Daniel
-
DU2XXR
- Posts: 191
- Joined: Thu Nov 28, 2019 5:25 am
- Location: Philippines
-
Contact:
Post
by DU2XXR » Mon Feb 24, 2020 3:25 pm
I've been using the Feb 21 version since, well, Feb 21. I've only started noticing something today, though. Sometimes, received transmissions would say "private call" even when they are TalkGroup traffic. This goes the same when receiving from repeaters and from my OpenSpot hotspot.
I have TS filtering turned off.
-
kd2lh
- Posts: 312
- Joined: Mon Dec 02, 2019 2:44 pm
Post
by kd2lh » Mon Feb 24, 2020 9:32 pm
I've received and installed the ferrite filter on the USB and power connections to the Pi Zero W.
Now we'll see if we get the USB lockout failure.
- PiStarFilter.jpg (129.76 KiB) Viewed 4840 times
-
VK3KYY
- Posts: 7613
- Joined: Sat Nov 16, 2019 3:25 am
- Location: Melbourne, Australia
Post
by VK3KYY » Mon Feb 24, 2020 10:06 pm
All of my RPi's are in metal boxes for shielding.
RF gets everywhere