3
\$\begingroup\$

TL,DR: How to implement notification system with multiple terminal devices, which allows to make call from any terminal to any other terminal? Main constraints are not using programmable chips/MCUs (only general-purpose and specialized hard logic), using wired communication instead of wireless, not having a separate cable between every two terminals, having single power source instead of batteries everywhere. There is no need to transmit voice or text - just targeted notifications in the style “doorbell between any two rooms”. The receiver must know who sent the notification.

This is my first question on Electrical Engineering SE. I am hobbyist in electronics. I consider myself beginner.

I would like to implement in my home a kind of notification system to make calls between rooms, either by designing it myself or by finding an existing design. Basic idea is that there will be several terminal devices (below called “terminals”) A, B, C, D, … at different places. Each terminal will have separate button for every other terminal (so for example terminal A will have buttons “B”, “C”, “D” and so on), separate LED for every other terminal (thus terminal A will have LEDs “B”, “C”, “D” and so on), and one bell (like usual electric doorbell). The buttons will be used to make calls, and the LEDs will indicate the caller.

How it should work

Suppose Alice (who is currently near terminal A) would like to call Bob (who is currently near terminal B). Then Alice pushes button “B” on the terminal device A. As a result, the LED marked “A” lights up on the terminal B, and the bell on the terminal B rings. Terminals C, D, etc. stay quiet. Bob hears the bell and sees the LED and goes to terminal A to look/ask what happened.

Further elaboration

There will be at most 16 terminals and at least 5 terminals.

Instead of multiple LEDs there might be one or two seven-segment displays on every terminal, to show caller’s ID.

Optionally, there will be also button "call all other terminals at once", e.g. to call B, C, D etc. from A simultaneously. This (as well as other optional features) will largely depend on whether it simplifies or complicates things.

Wires

All terminals will be powered from single power supply (instead of having batteries in every terminal), thus at least two wires will go through all terminals (Vcc and GND). Depending on schematics, third power wire might be needed. Further, low-frequency wire-based communication is preferred over high-frequency wireless communication for several reasons, including lack of experience with radio frequencies. Up to 8 additional wires for communication (i.e. not counting power wires) should be acceptable, with all cables meeting at single point (the location of power source). Alternatively, there might be additional mediating device which is connected to every terminal.

Simultaneous calls

There may be problem if two calls are made simultaneously from different terminals. This can be mitigated by locking terminals B, C, D once terminal A is activated, and unlocking them back once A is deactivated. Anyway, this issue can be ignored completely, assuming that any combination of simultaneous calls will not destroy the circuitry.

Design

I have a (still rough, no schematic yet) idea of how to accomplish the above project with general-purpose hard logic (gates, counters, encoders, decoders). Each terminal might send two bursts of impulses, one burst encoding caller, another burst encoding receiver. One or two communication wires might be enough. This seems to be nontrivial but viable. Perhaps I will have to find someone to review my schematics before trying to implement it.

However, I have strong feeling that this or similar problem is already solved and implemented in some specialized integrated circuits or electronic modules that can be just plugged in with minimal/moderate additions. I'm unsure how to search for such a solution, though, as well as whether the cost will be viable for me. My attempts at “multidirectional doorbell”, "home notification system" and several other queries did not provide anything relevant.

Maybe remote controls might be repurposed into terminals (calling part), with different commands for different receivers and different protocols for different callers, but then either every receiver must be able to understand all callers (multiple receiving modules in every terminal?), or there must be at least 20 different commands supported by remote control (to cover 5 terminals) to 240 different supported commands (to cover 16 terminals). I did not investigate the idea with remote controls closely, though.

Question(s)

Can you point to an existing solution with multiple "peer" terminal devices which is primarily intended for making simple non-voice notifications? Or to any ideas of how this might be implemented? Or to existing places on the web where the same thing is discussed under different name / in different setting? Are there existing solutions to other problems (like remote controls) which could be adapted for this purpose?

Please note that I will not accept answers suggesting programmable chips/microcontrollers/anything which must be programmed, even if this will really simplify remainder of circuit. (I am not saying such answers will be totally useless, since other people with different skills may have the same problem! Also, a few jumpers or micro-switches inside every terminal device to assign unique IDs to terminals are acceptable, even though this can be considered 'programming'.)

If nothing else, I will try using gates and counters. Even if the whole thing will turn out infeasible for me at this point, I'll still be glad to know what are existing possibilities.

Any input is welcome!

\$\endgroup\$
  • 2
    \$\begingroup\$ This is hard to read. \$\endgroup\$ – Marko Buršič Aug 28 '15 at 14:45
  • \$\begingroup\$ @MarkoBuršič: Why? Too long, bad formatting, bad language, wrong terminology? English is not my native language. \$\endgroup\$ – stannic Aug 28 '15 at 14:50
  • 2
    \$\begingroup\$ Too long. We don't really care about your background, previous projects and how they were built. Neither your market research. State the summary of your question preferably in the beginning, and then expand if really needed. And make sure the question can be answered without writing more than half page of text as well. And we are not recommending products. \$\endgroup\$ – Eugene Sh. Aug 28 '15 at 15:02
  • \$\begingroup\$ Just attempting to shorten the text. My "market research" was actually to ask my family what they think about it. Removed anyways. \$\endgroup\$ – stannic Aug 28 '15 at 15:58
2
\$\begingroup\$

Interesting. Of course, any sane person would use a microcontroller for this, such as Arduino. But if you really want a "hard logic" solution, I would propose basing it on a stand-alone UART chip — assuming they're still available. Here's a functional block diagram that explains the concept.

schematic

simulate this circuit – Schematic created using CircuitLab

U12 is a DIP switch that is used to identify the particular terminal (source ID).

U2 is a "keypad encoder" chip, which outputs the key number (destination ID) along with a "valid" strobe that indicates that a key is pressed. You never specified how long you want the display to persist, so I'm assuming that it's only as long as the key is pressed. Therefore, every keypress sends two messages, one on key-down and one on key-up. The key-up message sends the terminal's own ID as the destination ID, which the receivers will interpret as "turn off the display".

U3 is a multiplexer that selects the keypad output for key-down and the terminal's own ID for key-up, and U4 turns the edges on the "valid" signal into strobes for the UART transmitter.

The UART transmitter serializes the two 4-bit codes as an 8-bit byte, which then come out of the receivers of all the terminals. If the destination ID matches the terminal's own ID (determined by U7), then the display is enabled, showing the source ID from the message. If the destination ID matches the source ID in the message (determined by U11), then the display is turned off. Flip-flop U10 remembers the state of the display, and U8 functions as the decoder for the display (U9), which could be either individual LEDs or 7-segment displays.

The box marked "Bus or Hub" represents the connections among all of the terminals. You could use RS-232 as the signaling interface, in which case, you'd need a hub that combines all of the transmitter signals together and forwards them to all of the receivers. Or you could use RS-485 as the signaling interface, which would allow you to simply bus all of the terminals together along with the power distribution.

Adding the "call all" feature would most easily be added by dedicating one of the destination IDs (e.g., 0xF) to this feature. You'd only be able to have 15 terminals, but it would only require a little additional logic on the receiver to check for this specific ID coming in to enable the display.

Each of the boxes shown in this diagram is available as a single chip (SSI/MSI TTL plus the UART).

\$\endgroup\$
  • \$\begingroup\$ Will need time to digest your answer. It seems that it is not hard to modify the logic to have display persist for several seconds, and then it is OK either way. Thanks for writing. \$\endgroup\$ – stannic Aug 28 '15 at 16:15
  • \$\begingroup\$ I see how to make schematics of everything to the left of the UART (U5 and U6) but have problems with remainder. As I understand U5 has 8 data pins, 1 strobe pin, pin(s) going to the bus, and perhaps pins to set parameters; U6 has pin(s) from the bus, 8 data pins and pins to set parameters. I found HD-6402 datasheet which only shows interfacing with RS-232 (hub needed) and it seems unavailable in local shops (as well as other standalone UARTs). Also did not find any example real-life schematics with standalone UARTs. Maybe I'll just throw UART out and use more wires to transmit in parallel... \$\endgroup\$ – stannic Aug 29 '15 at 19:02
  • \$\begingroup\$ That would require a lot of wires: 9 for transmit and 9 for receive (8 data + strobe). It might be possible to replace the UART with some simple shift registers if a common clock is distributed to all of the terminals. I'll give it some thought. \$\endgroup\$ – Dave Tweed Aug 29 '15 at 19:44
  • \$\begingroup\$ Thanks; I'm interested in possible replacement for UART and will wait for possible updates. If I'm not missing anything, calling and receiving can be performed over the same 9 wires. When calling, two 4-bit IDs and "valid" signal are sent. On the receiving end the "valid" signal is AND'ed with output of U7 to enable the display and the bell. Two concurrent calls (although unlikely) will make one wrong call. Further, it is possible to use only 8 wires since at least one of 8 wires is guaranteed to be high-level during call (unless caller=receiver=0), which can be interpreted as "valid" signal. \$\endgroup\$ – stannic Aug 29 '15 at 22:09

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.