"Sticky" Dual Watch mode

[KenFromNN]

Hello,

Just want to suggest an idea of a new feature for discussion.

There is Dual Watch mode already in OpenGD77 and it works pretty well when it is necessary to monitor two different frequencies.
One thing which may make this mode even more valuable is to allow radio transmissions without exiting it.

Please consider the following use case:
When playing airsoft games, one may want to use VFO A to receive from their commanding officer.
VFO B can be used to transmit commands to their own team of other people.
Pressing PTT exits Dual Watch mode now which makes this mode not very comfortable.

The suggestion is:
1.To switch Dual Watch mode back at the end of transmission when PTT button is released.
2. Add '>' sign on Dual Watch mode display before VFO A or VFO B to indicate which one will be used for transmission.
3. Allow selecting VFO A or VFO B by pressing A/B button without exiting Dual Watch mode.
4. Quick Menu (and may be Settings) must be updated accordingly (depends on the way "sticky" Dual Watch mode is enabled).

What do you think about it?

[VK3KYY]

Source code is available for anyone who wants to change the functionality

See the FAQ

[KenFromNN]

Yes, I have already downloaded source code archive and even examined several routines related to Dual Watch mode.

Unfortunately I developed with C/C++ many-many-many years ago, almost twenty in fact
And never - for anything like portable radio.
Being Java/Oracle developer now, it looks a bit difficult

Maybe I'll try anyway. Hope I'll not brick my Bao 1801

[VK3KYY]

Yes, I have already downloaded source code archive and even examined several routines related to Dual Watch mode.

Unfortunately I developed with C/C++ many-many-many years ago, almost twenty in fact
And never - for anything like portable radio.
Being Java/Oracle developer now, it looks a bit difficult

Maybe I'll try anyway. Hope I'll not brick my Bao 1801

Virtually impossible to brick these radios, especially if you've backed up the Flash EEPROM and the MCU ROM
The top of the MCU ROM holds some a unique key used by the bootloader to determine whether it is allowed to reload the firmware

The firmware does not contain any functionality to write to the MCU ROM, hence the firmware can't damage the bootloader

Even if you did totally trash the MCU ROM somehow, I posted cracked versions of the bootloaders, which can be flashed using a $10 programmer dongle, by attaching 4 wires inside the radio.


The code on the VFO Screen is now quite convoluted, as there are 4 main operating modes, i.e normal, freq scan, sweep scan and dual watch.
Probably the code needs to be completely refactored, but thats many hours of work for no visible gain to any of the users.

[KenFromNN]

OK, I installed MCUXpresso IDE, installed SDK SDK_2.x_MK22FN512xxx12 and it seems that firmware was compiled successfully.
Did not try to flash my radio with it yet

Roger, should I bother searching for manuals/tutorials about debugging in MCUxpresso, or it is not possible for my environment?
Probably it is necessary to have some specific hardware?
I don't know, never had a chance to develop&debug anything like that

[VK3KYY]

OK, I installed MCUXpresso IDE, installed SDK SDK_2.x_MK22FN512xxx12 and it seems that firmware was compiled successfully.
Did not try to flash my radio with it yet

Roger, should I bother searching for manuals/tutorials about debugging in MCUxpresso, or it is not possible for my environment?
Probably it is necessary to have some specific hardware?
I don't know, never had a chance to develop&debug anything like that

J-link Edu is probably the cheapest in circuit debugger

BTW.
You would need to backup the MCU ROM using the CPS, then flash the backup back into the MCU to unlock the read protection

Don't use the External debugger build, as it no longer fits in the ROM. Just use the normal GD77 build target