Hi Goody, (here is my post that contains the description of this bug in WinKeyer emulation when using N1MMLogger+), I haven't been using my N3NG nanoKeyer for awhile due to the funky keying speed changes I was experiencing. First off, for me when running QRQ contesting CW, I must have serial port checking while sending CW. So to enable the option that disables serial port checking while sending CW is a show stopper for me. (enabling OPTION_DISABLE_SERIAL_PORT_CHECKING_WHILE_SENDING_CW is NOT an option because it breaks winkeyer like functionality) I can't deal with waiting for the current character to complete sending after hitting ESC, for example. This is not WinKey behavior with N1MM and I appreciate you adding serial port checking while sending several months ago. The following is a setup description of my setup... and at the end of the message, I describe the bug and how to duplicate it in N1MM. Just jump to the end to see the bug / duplicate the bug description if you are not interested in my setup for k3ng and the nanoKeyer rev d PCB.
I thought I would give the nanoKeyer another try and this go around, do more testing to see if I could help debug the mystery of the sending speed changing on the fly. So for this testing, I bought an OEM Arduino Nano to rule out any problems with the cheap clone nano boards (not that they bad), I just didn't want that in the mix. So for the follow testing where I can duplicate one sending speed change issue, I'm using a 'real' nano with the FDTI chipset as the base line with the Rev D nanoKeyer PCB etc... I'm using version 1.8.1 of the Arduino IDE with the latest K3NG code off the master branch as of the date/time of this message. Libraries are down the default k3ng_cw_keyer/libraries path by default when I open the sketch from the GitHub repo clone. The sketch compile is clean, no warnings or errors.
In keyer_hardware.h:
#define HARDWARE_NANOKEYER_REV_D
In keyer_features_and_options_nanokeyer_rev_d.h:
The only change is to make sure and DISABLE:
//#defineOPTION_DISABLE_SERIAL_PORT_CHECKING_WHILE_SENDING_CW
No other changes to the default rev_d.h features and options. I also have ASR disabled via the nice jumper on the nanoKeyer Rev D board.
Okay... now for the details on duplicating one of the speed change bugs in N1MM. And, I hope this might explain other cases where there is a potential of a speed change related to the following:
In N1MM macros for sending CW, you can use '<' and '>' characters to dynamically change sending speed on the fly via a macro by + or - 2wpm. So a common macro for sending a singnal report would be to use this Macro in N1MM:
F2 Exch,<<<<<5nn>>>>> {EXCH}
For each '<' in the above macro the cw speed is increased by 2wpm and then for each '>' it's decreased by 2wpm. So you get the turbo fast 5NN in this case and then the exchange is sent at the currently set WinKeyer speed. This works great with the K3NG code as expected... the use of these <> chars send the cw speed changes down to the nanoKeyer in winkeyer emulation and the speed changes for the 5NN and then returns to the previous speed for the expanded EXCH macro. All is well in k3ng winkeyer emulation mode. :)
So here is the bug when serial port checking is enabled while sending in the K3NG code... I may have lead you to the obvious here. IF, you stop CW sending in the middle of the 5NN after the <<< chars have increased the CW sending speed using the ESC key for example... the keying is stopped, but the currently set sending speed is NOT set back to the previous normal sending speed. i.e. in the above example, if I'm sending at 30wpm and I interrupt the sending after the <<<<< +2wpm commands have been sent to the keyer, the k3ng / nanoKeyer is set to 40wpm.
With an actual WinKeyer, this is not the behavior... when you interrupt the keying in the middle of the 5NN after the speed has been increased, the speed of the WinKeyer is set back to the previous speed before the <<< macro chars were used. It's very easy to duplicate. So, I think this will be an easy issue to resolve in the code, but thinking through it might make you think of other cases where the sending speed needs to be set back to the previous 'set' sending speed after something has been interrupted, or for that matter, in the event there is a keying interruption, always set the speed back to the previously set speed. The WinKeyer implementation is clearly working this way... or N1MM is sending other commands down to set the previous speed that are not getting interpreted by the k3ng code.
Hope that makes sense... it's a verbose explanation, but at least it's very easy to duplicate in N1MMLogger+.
Thanks for reading... Max NG7M