Page 2 of 3

Re: Update 21st Feb

Posted: Sat Feb 22, 2020 3:08 pm
by F1RMB
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.

Re: Update 21st Feb

Posted: Sat Feb 22, 2020 5:33 pm
by iv3bvk
Great job!
The 2/21/2020 release is working fine!

All the best

Re: Update 21st Feb

Posted: Sat Feb 22, 2020 8:43 pm
by VK3KYY
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

Re: Update 21st Feb

Posted: Sun Feb 23, 2020 12:38 am
by kd2lh
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
(7.37 KiB) Downloaded 152 times
Marc KD2LH

Re: Update 21st Feb

Posted: Sun Feb 23, 2020 2:02 am
by kt4lh
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!

Re: Update 21st Feb

Posted: Sun Feb 23, 2020 3:28 am
by VK3KYY
If you mean the beep volume, there is a bug with this, which will be fixed in the next experimental version.

Re: Update 21st Feb

Posted: Sun Feb 23, 2020 8:12 am
by F1RMB
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

Re: Update 21st Feb

Posted: Mon Feb 24, 2020 3:25 pm
by DU2XXR
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.

Re: Update 21st Feb

Posted: Mon Feb 24, 2020 9:32 pm
by kd2lh
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
PiStarFilter.jpg (129.76 KiB) Viewed 4744 times

Re: Update 21st Feb

Posted: Mon Feb 24, 2020 10:06 pm
by VK3KYY
All of my RPi's are in metal boxes for shielding.
RF gets everywhere ;-)