K3NG keyer?

[dl1ycf]

I find the state of the software close to converged now (I am using the keyer regulary since I do a lot of CW), so the question is
whether the K3NG keyer should be included as an alternative to the TeensyWinkeyEmulator.

The TeensyWinkeyEmulator emulates exactly those features of the original (K1EL) WinKey chip which I need. Some features (stored messages, changing settings via paddle) cannot be used since there are no push-buttons. But the K3NG keyer is a much more "complete" K1EL emulation than the TeensyWinkeyEmulator.

So the question is, should I start adapting it to the CWKeyerShield library. It is not that difficult since the interfacing is essentially the same as done for the "other clone" (TeensyWinkeyEmulator). In my view this is not a must-have but possibly a nice-to-have.

Yours, Christoph Dl1YCF

[softerhardware]

Hi Christoph and Group,

Thanks for your help. I'll leave it to you and other CW operators to decide whether a K3NG port is worth it. You can still find my early port here: https://github.com/softerhardware/k3ng_cw_keyer

Sorry for not being very responsive. My day job is taking all my time right now. I still like to organize a group buy for the CWKeyerShield once people think software and firmware are ready, and with a few tweaks to the hardware.

73,

Steve
kf7o

[jimahlstrom]

If the K3NG is available, I think it should replace the original WinKey chip. I don't see a reason for both.

[dl1ycf]

OK, given that (as I see it) adapting the K3NG keyer to the KeyerShield is mostly "copy and paste" from what I did to adapt the TeensyWinkeyEmulator, this is probably the way to go (I shall take care of that but give me some time).

For people that want to compile the things from sources themselves, TeensyWinkeyEmulator is probably somewhat easier, but at the end there will be a hex file containing the CWKeyerShield library and the K3NG keyer, and this can be used without special skills.

The largest part of adapting the K3NG keyer is to identify the places where there is "busy waiting", e.g. delays etc. Since it must be guaranteed that the shield.loop() function is called at regular intervals. TeensyWinkeyEmulator is a (nearly complete) state machine and has "busy waiting" only for reading/writing the EEPROM, but as far as I have seen there is some more "busy waiting" in the k3ng keyer, but this will be manageable.