0
\$\begingroup\$

For a lighting project I need to be able to trigger 20 units every couple of seconds independently which are daisy chained with 1-2 m space between each of them like so:

Control station ====== Unit 1 ====== Unit 2 ====== Unit 3 ....

Every unit has an ID and I need to be able to trigger it with a response time of <500ms, no other data needs to be transferred.

Every unit has an Attiny25V. Ideally, I would like to prevent adding ICs for communication. I can spare a maximum of 2 pins for communication on the Attinies.

How can I connect a few Attinies with a digital bus if they are spaced far apart?

\$\endgroup\$
  • 1
    \$\begingroup\$ Does power and signal go down the daisy chain? How much current flowing if power is in the cable? \$\endgroup\$ – Jack Creasey May 29 at 22:28
  • 2
    \$\begingroup\$ What is your awareness of ambient noise levels expectations for immunity, error rate? fault detection? Any noisy Triac dimmers or HV flashes nearby? with 100kHz-m bandwidths using good cable and low ambient noise, 20 to 40m bus might go at 25kbps . Is this a simplex Tx only? no error detection? \$\endgroup\$ – Tony Stewart Sunnyskyguy EE75 May 29 at 22:57
  • \$\begingroup\$ power runs through the daisy chain, im expecting about 0.6 Amps at 10V. Every unit contains a HV flash (that is what is being triggered by the signal). Im guessing the implications of this make I2C unlikely to work for my given scenario? \$\endgroup\$ – WhiteSpin May 30 at 12:33
  • \$\begingroup\$ I2C would have more noise than signal. \$\endgroup\$ – Tony Stewart Sunnyskyguy EE75 May 31 at 1:10
1
\$\begingroup\$

Low data rate transmission over long distance using MCUs

I'd suggest that any configuration requiring the nodes/units (the MCUs) be programmed with individual ID# would be extremely hard to manage.

  1. Each unit has to be individually programmed with an ID#
  2. Most bus based protocols are not able to be position sensitive
  3. Units become order sensitive and difficult to use in large numbers

With any Bus based system it is almost impossible to tell the relative positions or physical connection order of the slaves. I2C is a great example of this restriction; there is no way to tell the physical connection architecture without additional logic and status lines.

I would suggest the best possible architecture for your application would be to use a SoftUART in each of your ATTinys and a very simple half duplex async command protocol.

Consider a configuration like this:

schematic

simulate this circuit – Schematic created using CircuitLab

Each ATTiny is Non-unique (no initial ID#'s) and is configured by the protocol reset. ID#'s are allocated based on connection order.
A simple protocol might be as follows:

  1. All units Rx a character string starting with "#" and ending with a cr or cr/lf sequence from the left source on their Rx input, decode and send to the next unit using the right Tx. The string is fully received decoded and then sent to the next unit downstream. In this way you only require half duplex operation in each node.
  2. Character strings can be modified by each unit if required. This allows either incrementing elements such as ID#'s or allows command feedback.
  3. The character string is returned to the Host unit after passing through ALL physical units in the string.

Command strings might be as follows:

Reset: #Ra cr ….// #=Start of string.... "R"=reset command …. "a"=start ID# …. cr= cr or cr/lf sequence
The host sends "#Ra" cr to the first downstream node, which resets, and copies the "a" to it's ID# storage. The string start ID# is incremented (from 'a" to "b") and sent to the next downstream node. If there were 26 nodes in series, then string returned to the Host would be "#Rz" cr" and each node would now hold a unique ID# of "a" through "z".

Trigger: #T? cr ….// #=Start of string ….."T"= Trigger command …."?"=node ID# "a" through "z".

Passthrough: #P? cr ….// #=Start of string ….."P"= Passthrough command …."?"=node ID# return value.
The node receiving this command would simply copy this to it's downstream neighbor taking no other action. This would be a simple way to return a status byte from a node. For example, if a node received a Trigger command, then it could alter the string sent to the next node to a Passthrough command, adding whatever status byte it required. All other nodes would simply pass this string to their neighbor and eventually back to the Host.

With the protocol above a string is 4 characters long. If the baud rate was set at 9600 baud, then it takes about 4.1mS for the string to be sent. Since the string must pass through all 20 nodes then it takes about 21 * 4.1ms for the string to return to the Host, or about 84mS.
I'd suggest that when a trigger command was received, the addressed node would not send the string to it's neighbor until the Flash was complete, it could then return the status (power used, or other parameters) to the Host using Passthrough. This also means that if you have a high energy pulse, the data lines are not being used while processing the command, reducing the likelihood of transmission errors.

An architecture such as this could be useful for at least ten meters distance between nodes, and at 9600 baud easily meets your 500mS requirement.

\$\endgroup\$
  • \$\begingroup\$ I really like this approach and have started implementing it. I guess the biggest bottleneck now is the distance of the last unit in the chain (Tiny_n) to the Host_rx, as this is not amplified by the units in between, or am I missing something? \$\endgroup\$ – WhiteSpin May 31 at 10:47
  • \$\begingroup\$ At 9600 baud you should have no trouble going the distance (40-50m) with a 5V signal. while it adds complexity you could buffer/invert/clip the inputs and pull up to 10V which would improve risetimes and mean the line operated almost as a current loop. \$\endgroup\$ – Jack Creasey May 31 at 15:28
0
\$\begingroup\$

Probably the best protocol for an application like this is I2C, because devices use pull up resistors, it allows for less noise and common mode problems than other buses. They can all be on the same bus and only three wires need to be ran like this (but each device is an Attiny):

enter image description here Source: http://robotexplorer.blogspot.com/2014/01/i2c-and-spi.html

Here is a tutorial on I2C for an Attiny

\$\endgroup\$
  • \$\begingroup\$ The downside here is that there is no way to tell in what physical order the nodes are connected to the bus, which makes I2C not viable for applications like this. \$\endgroup\$ – Jack Creasey May 31 at 15:32

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.