Meaning and interpretation of "Interface Type" (KEY_SOUNDER / LOOP / KEYER)?

[pwdirks]

Hi guys,

In trying to collect together all the variables that should be included in a config/preferences panel I found I wasn’t quite clear on all the possibilities for “Interface Type”. I realized there are three possible values: KEY_SOUNDER, LOOP, and KEYER. That’s easy enough to represent using a three-state radio button set since you have to pick one of the options.

I believe I understand what “LOOP” represents - a local loop interface, using a box of the sort Chip Morgan sells, for instance? It interfaces via USB but I assume it essentially looks to the “Sounder” line (RS-232 “RTS”, IIRC) to activate the local sounder and recognizes a local key to generate input into the standard serial input (RS-232 "DSR", IIRC)?

How is KEY_SOUNDER treated differently? Does it not assume a local key connected to RS-232 DTR and a sounder on RTS?

Similarly KEYER - I guess that’s the clue to use DSR for “dot” and CTS for “dash” instead of paying attention only to DSR?

Can someone correct my understanding? I’m curious how “Invert Key Input” applies. I believe it was designed for use with modems connected to the input? Is that meaningful only for a KEY_SOUNDER configuration? Or does it apply equally for LOOP or KEYER configurations? Just out of curiosity, is the output signal similarly inverted when “Invert Key Input” is selected?

I realize that’s a lot of questions in one post but I’d appreciate any and all clarifications you can offer.

Thanks!
-Patrick.

[leskerr]

Patrick,

You're right about 'LOOP'. It's for the loop interface where the external key and sounder are connected in series. 'KEY & SOUNDER' is for a key and sounder that are connected independently, with the sounder controlled by a simple sounder driver circuit. The difference between the two is in 'KEY & SOUNDER' mode the MKOB software causes the sounder to follow the key, while in 'LOOP' mode the loop is powered constantly (except when Morse is received from the internet or sent on the keyboard). The pin connections for key input and sounder output are the same in both cases: DSR (not DTR) for key input and RTS for sounder output.

'KEYER' interface is similar to 'KEY & SOUNDER' except, as you said, the DSR line generates automatic dots and the CTS line is for manual dashes. This allows a keyer paddle to be used as a simulated bug.

We've talked about a fourth interface type which would accommodate the Raspberry Pi's GPIO pins. @AESilky can provide more details on this. An open question is whether the GPIO interface option would always assume a loop interface, or whether it should also work with a sounder driver and maybe even a keyer paddle. I don't have strong feelings one way or the other.

'Invert Key Input' only makes sense in 'KEY & SOUNDER' mode. The way @AESilky is using this option, however, the sounder output should not be inverted. If anyone wanted to actually connect to a dialup modem, then the sounder output would have to be inverted as well. I think this is an unlikely scenario, but for completeness maybe we need an 'Invert Sounder Ouput' option as well.

~Les

[AESilky]

Of course, @leskerr is 100% correct.

I will add...

1. I don't know that we would want to include the 'Invert Key Input' in the dialog. It is a very special configuration option that would rarely be used and would likely just cause questions. I think it should be included in our documentation and be included in the command line Configure.py, but not be part of the GUI. It wouldn't be hard to add an Invert Sounder Output as @leskerr suggests. I wouldn't use it, but I guess it would allow someone to use MKOB with an actual dial-up connection. I use the Invert Key Input in order to 'read' code from a modem being fed from an audio recording of a dial-up session. I use the PyKOB/MKOB record function to record the dial-up recording as a JSON recording. I also drive a local sounder so I can monitor the progress as the session is being recorded. I can't use the virtual sounder (computer sound) because the computer sound is playing the dial-up recording that is feeding the modem. The output from the modem is inverted compared to a directly connected key. I use Interface Type: Key & Sounder and Invert Key Input when I am doing these recordings.
2. For Raspberry Pi GPIO, I want 'LOOP' and 'KEY_SOUNDER' to be supported. I don't have a keyer, but I think it makes sense to support that as well if we support it with the serial interface. I think 'Raspberry Pi GPIO' would be an option with 'Serial/USB' and separate from the 'LOOP'/'KEY_SOUNDER'/'KEYER'. So I could pick (for example) 'RPi GPIO' & 'LOOP' or 'Serial/USB' & 'Key & Sounder'.

[jchausler]

This is in response to the whole thread which showed up in my inbox this morning. I don't know if this is the proper way to do so but here goes.

1. Yes, the "main 3" should remain on the main display. I would not have them on any underlying display, having the same thing in multiple places I think is confusing.
2. I'm OK with the single installation and multiple instances but the entire configuration has to be done from the GUI interface. I spent too much of my working life trying to talk computer phobic or computer ignorant technicians through entering command sequences using a CLI. Trying to get a system restarted remotely after said technician accidentally erased key files is no fun.
3. I would make the designation of which option (instance) to use or save just a digit. You can show the station and wire number on the selection menu but all that is needed is the "instance number" to select it. Further, once that instance is running, any change to the configuration of that running instance should be automatically saved (once OK is checked on that menu) to that instances configuration.
4. However it is absolutely necessary that different instances be started using only the mouse, no keyboard input and no menu selection. Having each configuration appear as a separate icon on the screen so all that is necessary is to click on that icon to get that configuration running is necessary. Again we're talking museum docents who are computer clueless. I've had this problem at the AWA.
5. As to configuration options, a two layer (three if you include the main screen :-) arrangement is a good idea with the more obscure options at the lower level. But again any specific option should only be configurable on one of the configurations menus.
6. As to saving json files, not only whether they are saved but a field on the configuration window designating the path to which they should be saved would be a good idea. And the json files should include the decoded letter like the existing show packets option on 2.5.
7. One option I have considered buried down at some level would be whether to automatically connect to the selected wire when the program is started. Although I had left specific instructions one docent started the program successfully and then wondered why it didn't start running :-) Never underestimate the knowledge of folks using the system and sadly, this includes former telegraph operators. Further, the typical historian at a museum is more than likely either not knowledgeable about how to work with computers and at times I've found them afraid or phobic. They don't teach computer science in history class :-)

I'll pause here to catch my breath ;-)

73, Chris

[leskerr]

Chris,

Don't you think a custom client for museum applications makes more sense than trying to make MKOB 4 bulletproof for unattended operation? Something where docents wouldn't even have a keyboard or mouse to get themselves in trouble.

Any software support would be done by remote login by someone who knows what they're doing.

~Les

[jchausler]

Hi Les,

I guess I think this is overkill. They still have to turn the computer on and I know that the installation at SONO does other things with the computer than just MorseKOB (they run audio of a dispatchers fone circuit but I had to remind them that they needed to turn off computer sound else they heard the sounder clicks along with the audio :-) and maybe there are situations where they want to use the computer for other things and not run MorseKOB. At the AWA I normally run two copies of MorseKOB but when I am chatting on wire 11 I usually kill one copy and full screen the one I'm using on wire 11. When the wire 11 chat is over I change the wire on that instance back to one of the broadcast wires and then restart the other by just clicking on it's separate icon on the screen.

The only option I can think of adding to this is what I mentioned earlier is a sticky option to automatically connect to the specified wire on start up so the docent doesn't have to remember to click on connect. However even that was a one time issue and once I explained it to that docent he had no further problems.

73, Chris

[pwdirks]

[ Chris, I'll respond to the "Config/Preferences"-related comments in the other thread ]

I think I understand "KEY/SOUNDER" vs. "KEYER" - whether to use a single "DSR" input or separate dot/dash inputs on "DSR/CTS"

I'm still not sure I understand the practical impact of choosing "LOOP" vs. "KEY/SOUNDER". Either way, input is coming from two pairs of RS-232 signals, no? Asserting "RTS" (vs. "SG") to generate sounder output, and looking for "DSR" (vs. "SG") for key input? Isn't it the loop interface's job to interrupt loop current on sounder output and translate breaks in loop current into signals on DSR? Or are the serial port's (perhaps after translation to/from USB) interpreted differently depending on whether MKOB is running the interface in "LOOP" mode vs. "KEY/SOUNDER" mode? Is there an electrical different in expected behavior?

[leskerr]

The difference between 'LOOP' and 'KEY/SOUNDER' is more theoretical than empirical. The idea is to keep the loop constantly powered in loop mode, so the sounder faithfully follows the opening and closing of the key.

If you use a loop interface in 'key & sounder' mode, then the sounder is also subject to any lag that exists in the software. I've never done any tests to see how much of an issue this is, although I've often wondered about it.

[jchausler]

Although in reality the key and sounder signals are separate at the COM port interface, with 2.5 I've come across issues when the wrong mode is set for the interface type. (Normal with a loop interface and Loop with a sounder driver type interface but haven't characterized the different behaviors so I think the two modes need to continue to be supported.

I also support the idea of continuing the paddle mode so those folks who have paddles can use them like a bug. A question would be if the code selected it International and paddle mode is selected, since there is only one dash length in international, possibly automatic dashes could be generated when in paddle mode. Just a thought, I don't ever plan to be using a paddle or international Morse with MorseKOB :-)

[pwdirks]

Hi Les,

On Dec 28, 2020, at 12:27 PM, Les Kerr ***@***.***> wrote: The difference between 'LOOP' and 'KEY/SOUNDER' is more theoretical than empirical. The idea is to keep the loop constantly powered in loop mode, so the sounder faithfully follows the opening and closing of the key.

… but does the PROGRAM behave any differently? If you select “LOOP” does it keep the sounder output active the whole time, or something?

If you use a loop interface in 'key & sounder' mode, then the sounder is also subject to any lag that exists in the software. I've never done any tests to see how much of an issue this is, although I've often wondered about it.

Are you saying in “Key & Sounder” mode the sounder is activated only when there’s output? Thanks! -Patrick.

…

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#211 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ALTAYKYNZUX6LSG4KJO3TWTSXDSZ7ANCNFSM4VLMPAVA>.

[AESilky]

I like to say 'energized', because I like to think about it 'at the instrument/equipment', but yes. In 'Key & Sounder' mode the sounder output is 'energized' only when it is being directed to 'click' (go down). In 'Loop' mode, it is energized as long as the external loop (the wire) is closed. This allows it to follow the local key. When the key is open the physical loop circuit is broken so the sounder is de-energized ('clacks' (goes up)), then when the key is closed the physical loop circuit is restored so the sounder is energized ('clicks' (goes down)).

[AESilky]

To add...
When the 'wire' circuit is opened the sounder is de-energized ('clack' (goes up)). It is then energized/de-energized ('click'/'clack') to follow the wire state (the code being sent) - thereby sounding the code.

[AESilky]

In comparison - the Key & Sounder mode energizes the sounder only when the 'complete' loop is closed. That means that the local key is closed and the remote/wire (loop) is closed. If either is opened, the sounder is de-energized ('clack' (goes up)). If the local key is closed and the remote/wire loop is closed the sounder is energized ('click' (goes down)). In this mode, the sounder is completely driven by the application. Any local or remote/wire key open/close actions are sounded by the code energizing/de-energizing the sounder.

[AESilky]

I'm trying to refrain from referring to the RS232 signals, because those go out the window when we implement the Raspberry Pi GPIO interface.

[leskerr]

Yes, the program does behave differently in Loop mode versus Key & Sounder mode. In Loop mode, the RTS line is always positive (I hesitate to say 'high', because RS-232 terminology is backwards), even when the key is open. So the loop is always powered, although no current will flow when the key is open (obviously). This is normal telegraph loop behavior.

In Key & Sounder mode, the RTS line is negative whenever the key is open, and positive when the circuit is closed. That's what allows the sounder to follow the key when the key and sounder are connected separately, and it's the main reason the Key & Sounder mode exists. A side effect of this is that in Key & Sounder mode, the sounder output reflects the contact debounce filter that's applied to the key input. I don't know if that's a pro or con.

[AESilky]

I like to say 'energized'.

In LOOP mode the sounder is always energized except when an external station has the circuit open. In that case the sounder is de-energized and energized to follow the opening/closing of the circuit by the external station (by the station sending code).

As @leskerr said, keeping the sounder energized (as long as the external stations have the circuit closed) allows the serially connected sounder (for example a KOB) to follow the key when the local circuit-closer is open.

[pwdirks]

Hi Ed, Yeah, I like “Active” or “Asserted” as a neutral term. I wonder if I have the signals listed correctly (hope this table comes through)?  “DTR” makes sense for key input but I’m confused why DSR and CTS, which normally are signals from the computer TO a terminal, are specified for dot/dash inputs? And “RTS” seems similarly inverted - shouldn’t that be an signal INTO the computer? Thanks! -Patrick.

…

On Dec 28, 2020, at 11:05 PM, Ed Silky ***@***.***> wrote: I like to say 'energized'. In LOOP mode the sounder is always energized except when an external station has the circuit open. In that case the sounder is de-energized and energized to follow the opening/closing of the circuit by the external station (by the station sending code). As @leskerr <https://github.com/leskerr> said, keeping the sounder energized (as long as the external stations have the circuit closed) allows the serially connected sounder (for example a KOB) to follow the key when the local circuit-closer is open. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#211 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ALTAYKYE3DPQXNXBUEJWSG3SXF5RZANCNFSM4VLMPAVA>.

[AESilky]

Unless it is specific to (used within) the code, I prefer to say 'energized'/'de-energized', 'key-open'/'key-closed' - because, when we implement the RPI GPIO interface there won't be DSR/CTS/ect.

[wamorganjr]

We could always go back to the original "Mark/Space". :-) I usually refer to loop (or key) open or closed as I most often work with loops. That's also where the terms "make" and "break" come from.

[leskerr]

Patrick,

I hope I can clear up the confusion here (without further muddying things). It looks to me like all the entries in the To and From columns of your table are reversed. For example, the RTS line goes from the computer to the interface to control the sounder.

Also, the DTR line is not 'key input', per se. It's nothing more than a constant source of positive voltage from the computer to the key.

One line that doesn't appear in your table is TxD on pin 3. It provides a constant negative voltage from the computer to the loop interface for the minus power rail of the op amp comparator.

Maybe the confusion comes in because in this case the computer plays the role of the DTE (data terminal equipment) in RS-232 terms, while the interface is the DCE (data communications equipment, or modem). If you're thinking of the interface as being a terminal connected to the computer, that could be where things got switched around.

I hope this helps...

~Les

[AESilky]

I don't see (or missed) the diagram.

[jchausler]

First off, I too like the terms "energized/de-energized" for the sounder and loop circuit.

As to the RS-232 signals, I've spent most of my life since the mid 60's dinking with DTE-DCE links so know it like the back of my hand but as they say a picture is worth a 1000 words so here's a link which shows both 9 pin and 25 pin pinouts and the direction of signals:
https://www.wut.de/pics/collage/e-8wwww-17-grus-000.gif .

I'm not sure its part of this thread but I see two interface "types": "serial" and "parallel" where at present (at least :-) "parallel" only refers to the possibility of using the data pins on the Pi. This is separate from whether the interface "mode" which is "loop" or "normal" (key/sounder). These should be separate configuration options and like wire number, WPM and station ID as well as server address all of these should be sticky for that individual instance of MorseKOB.

73, Chris

[jchausler]

I second Chip's idea of using mark/space for the two signal states. After all its original to the Morse telegraph and I've been using that terminology now for about 55 years both for work and play so am quite familiar with it :-)

[AESilky]

Very good! I was thinking about it as an engineer as to how the sounder is controlled (it is either energized or not), but if there is an accepted terminology in the industry, I will use that.