Concurrent key presses?

This might sound like a silly question, but I have to ask - because I'm seeing an odd behavior and this might be the explanation.

I have an 8-way NEO key input (firmware 1.4.0) which is operating some different loads.

Is there any (defined) condition when more than one key is pressed and held at a time? Does each key operate "in isolation" - or does having more than one key pressed at a time cause the key scanning to break? (They would rarely be simultaneous, but frequently are concurrent)

Imagine, if you will, each key being configured as a bell-press, and different loads being operated by each key. What I'm observing is that depending on what other keys are pressed, some will (or will not) operate. The effect seems to be repeatable and reliable.

"Don't do it" isn't an option

 

Neo firmware can process up to two simultaneous key presses without problems.

Any more keys pressed at the same time, and one of the keys won't register.
Note: the key that doesn't register is not necessarily the last key to be pressed.

This is the same for Saturn (Ulti) and Reflections units, as well as the 30mech switches.

Mask 1.00 units and the bus coupler on the other hand, can process any number of simultaneous switch closures accurately. With these units for example,you can hold three keys down, and press the fourth and the fourth will operate correctly.

 

Ahhh. That explains it exactly. The reason for my "intermittent" operation is there may be none, 1 or 2 already pressed.

Sounds like I'm in the market for a bus-coupler

Thanks for the confirmation.

 

Modified my thinking to work around the limitation.
Rather than a steady-state to indicate on/off for each input, I could send (say) a long pulse (500ms) for "on", and a short pulse for "off". The chance of more than two inputs being on at the same time with such relatively short pulses is insignificant.

The question is "how short must a short pulse be"?
Presumably it must be greater than the debounce time (48ms) but shorter than the "long press" threshold (400ms).

Is a 100ms +/-10ms "safe"? Would it be better to aim for nominally 200?
Response time isn't a concern.

I'd set the key functions as:
Short Press: Idle
Short Release: Off Key
Long Press: Idle
Long Release: On key

I can then overcome the obvious problem of "losing state" if there was a powerfail or system reset (it's never happened yet, but lets not preclude the possibility) by periodically sending long or short pulses to continuously "update" each input channel.

 

I don't see any problem with 100mS +/- 10ms.

Of course you can change both the debounce and the long press times to suit your application.
Obviously you are using this NEO as a bus coupler - and using switch contacts or transistors for activation. If you are using transistors, you could reduce the debounce time, but note the keys are scanned once every 16ms, so your pulses must be at least 16ms long.

Your suggested key functions are fine, although I always prefer to set the Long press to the action and leave long release idle - just because it gives faster response.

 

Great, I'll try to make some time to play this weekend.

Yup, but I figure the dev guys picked these times for a reason

Yes, and using optoisolators to ensure isolation from control equipment to cbus, prevent any potential of leakage, ground loops etc from the various control elements (which are spread over quite a large distance)

I pondered that, and couldn't make a good case for one over the other - especially given the "non-time-critical" nature of the event. Basically it's turning on and off a variety of circulating, cooling and transfer pumps. Response times even in tens of seconds wouldn't pose a problem.