Something to consider is that the lightweight process reading the I/O lines wouldn’t be merely poking the main process when there is a paddle I/O line transition. ?That wouldn’t really accomplish anything and would still be very time sensitive. ?If the lightweight process recorded I/O line transitions based on time and sent that information to the main process for processing, any latency or jitter in the IPC or execution of main process wouldn’t be nearly as crucial. ?

For example, the lightweight process could send to the main process something like:

DIT_KEY_DOWN 0.000 mS

DIT_KEY_UP 1.500 mS

DIT_KEY_DOWN ?3.750 mS

DAH_KEY_DOWN 3.800 mS

etc.

Keep in mind DIT_KEY_DOWN, DIT_KEY_UP, etc. are just representing something like byte values that are sent, and the times would probably be in an integer. ?We wouldn’t send big clunky ASCII strings down the IPC pipe.

I had some experience developing a protocol like this for my Arduino keyer, where you could connect two keyers via IP and have code sent on one keyer via any means (keyboard, paddle, straight key) come out the other keyer with exactly the same timing as the source. ?The protocol was rather simple, but very efficient and pretty much immune to high latency and jitter. ?(I never used it on the air and I doubt anyone has, but it was a good academic exercise.)

So, we’re not sending specific CW element times, but I/O line transition times. ?The main process would translate these into CW, and in iambic paddle mode would interpret CW element insertion. ?For straight key operation, the I/O line transition times would correspond directly to key down and key up times.

But come to think of it, I could implement something like this within the paddle I/O line interrupt service routine right now, without all the trouble of another process, using an array to store the transitions…. hmmmm. ?I will explore this.

73

Goody

K3NG