CW keyer for a STRAIGHT key...

[cottersay]

Would it be possible to add code to make a functional input for straight keys (as opposed to a simple pass-through)?

The idea is that the key input would not only be de-bounced for straight keys, but also automatically send a perfect single dit (when the key is pressed down for a short time) and a perfect dah (when pressed for a longer period of time).

Obviously, it would also have automatic spacing as well as some dit/dah memory.

Just thought I'd throw it out there...

[gsansoucie]

That is a good idea. There is no straight key decoder, but I've written a straight key decoder in the old days (probably have the code somewhere). Basically decode the straight key input and then send the decoded values (dit or dah).

I imagine it would be tough to tweak though.

[cottersay]

Thanks for the feedback, Glen. I might try coding such a thing, but it's been years since I've coded anything (like way back in college with machine code).

…

-Cotter (KZ3J)

On Sat, Feb 17, 2018 at 6:24 PM, Glen ***@***.***> wrote: That is a good idea. There is no straight key decoder, but I've written a straight key decoder in the old days (probably have the code somewhere). Basically decode the straight key input and then send the decoded values (dit or dah). I imagine it would be tough to tweak though. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#42 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/Ai4kebIP7erV0s8rbHyosFUFK55T7J-Jks5tV22zgaJpZM4SJhHC> .

[gsansoucie]

Sidetone might be a concern, question is what is reflected? The straight key down or the output?

My vote would be the output and use the mechanical clicking as your straight key guide.

[cottersay]

That was my concern as well, but it could be switchable. But yes, output makes more sense, since we are all use to having it that way with paddles. I just can't believe that with all the bad straight key ops out there (like me), that someone hasn't come up with such a keyer unit, which would definitely level out the rough spots inherent in manipulating a straight key...

…

On Sat, Feb 17, 2018 at 6:29 PM, Glen ***@***.***> wrote: Sidetone might be a concern, question is what is reflected? The straight key down or the output? My vote would be the output and use the mechanical clicking as your straight key guide. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#42 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/Ai4kefk-nmA6wUVOKqpa6ItQj9LM0Tebks5tV271gaJpZM4SJhHC> .

[k3ng]

There are two straight key modes in the keyer. If you hold down the dah paddle on boot up, the keyer goes into straight key "pass through" mode with the dit paddle pin as the straight key contact. The second mode is setting the straight key pin and compiling, in which the keyer will let you operate a straight key during normal operation, in parallel with paddle and other keyer functions. This does more than pass through and if you activate straight key echo, it will decode what you're sending. I suppose it would be possible to code something to automatically time and form dits and dah, but essentially what you're asking for is bordering on bug operation, which exists in the keyer. With bug operation the dits are automatically formed and the operator has to form the dahs. This is meant to emulate bug operation with a normal paddle like you would get from a classic Vibroplex bug. An issue with coding something to form dits and dahs with a regular straight key is that the keyer needs to make a decision as to whether the operator is trying to send a dit or dah. The operator would need to set the keyer WPM speed and try to send at that speed, otherwise the keyer would make wrong decisions. However, I would argue that automatic dit and dah forming for a straight key is antithetical to straight key operation, and if one is looking for such a thing, they really want a bug, or bug emulation. I'm not saying your feature idea is a bad idea, however I'd probably devote my time coding to address the root issue, bad straight key ops. I'm thinking I will add a straight key training module that will analyze timing and coach the operator on improving it. 73 Goody K3NG

…

On Sat, Feb 17, 2018 at 7:42 PM, cottersay ***@***.***> wrote: That was my concern as well, but it could be switchable. But yes, output makes more sense, since we are all use to having it that way with paddles. I just can't believe that with all the bad straight key ops out there (like me), that someone hasn't come up with such a keyer unit, which would definitely level out the rough spots inherent in manipulating a straight key... On Sat, Feb 17, 2018 at 6:29 PM, Glen ***@***.***> wrote: > Sidetone might be a concern, question is what is reflected? The straight > key down or the output? > > My vote would be the output and use the mechanical clicking as your > straight key guide. > > — > You are receiving this because you authored the thread. > Reply to this email directly, view it on GitHub > <#42 (comment) >, > or mute the thread > <https://github.com/notifications/unsubscribe-auth/Ai4kefk- nmA6wUVOKqpa6ItQj9LM0Tebks5tV271gaJpZM4SJhHC> > . > — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#42 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ADLacBGOSSHzEZG7RrlAeGNVsZpH4nfvks5tV3ISgaJpZM4SJhHC> .

[cottersay]

Thanks Goody. I love straight key and bug operation, but stink at both. I would think that an operational straight key and cootie key electronic keyer function would "round out" the great functionality of modern keyers, but I must be the only one who thinks that!

[k3ng]

Well, you can use both a straight key and a cootie with this keyer. :-)

…

On Sun, Feb 18, 2018 at 1:38 PM, cottersay ***@***.***> wrote: Thanks Goody. I love straight key and bug operation, but stink at both. I would think that an operational straight key and cootie key electronic keyer function would "round out" the great functionality of modern keyers, but I must be the only one who thinks that! — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#42 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ADLacIRCzRVI00q6IEaJCQYkuDQIw34Dks5tWG4vgaJpZM4SJhHC> .

[cottersay]

What I need to do is invent a robotic hand that allows me to send decent code with a straight key, 'cause my god-given hands are apparently too sub-par in that regard!

[behiels]

Hi Anthony;

I do have made a lot of progress and the whole project is working outstanding now,just one particular little failure I have …

This is your comment and explanation about “the straight key feature” I found on the internet :

There are two straight key modes in the keyer. If you hold down the dah paddle on boot up, the keyer goes into straight key "pass through" mode with the dit paddle pin as the straight key contact. The second mode is setting the straight key pin and compiling, in which the keyer will let you operate a straight key during normal operation, in parallel with paddle and other keyer functions. This does more than pass through and if you activate straight key echo, it will decode what you're sending.

I do have next settings enabled in the K3NG software :

#define FEATURE_STRAIGHT_KEY

#define FEATURE_STRAIGHT_KEY_ECHO (I like to read and seen what I am sending on the LCD for education )

After compiling I receive next error message :

#if defined(FEATURE_DISPLAY) && defined(FEATURE_STRAIGHT_KEY_ECHO)
if (cli_straight_key_echo){display_scroll_print_char(convert_cw_number_to_ascii(decode_character));}
#endif //FEATURE_DISPLAY

The failure is coming from the second command : #define STRAIGHT_KEY_ECHO

Could you help my further on the way with tihis remarcable failure Anthony ?
What could be the reason ..?
Do I have not the last software relaise from your project ?

With kindly regards es 73’s Jean ON4AEF

[jh4vaj]

That "if statement" is probably unnecessary.
If you simply do the following, no error will occur. The straight key is echoed.

display_scroll_print_char(convert_cw_number_to_ascii(decode_character));

[mamortensen]

"The second mode is setting the straight key pin and compiling, in which the keyer will let you operate a straight key during normal operation, in parallel with paddle and other keyer functions. "

By "setting the straight key pin" do you mean uncommenting #define FEATURE_STRAIGHT_KEY? I don't see a straight key pin. Either a pin to enable straight key or a pin to connect the straight key to. That option isn't shown in the schematic. Can you elaborate how to enable and connect a straight key in parallel with the paddle?

[mamortensen]

Ah, I figured it out. The straight key pin is hidden inside an #ifdef that I didn't notice and is set to a pin I don't have. I assigned it to pin 10 and now it works.