Restructure local loop

[leskerr]

• Place keyboard in parallel with key.
• Rename 'latch' variables.
• Implement Circuit Closer checkbox.

[leskerr]

@pwdirks @AESilky I made a bunch of changes to MKOB to implement the new architecture we came up with in yesterday's Zoom session. When I started testing the changes, I quickly realized the architecture has a serious problem. With the loop interface, when you open the key to enable the keyboard, it means the sounder is inoperative and you can't hear the Morse that's being sent by the keyboard.

I guess it's back to the drawing board. :-(

[AESilky]

I figured it would still have the software closer. If you are using a loop and you want to hear the keyboard text on your sounder you would leave the key closed and use the software closer to (virtually) open the circuit.

I believe the ability to open the key and be able to switch back and forth between the keyboard and the key will be helpful even though you can't hear the sounder from keyboard input. That is a limitation of the KOB/loop that can't be avoided.

[pwdirks]

Hmmm... on the one hand I like the idea of using the on-screen (virtual) circuit closer to activate and deactivate the keyboard. OTOH wouldn't you expect the on-screen circuit closer to follow along with the physical circuit closer on the key itself? Wouldn't it be strange to open you key but have the on-screen circuit closer look like the circuit's still closed? But if you do that, you lose the ability to use the (virtual) on-screen circuit closer as an alternate mechanism. All in all, I'm not sure it's a great idea to divorce the on-screen circuit closer from the physical one?

[leskerr]

I have the time and motivation to move forward on this issue, but I'm going to need guidance from you guys first. I'll collect my thoughts and post something here later this afternoon.

[leskerr]

I'm trying to avoid the mess I got into with the incremental evolution of MorseKOB 2.5. At first there was just the 'Normal' mode and the rarely used 'Keyer' mode. Then we added the 'Loop' mode for the loop interface, which became more and more popular (thereby making 'Normal' a misnomer). For a while we also needed the 'Modem' mode, but that need has gone away forever.

I'm reluctantly coming to the conclusion that MKOB needs a 'Loop' mode and a non-loop mode (we need a better name for this than 'Normal'). The non-loop mode would be for when there's just a key connected to the computer, or a sounder connected with a sounder driver, or both. I can see a 'Keyer' mode eventually, especially for hams who want to use their keyer paddles as a semi-automatic bug.

Right now I'm working to implement 'Loop' mode according to the following diagram:

Once I've got that working, I'll add the non-loop mode. Before I do that, though, I'll need help picking a good name for that mode (Chris would be a good person to ask), I believe the mode variable should be an enum (I've never done that before), and we'll need another config option for the mode (I'm not sure I'm comfortable doing that myself).

If you think I'm on the wrong track, please stop me before I dig myself into an even deeper hole. Thanks!

[pwdirks]

Hi Les,

What did we call it during our conversation? Independent / Linked?

As the diagram below shows, when your key and sounder are in series (“linked”?), you can turn the sounder OFF independently but you can’t turn it on for incoming traffic if you’ve opened your key, whereas with them independently connected to the computer you can leave the sounder on even if the key is opened.

Before you start implementing modes, can you spell out how MKOB would behave differently in each mode?

73, N6PWD -Patrick.

On Aug 23, 2020, at 3:55 PM, Les Kerr notifications@github.com wrote:

I'm trying to avoid the mess I got into with the incremental evolution of MorseKOB 2.5. At first there was just the 'Normal' mode and the rarely used 'Keyer' mode. Then we added the 'Loop' mode for the loop interface, which became more and more popular (thereby making 'Normal' a misnomer). For a while we also needed the 'Modem' mode, but that need has gone away forever.

I'm reluctantly coming to the conclusion that MKOB needs a 'Loop' mode and a non-loop mode (we need a better name for this than 'Normal'). The non-loop mode would be for when there's just a key connected to the computer, or a sounder connected with a sounder driver, or both. I can see a 'Keyer' mode eventually, especially for hams who want to use their keyer paddles as a semi-automatic bug.

Right now I'm working to implement 'Loop' mode according to the following diagram:

https://user-images.githubusercontent.com/63867213/90990649-e380b580-e557-11ea-9648-0fc87a7c63f6.png Once I've got that working, I'll add the non-loop mode. Before I do that, though, I'll need help picking a good name for that mode (Chris would be a good person to ask), I believe the mode variable should be an enum (I've never done that before), and we'll need another config option for the mode (I'm not sure I'm comfortable doing that myself).

If you think I'm on the wrong track, please stop me before I dig myself into an even deeper hole. Thanks!

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/MorseKOB/PyKOB/issues/130#issuecomment-678835465, or unsubscribe https://github.com/notifications/unsubscribe-auth/ALTAYK7ESRMQRNVY63N6XCDSCGM77ANCNFSM4QIEHNWA.

[AESilky]

On @pwdirks comment about the key closer and the virtual closer... If you open the key's closer (physical closer), I think the virtual closer should follow it and the checkbox should be unchecked. However, to account for the limitation of the KOB/Loop circuit, I think it is acceptable (and helpful) to be able to open the virtual closer while the physical closer is closed. This will allow the keyboard to send. The physical key will still be inactive because of the circuit of the KOB/loop interface, but I think that is fine.

The main thing I would like to get from this is the ability to open my key and send what I can from it while reverting to the keyboard for the things that I can't yet send with my fist. If I want to primarily send with my keyboard and hear it on my sounder I think it is reasonable to require that I close my key and use the virtual closer (I expected to have to do that).

@leskerr, In the case of the KOB/Loop I believe the sounder on/off is completely a software thing and not something you can illustrate correctly in the circuit diagram. The reason I say that is because the sounder isn't really being shorted, it's just that the sounder output isn't being driven. The difference is that if the program is driving the sounder, I could short the sounder (the switch in the diagram) and it wouldn't sound, but the computer output is still driving the loop interface (I could measure that on the Base of the driver transistor). I think the way to illustrate it in the diagram would be to have 'sounder out' and 'key in' on the computer and have a switch within the computer that can drive the sounder or not.

The thing that makes it hard to illustrate in a way that might (somewhat) make sense for a local loop in a telegraph office, is that it really isn't a simple loop (as drawn in the diagram). The key input to the computer is independent from the sounder being driven by the computer. It is true that if the key is open the sounder can't activate due to the physical KOB wiring (even though the computer would still be driving the sounder output and that can be observed internally in the loop interface circuit). However, the sounder output doesn't need to be driven by the computer to detect the key being open or closed because there is separate power being supplied to the key detection portion of the loop interface (from the RS-232 connection).

[leskerr]

Before you start implementing modes, can you spell out how MKOB would behave differently in each mode? 73, N6PWD -Patrick.

The essential difference is that in 'Loop' mode, if you open the key, the sounder will always be silent, even if you're sending on the keyboard or receiving a transmission from the internet. There's no way to bypass an open key with a software circuit closer. This is dictated by the key and sounder being physically in series. Fortunately, the key in this situation will always have a real shorting switch on it. The other difference with 'Loop' mode is that it's not possible to send on the keyboard when the key is open.

In non-loop mode (whatever we decide to call it), the key is in parallel with the keyboard sender and the Circuit Closer. This gives the option of opening the key and then sending on the keyboard (and hearing the sounder), and it also provides a way of closing the circuit if the key lacks a shorting switch.

I'm not happy having two different modes of operation, but I don't see any way of avoiding it. I'll take your advice though and hold off a day or two before proceeding with the changes. I think a bit of reflection is in order.

[AESilky]

I think 'Key & Sounder' and 'KOB-Loop' are good terms. It's 'Separate Key and/or Sounder', but that's probably too much detail.

You can drive the sounder if you have opened the virtual key and left the physical key closed. In that case, you just can't send from the key - only from the keyboard. In fact, as I mentioned above, you can always drive the sounder - it's just that the sounder won't 'sound' if the physical key is open.

[AESilky]

The other difference with 'Loop' mode is that it's not possible to send on the keyboard when the key is open.

That doesn't seem to be a physical limitation to me. Why can't the program read the keyboard and send the information if the physical key is open? It is true that the sounder won't sound what you sent from the keyboard, but the program should still be able to send it.

Am I missing something?

[leskerr]

If you open the key's closer (physical closer), I think the virtual closer should follow it and the checkbox should be unchecked.

This could be done with a loop interface, but not if a key that lacks its own circuit closer is connected directly to the serial port. In that case, the checkbox would always be unchecked and there would be no way to close the circuit at the end of a transmission.

[leskerr]

The other difference with 'Loop' mode is that it's not possible to send on the keyboard when the key is open.

That doesn't seem to be a physical limitation to me. Why can't the program read the keyboard and send the information if the physical key is open? It is true that the sounder won't sound what you sent from the keyboard, but the program should still be able to send it.

Am I missing something?

I was just describing how it would work in the revised architecture that I proposed. I wasn't talking about a physical limitation.

[AESilky]

For a straight key and sounder, it doesn't seem like two modes are needed. To the computer, it can't tell the difference (can it). It still drives the sounder by toggling RTS and it still detects the key on DSR.

I'm thinking that we might be trying to emulate a true circuit too literally. Maybe people really expect that and I will admit to being a rookie and defer to you. But, to me (a newcomer which would be nice to attract more of), some of these features (sending from the keyboard when I have my key open) would be very welcome.

The physical difference between a KOB/Loop and independent key and sounder is that on the KOB the sounder won't 'sound' if the key is open. However, the sounder can still be driven by the computer and the key and keyboard can still be read and sent.

[AESilky]

For a key without a circuit closer, there probably needs to be a config option for that. So that the software knows that it should always just use the virtual closer and ignore the key state.

[leskerr]

For a straight key and sounder, it doesn't seem like two modes are needed. To the computer, it can't tell the difference (can it). It still drives the sounder by toggling RTS and it still detects the key on DSR.

In the case where the key and sounder are connected separately, the computer needs to echo the key inputs back to the sounder. In the loop interface case that's not necessary, and may not be desirable.

[AESilky]

The reason I want to disable the sounder (whether my KOB or my separate key and sounder) is so I can use the computer sounder with headphones while I'm practicing at night without the physical sounder clacking out code when others in the house are sleeping. So I still want the computer sounder to sound (if I have it enabled) whether or not the physical one does/can.

[leskerr]

Right, the sounder will always be silenceable. But when not silenced, it needs to follow the key in either mode.

[AESilky]

I completely understand that, and I think that is where the 'actual' vs the 'allowing me to learn and help others learn' becomes the difference. Maybe the mode needs to be 'Realistic' and 'Training'.

[AESilky]

In the case where the key and sounder are connected separately, the computer needs to echo the key inputs back to the sounder. In the loop interface case that's not necessary, and may not be desirable.

It would be interesting to test whether sending the code to the sounder (when it is a loop interface) makes a difference. Of course I'm not a good judge of that, but you and Chris (maybe pull in a few others) would be.

[leskerr]

In the case where the key and sounder are connected separately, the computer needs to echo the key inputs back to the sounder. In the loop interface case that's not necessary, and may not be desirable.

It would be interesting to test whether sending the code to the sounder (when it is a loop interface) makes a difference. Of course I'm not a good judge of that, but you and Chris (maybe pull in a few others) would be.

I think it works fine at slow speeds. My concern is that any latency in the software will distort how faithfully the sounder follows a bug at high speeds. I will try it the first chance I get.

[leskerr]

I'm working on a prototype proof-of-concept implementation that links the Circuit Closer checkbox to the circuit closer on the key. It's not as straightforward as it sounds, but if it works it might be a good solution. It would allow switching back and forth between the key and the keyboard, and I don't think realism for the keyboard is a high priority.

Thanks for coming up with that idea, @AESilky. I had blinders on and never would have thought of it myself.

[AESilky]

So, let me try to think this through and you tell me where I'm wrong...

1. When the local physical key is open and the operator is sending code from the key 1.1. The code is sent to the wire 1.2. KOB/Loop Interface 1.2.1. Computer always drives sounder on (if enabled) to activate it (energized) 1.2.2. Operator keying automatically causes sounder to sound due to making/breaking the loop circuit 1.2.3. Computer audio (if enabled) follows the key 1.3. Independent key and sounder 1.3.1. Computer follows key and drives the sounder on (if enabled) for 'click' (key is down) and off (key is up) for 'clack' 1.3.2. Computer audio (if enabled) follows the key (sounding it)
2. When the local physical key is open and the operator is sending code from the keyboard 2.1. The character is translated to code 2.2. The code is sent to the wire 2.3. KOB/Loop Interface 2.3.1. Computer always drives the sounder on (if enabled) to activate it (energized) 2.3.2. Physical sounder will not sound, since the key is open 2.3.3. Computer audio (if enabled) follows the translated character/code (sounding it - 'click'/'clack') 2.4. Independent key and sounder 2.4.1. Computer uses translated code to drive sounder (if enabled), generating 'click'/'clack' 2.4.2. Computer audio (if enabled) follows the translated character/code (sounding it - 'click'/'clack')
3. When the local physical key is closed and the virtual closer is open 3.1. User can only send from keyboard since the physical key is closed 3.2. The character is translated to code 3.3. The code is sent to the wire 3.4. KOB/Loop Interface 3.4.1. Computer uses translated code to drive sounder (if enabled), generating 'click'/'clack' 3.4.2. Computer audio (if enabled) follows the translated character/code (sounding it - 'click'/'clack') 3.5. Independent key and sounder 3.5.1. Computer uses translated code to drive sounder (if enabled), generating 'click'/'clack' 3.5.2. Computer audio (if enabled) follows the translated character/code (sounding it - 'click'/'clack')
4. When the local physical key is closed and the virtual closer is closed 4.1 Computer listens to the wire to receive code 4.2 Computer drives the sounder (if enabled) on/off to generate 'click'/'clack' following the received code 4.3 Computer audio (if enabled) follows the received code

[AESilky]

If that is correct - I think @leskerr 's point is valid that the computer delay might be noticeable to a trained operator if at 1.2.1 the computer activated the sounder based on the code rather than always having it activated.

If that is true - I think we need KOB/Loop and Independent Key/Sounder modes.

To handle physical keys without a closer, I think we need a configuration option to indicate that (as the key will normally appear open). That option will tell the app to ignore the key open state and just follow the virtual closer.

There is also the case where no key is attached but a sounder is. I think that is the same as a physical key without a closer, except that no input will ever be received from the key.

[AESilky]

So maybe:

1. KOB-Loop
2. Independent Key-Sounder
3. Key without closer / Sounder only

For #3, the sounder is assumed. It doesn't hurt to drive it (if enabled) even if it doesn't exist. (you won't have a KOB without a closer)

[leskerr]

3. When the local physical key is closed and the virtual closer is open ... 3.4. KOB/Loop Interface ... 3.4.2. Physical sounder will not sound, since the key is open

This all looks right to me, except I think you need to delete line 3.4.2. The physical sounder will sound in this case, because the physical key is closed.

[AESilky]

@leskerr - you are correct... copy/paste error on my part.

[AESilky]

@leskerr - updated. Does it look correct now?

[AESilky]

I would prefer to perfect the list and implement from it and then create a diagram to match - since a telegraph office of the day didn't have a computer and a keyboard in the loop.

[leskerr]

I'm coming to the conclusion that we need two modes: Basic and Loop. Basic covers any of four configurations: (1) no key or sounder, (2) key only, (3) sounder only, and (4) key and sounder connected independently. Loop handles the situation where a loop interface is used to insert MKOB into a physical telegraph loop, whether it be a KOB, a series key and sounder, or a more extensive loop consisting of multiple instruments (maybe including relays, repeaters, etc.)

We might want to add a third mode for Keyer later on. All of these modes can be config options.

[AESilky]

I agree - except, where does the key without a closer come in? (I don't have one of those, but it was brought up a number of times)

I can always take my stand-alone key and just open the closer all of the time :-)

[leskerr]

@AESilky The prototype I'm working on will implement your list as corrected. I'd be happy for someone else to draw the diagram! :-)

[leskerr]

Basic mode handles a key with or without its own closer. If it doesn't have a closer, then you use the Escape key to toggle the virtual Circuit Closer. If it does have a closer, then the virtual closer follows whatever you do with the physical closer.

[AESilky]

Okay, so initially the virtual closer would be open, but you could close it to override the 'open' state.

[AESilky]

I'm just thinking that knowing that a key doesn't have a closer to cause the default to be closed might be nice. But I don't know how may have keys without closers and how much they would care.

Maybe a reason for them to submit an enhancement issue? :-)

[AESilky]

I think a connection/configuration enum of Basic / KOB-Loop would be good. We can adjust the names if needed and add a third to cover the Keyer when that presents itself.

We can easily change the names if needed.

[leskerr]

I think if the Circuit Closer defaults to closed initially, that'll work well in all cases.

[leskerr]

I agree on the enum, although I prefer Loop to KOB-Loop. It's shorter, and there may not be a KOB. Instead of mode, the enum could be called interface or something else.

[AESilky]

On Circuit Closer... What if I start the program with my key open? I suppose that's not a big issue - I just need to close my key to go back to a 'normal' state.

[leskerr]

That's right. If you start with your key open, the Circuit Closer will be initially checked by default and the program will consider the circuit to be closed. If you close your key and then open it again, Circuit Closer will become unchecked and the circuit opens up.

[AESilky]

That makes sense - just hard to understand what happens if I just start keying on my open key.

Maybe just something to see how it works and change it if there is an issue.

[leskerr]

@Houston We have a problem!

In testing my changes, I find that my turnkey interface is unstable when the sounder is deenergized and the key is open.

To confirm the problem, I ran this simple script:

from pykob import kob

myKOB = kob.KOB(port="com3")
myKOB.setSounder(False)
while True:
    print(myKOB.key())

I started the program with the key closed. The sounder was deenergized, as it should be. Then I opened the key for a second and closed it again. This is the output I got:

C:\Users\Les\Documents\GitHub\PyKOB>py keytest.py
(-2180, 2)
(-20, 11, -22, 11, -21, 11, -21, 11, -23, 12, -19, 12, -20, 11, -23, 12, -19, 12, -21, 11, -23, 11, -21, 11, -22, 12, -21, 11, -20, 11, -21, 11, -23, 12, -19, 12, -22, 11, -21, 12, -21, 12, -22, 11, -21, 11, -21, 11, -21, 11, -23, 12, -20, 12, -21, 11, -21, 11, -22, 11, -20, 11, -21, 11, -22, 11, -21, 11, -21, 11, -23, 12, -19, 11, -23, 11, -18, 1)

It's a sequence of very rapid dots, whereas it should have been something like (-987, 1).

I have a couple of other loop interfaces in my offsite storage unit. Fortunately, I 'm going to be there tomorrow anyway, so I'll bring them back home with me and try them out. I'll also take apart the one I've got and check the voltages in the circuit. But this is enough for today. I pushed a slew of PyKOB changes to the server to back up today's work.

[AESilky]

I'm open tomorrow afternoon, so I can try it with my interface and test it out. I will report back. What branch should I pull?

[AESilky]

Although I want to understand it, I think that since you experience it with your interface, others would as well.

What step does this apply to? I thought, with the kob-loop interface and the key closed the sounder would always be energized, unless sounding code.

[leskerr]

I don't think my branch is in a state worth trying. I'd sure like you to try running my little test script, though. I'd be very interested to know what it prints out when you open and close your key.

[leskerr]

I thought, with the kob-loop interface and the key closed the sounder would always be energized, unless sounding code.

This is normally true. The problem would only arise in unusual situations, such as when you want to break a remote operator by opening your key. It would also happen if you were sending on your keyboard and temporarily started sending something on your key without taking time to close the virtual circuit closer first.

[AESilky]

Let me think about that for a bit. It seems like the virtual closer and the physical closer would be open in order to send on the key. (the virtual closer should be open if the physical closer is open - unless the option for key-without-closer is true.)

[leskerr]

I need to think about this some more too. No doubt I was confused, as so often happens these days.

[AESilky]

To make is easier to move between my different machines I made a small change to your test script:

from pykob import kob
from pykob import config

interface = config.serial_port

myKOB = kob.KOB(port=interface)
myKOB.setSounder(False)
while True:
    print(myKOB.key())

This uses the configured interface port rather than just using 'com3', which doesn't exist on the Mac or Linux and my Windows uses 'com5'.

[AESilky]

Test on Mac wo PS (with my attempt at "HI" a few times)

esilky@Eds-Macbook PyKOB % python3 Closer-Test.py
(-1348, 17)
(-3443, 111, -121, 91, -96, 83, -90, 103)
(-464, 82, -115, 110)
(-1591, 82, -118, 86, -117, 65, -108, 103)
(-431, 82, -107, 130)
(-1655, 106)
(-125, 90, -109, 60, -110, 114)
(-424, 95, -115, 106)
(-1973, 98)
(-140, 67)
(-134, 50)
(-126, 127)
(-407, 95, -104, 130)
(-2219, 87)
(-127, 88, -104, 74, -112, 130)
(-523, 94, -104, 116)
(-2123, 95, -110, 93)
(-123, 54)
(-124, 121)
(-448, 91, -117, 119)
(-2878, 112, -104, 110, -92, 81, -108, 128)
(-466, 82, -116, 102)
^C
Thank you for using the Closer-Test!

[AESilky]

Test on PC wo ps attached:

C:\Users\esilk\code\morse\PyKOB>py Closer-Test.py (-3788, 123, -111, 91, -101, 84, -117, 123) (-565, 94, -102, 131) (-868, 107, -113, 88, -111, 71, -106, 124) (-406, 82, -98, 141) (-1023, 90) (-129, 76, -117, 68, -118, 124) (-404, 81, -108, 130) (-931, 95, -102, 104, -112, 78, -107, 128) (-420, 86, -107, 122) (-879, 92, -93, 107) (-126, 63, -114, 136) (-494, 91, -110, 121) (-869, 95, -116, 92, -114, 94, -94, 131) (-426, 76) (-127, 109) (-984, 113, -86, 114, -108, 100, -98, 123) (-414, 78, -118, 140) (-842, 106, -106, 102, -111, 91, -110, 130) (-436, 75) (-129, 120) (-750, 104, -115, 108, -116, 86, -103, 136) (-434, 11, -12, 47, -118, 130)

Thank you for using the Closer-Test!

C:\Users\esilk\code\morse\PyKOB>