Re: Keyer Issue with QCX - missing or short dahs
toggle quoted messageShow quoted text
You have done something I had thought about some time back but never had time to dig into it. What would be really interesting would be to take your ardunino that acts as the keying generator and hook it up to two keyers simultaneously. For the benchmark keyer use one of those older units based on hardware CMOS chips and then a microprocessor based one for the test subject. Compare the outputs. The problem with these microprocessor based keyers (the ones that have issues at least) is that they are doing multiple things in the background whereas the hardware based keyers are dedicated to the task and never get delayed or interrupted. You could go one step further and use a second arduino dedicated to the monitoring side rather than the storage scope. Use a digital pin on the sending arduino to trigger the measurement loop on the receiving arduino. Send alternating dit/dahs and gather some statistics on the timing jitter. This could evolve into a benchmark test for all the various keyers out there! Thanks for taking the initiative.
On Mon, Jul 15, 2019 at 9:37 PM Rex Vokey <rex@...
I think I misspoke - I don't key ahead on words. I just sometimes key the character itself faster than the set speed. Playing around with all of this a bit, I found that I do, in fact, tend to slow down a bit when the keyer speed is set slower - but it's not a perfectly linear scale (I'm not a machine!).
Since all of this timing stuff can get a bit dizzying, I decided to take myself out of the equation. I set up an Arduino to "close" the dit and dah paddles for me, with timing precise down to the millisecond. I played around with the timings a bit until I got to a point where the Arduino is closing the paddles at about 21wpm.
See the attached photos—top is RF-out, bottom is paddle closures ("hollow" longer ones are dahs and shorter "solid" ones are dits). What I've found so far, keying "C" at various keyer speeds:
At 12wpm, I hit the limit of the dot/dash memory (one element). As many have stated, this is expected. We're getting more than one element ahead here. Slow down on that paddle!
At 13wpm, it somehow functions fine, even though it appears I'm keying just a tiny bit too fast. I'm probably within milliseconds of the memory window.
At 14wpm, this is where we see my primary issue. The second "dah" is shortened by nearly a full "dit." You want to talk about needing feedback? This really throws me off if I'm trying to send good code. I haven't done enough testing yet, but it seems to me, the length varies. I could be wrong. More testing is needed.
At 15wpm, everything is fine. I don't have a capture of it, but I believe 16wpm was also fine. Again, more testing needed.
At 21wpm, all is normal.
One thing I've learned from this is that one element worth of dot/dash memory actually provides a good deal of flexibility for human inconsistency.
I'm going to do some more testing. I'll try and update here with what I find. Hopefully I've provided more useful information for those attempting to analyze the problem.
Thanks, and 73!
Join QRPLabs@groups.io to automatically receive all group messages.