Shop OBEX P1 Docs P2 Docs Learn Events
Remote relay control, async — Parallax Forums

Remote relay control, async

T!T! Posts: 17
edited 2006-10-28 15:40 in BASIC Stamp
THis is more of an attempt to ping an idea off folks than anything else.

I have a need to remotely control about 10 relays.· This needs to be done with minimal wiring between the two points, and confirmation of relay operation is not really required.· Preferably the wiring between the two points is a single twisted pair or a coax.

I must be able to select any combination of the 10 possible relays, from any single relay to all 10 on.

I realize I could do it with serial in between two Basic Stamps, and kick an ASCI character back and forth, each meaning a relay combination.· Or a number from 0000000000 to 1111111111.· But how can I do this without having a handshake between the two?· I just want to send from one, and receive on the other, setting the corresponding output pins on the receiving Stamp to high.· One way.

Does any of this make sense or am I missing something basic and easier to do?

T!

Comments

  • Mike GreenMike Green Posts: 23,101
    edited 2006-09-20 05:04
    There are some one-wire switches that are open-drain. The DS2406 comes to mind. It can sink 50ma and comes in a TO-92 (transistor) package. The one-wire protocol is not the fastest and you have to turn on/off the relays one at a time, but it does require only one wire other than the system ground and a supply line for the relay. If you've got decent power at the relay, you can use that. You can run the bus quite some distance (1000's of feet), but you would need a proper driver and cabling over that distance. Dallas Semiconductor has plenty of application notes on long distance one-wire busses since it's used for building temperature control.

    The later model Stamps all have built-in one-wire commands. Again, you would need an external driver for long distances or lots of devices.
  • Tom WalkerTom Walker Posts: 509
    edited 2006-09-20 13:16
    ...or if you want to go with the 2 Stamp idea, there is no need for a "handshake"...just have your relay-end (receiving) Stamp waiting for a serial message (there are multiple forum topics covering the gotchas and techniques) and activating te relays as required. Depending on the distance between the sender and receiver, this could be done with no more than two wires between them. (simple twisted-pair).

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Truly Understand the Fundamentals and the Path will be so much easier...
  • T!T! Posts: 17
    edited 2006-09-20 14:10
    Tom Walker said...
    ...or if you want to go with the 2 Stamp idea, there is no need for a "handshake"...just have your relay-end (receiving) Stamp waiting for a serial message (there are multiple forum topics covering the gotchas and techniques) and activating te relays as required. Depending on the distance between the sender and receiver, this could be done with no more than two wires between them. (simple twisted-pair).

    I think this probably defines what I was thinking of.· Keep in mind I am not hard and fast set on this idea yet, this is the early stages of seeing what might apply.

    I envision a two stamp solution.· Here is a simplified version of what I want to do.

    On one end is a stamp, it has (as an example, actual number may change) 10 toggle switches, each toggle is connected to a seperate·IN pin on·a stamp.· When the switch is on it provides +5 VDC to the IN pin, when off 0 VDC.· It kicks out a word or number corresponding to the on and off conditions of the switches.· Easiest might be something like 0000000000 to indicate all off, 1111111111 to indicate all on, and something like 0010000001 would indicate the third and tenth are on and all others off.· This number is in a one way stream, it only kicks the word out every once in a while not looking for any response.· Whether word is continually kicked out on a periodic basis or only a new word when conditions change does not matter, I assume since I do not want to handshake that continually kicking the word out would be best, that way a missed word would only be missed for one cycle.

    At the far end is another stamp.· It recognizes the word and sets the corresponding OUT pins to a high or low state as defined by the word.· These OUT pins can then be used to drive solid state relays or any other TTL style load using a buffer or driver if needed.

    The connection between the two locations needs to be a single twisted pair, or possibly a coaxial cable.

    Distances between the stamps are not far, possibly as much as 350 feet but maybe less.· The farthest part of my yard is only 370 feet from the house...lol

    Now I know I can do this kind of thing with 74 and 54 series TTL chips, I have done it before.· But, I thought it would be neet and fun to do it with stamps...and cheaper and more adaptable in the long run.

    I guess the important thing here is, am I trying to re-invent the wheel?· Does this kind of thing already exist as a single chip solution someplace?· Actually, even if it does exist I will probably play around with it anyway, just because.· Can someone suggest search criteria here on the forums that might help me grasp this and the concepts of it·a bit better?· I have done a bit with a single stamp, but never tried to make two of them respond to each other in any way.

    Thanks

    T!
  • willthiswork89willthiswork89 Posts: 359
    edited 2006-09-21 11:25
    i understand what your doing but i think if you told us really what your doing it would make a little more sense to us, is it a practical joke? a mailbox sensor? what is it going to be doing exactly? i understand that you need to communicate to one without really carrying if it gets the message. but why?

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    -Learn somthing about everything, and Everthing about somthing-
  • T!T! Posts: 17
    edited 2006-09-21 14:05
    willthiswork89 said...
    i understand what your doing but i think if you told us really what your doing it would make a little more sense to us, is it a practical joke? a mailbox sensor? what is it going to be doing exactly? i understand that you need to communicate to one without really carrying if it gets the message. but why?

    Pretty simple really.· The relays at the far end will turn on and off different small items, such as lights, motors, a solenoid for gas flow.· Open and close my electric gate (the control loop and sensors for this already work, I just need to take the place of·two momentary·switches).· One relay will shunt a signal from another system back into itself for zeroing of a positional error in a feedback loop.· All of that stuff already works, and is independent of the stamp application, I just want to be able to do·everything at a distance.· As you may be able to tell, I am thinking of several different applications and locations here, not just a single installation, one set for a project at work, one set for home, etc.· Everything I want to control already has some form of feedback, such as a character generated on a video overlay in one case, or you can see when the light comes on in another, or the camera already shows the gate, so it is more important to minimize the wire bundle than to get a response.· And, if I did not do it this way I would have to run at least one wire per relay I want to control.· Much better to have a single twisted pair than an 11 wire bundle to control 10 relays.

    T!
  • allanlane5allanlane5 Posts: 3,815
    edited 2006-09-21 14:21
    You can use a very simple byte-oriented protocol to implement this over 4-conductor, 2 twisted pair wire. You'll need a 'TX', 'RX', and 'GND' wire.

    The 'switch' BS2 will have a very simple program to read the switches and build the 'send' packet. The 'reciever' BS2 will have another very simple program to wait for the 'send' packet, validate it, and send those settings to its I/O pins.

    For reliability, I highly recommend a 'packet' approach. While you COULD send individual bytes, any communication channel is subject to 'noise', and you need some way of detecting when a garbled message has been recieved. This 'packet' can be as simple as "!101101011 <cksum>", though. (where 'cksum' is a simple sum of the bytes of the message, and the "!" is used as a 'sync' byte to insure the reciever got the start of the message.)

    The BS2 also has a very nice "DEC" modifier, which easily and simply converts a 'Word' value into a string for transmission. The reciever's DEC modifier converts the string back into a Word. So you could send:

    SEROUT 16, 16368, [noparse][[/noparse]"!", DEC MyVal, ",", DEC MyVal, "?"]

    And recieve as SERIN 16, 16368, [noparse][[/noparse]SyncByte, DEC NewVal, DEC NewVal2, EndByte]

    Then check that SyncByte == "!", EndByte == "?", and NewVal == NewVal2, and you KNOW you've gotten the value correctly.
    You MIGHT even send back from the Reciever an "A" to indicate it got the data correctly, or an "N" to indicate it didn't so the Transmitter would send the 'packet' again.

    Very simple, doesn't take much code, flexible for the future, very reliable.
  • T!T! Posts: 17
    edited 2006-09-22 18:58
    allanlane5 said...
    You can use a very simple byte-oriented protocol to implement this over 4-conductor, 2 twisted pair wire. You'll need a 'TX', 'RX', and 'GND' wire.

    The 'switch' BS2 will have a very simple program to read the switches and build the 'send' packet. The 'reciever' BS2 will have another very simple program to wait for the 'send' packet, validate it, and send those settings to its I/O pins.

    For reliability, I highly recommend a 'packet' approach. While you COULD send individual bytes, any communication channel is subject to 'noise', and you need some way of detecting when a garbled message has been recieved. This 'packet' can be as simple as "!101101011 <cksum>", though. (where 'cksum' is a simple sum of the bytes of the message, and the "!" is used as a 'sync' byte to insure the reciever got the start of the message.)

    The BS2 also has a very nice "DEC" modifier, which easily and simply converts a 'Word' value into a string for transmission. The reciever's DEC modifier converts the string back into a Word. So you could send:

    SEROUT 16, 16368, [noparse][[/noparse]"!", DEC MyVal, ",", DEC MyVal, "?"]

    And recieve as SERIN 16, 16368, [noparse][[/noparse]SyncByte, DEC NewVal, DEC NewVal2, EndByte]

    Then check that SyncByte == "!", EndByte == "?", and NewVal == NewVal2, and you KNOW you've gotten the value correctly.
    You MIGHT even send back from the Reciever an "A" to indicate it got the data correctly, or an "N" to indicate it didn't so the Transmitter would send the 'packet' again.

    Very simple, doesn't take much code, flexible for the future, very reliable.
    So, your recommendation is for a handshake and 4 wires in a more or less standard serial configuration?· I understand that what you have suggested is a low risk approach, in fact darn near fool-proof.· Again, this is not impossible for my application, but I was hoping for a two wire, one way, solution.· I had planned on something like what you have described if no one came up with something interesting to try in a one way scheme.

    Yes, I know there is a greater danger of lost data, and that I do not mind.· I would like to have a solution that results in a good data packet making it into the system at least 4 times a second, preferably 10 times a second.· What I want to avoid is implementation, or use to control relays,·of a bad data packet.· I don't care if packets have to be thrown out in a one way scheme, but bad data should never set a relay that was not commanded.

    T!
  • Mike GreenMike Green Posts: 23,101
    edited 2006-09-22 19:24
    You could use a one-way serial system and use redundancy in the data packets. Use a packet as suggested before with a sync character like "!", a decimal number (using the DEC formatter), then a comma, then another decimal number which must be the complement of the first, then a closing character. Using the complement gives you some more redundancy. Using ASCII digits rather than a binary value gives you some more redundancy. If the packet isn't correct, throw it away. The master (sender) resends the packet periodically with the current state of the relays. There are lots of other variations on the redundant packet idea. You could send a sync character, then a sequence of letters with an A or Z in the first position, B or Y in the second, C or X in the third, etc. representing the different relays. Two possible choices gives you on/off. The letters must be in the proper sequence or the packet is ignored. There's not just a single bit difference between on and off. There must be an end character. You could even add a checksum character at the end.
  • Bruce BatesBruce Bates Posts: 3,045
    edited 2006-10-04 09:48
    T! -

    There is a mailbox sensor project in the June 2006 issure of Nuts and Volts Magazine on Page 44.

    Regards,

    Bruce Bates

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    <!--StartFragment -->
  • T!T! Posts: 17
    edited 2006-10-24 02:00
    Just a follow up here.· I went ahead and did what I initially described, just as a thing to do, if nothing else.· Yes, I know a serial ASCI string could have done it, but I wanted to try something different.

    The control end of the software:

    ' {$STAMP BS2e}
    '

    ' Program Description
    '
    ' 10 control bits and switch inputs
    ' Timings all adjusted
    '
    ' I/O Definitions
    '


    TrgPls········· VAR···· OUT0·············· 'Trigger pulse on pin 0
    InfPls······· ·· VAR···· OUT1·············· 'Information pulse on pin 1
    InfS1·········· VAR···· Byte
    InfS2·········· VAR···· Byte
    InfS3·········· VAR···· Byte
    InfS4·········· VAR···· Byte
    InfS5·········· VAR···· Byte
    InfS6·········· VAR···· Byte
    InfS7·········· VAR···· Byte
    InfS8·········· VAR···· Byte
    InfS9·········· VAR···· Byte
    InfS10········· VAR···· Byte
    InfS11········· VAR···· Byte
    InfS12········· VAR···· Byte
    AcqChk········· VAR···· Byte
    FireChk········ VAR···· Byte
    FireChkCount··· VAR···· Word··············
    CageChk········ VAR···· Byte
    CageChkCount··· VAR···· Word



    '
    ' Initialization
    '


    Initialize:
    · DIR0 = %1····························· ' make pin output, this is for the trigger pulse
    · DIR1 = %1····························· ' make pin output, this is for High and Low confirmation pulses and switch data pulses


    · AcqChk=0
    '

    ' Program Code
    '



    Main:

    · INPUT 2······························ ' sets as inputs pins 2 to 11, these are the control switches
    · INPUT 3
    · INPUT 4
    · INPUT 5
    · INPUT 6
    · INPUT 7
    · INPUT 8
    · INPUT 9
    · INPUT 10
    · INPUT 11
    · INPUT 12


    · InfS1=IN2···························· ' Makes variable InfSx equal to switch states
    · InfS2=IN3
    · InfS3=IN4
    · InfS4=IN5
    · InfS5=IN6
    · InfS6=IN7
    · InfS7=IN8
    · InfS8=IN9
    · InfS9=IN10
    · InfS10=IN11
    · InfS11=IN12························· 'bit to reset shot/acq/fire status


    · TrgPls = 1·························· ' generates trigger pulse output on pin 0
    · PAUSE 3
    · TrgPls = 0
    · PAUSE 3


    · InfPls = 0·························· ' check (confirmation) pulse low, output on pin 1
    · PAUSE 3
    · InfPls = 0
    · PAUSE 3


    · InfPls = 1·························· ' check (confirmation) pulse high, output on pin 1
    · PAUSE 3
    · InfPls = 0
    · PAUSE 2


    · InfPls = InfS1······················ ' first relay control pulse (switch data), output on pin 1
    · PAUSE 3
    · InfPls = 0
    · PAUSE 2


    · InfPls = InfS2······················ ' second relay

    · PAUSE 3
    · InfPls = 0
    · PAUSE 2


    · InfPls = InfS3······················ ' third relay
    · PAUSE 3
    · InfPls = 0
    · PAUSE 2


    · InfPls = InfS4······················ ' fourth relay
    · PAUSE 3
    · InfPls = 0
    · PAUSE 2


    · InfPls = InfS5······················ ' fifth relay
    · PAUSE 3
    · InfPls = 0
    · PAUSE 2


    · InfPls = InfS6······················ ' sixth relay
    · PAUSE 3
    · InfPls = 0
    · PAUSE 2


    · InfPls = InfS7······················ ' seventh relay
    · PAUSE 3
    · InfPls = 0
    · PAUSE 2


    · InfPls = InfS8······················ ' eighth relay
    · PAUSE 3
    · InfPls = 0
    · PAUSE 2


    · GOTO LastTwo

    Pause10:

    · PAUSE 14
    · AcqChk=0
    · FireChk=0
    · CageChkCount=0


    · GOTO Main

    Pause5:

    · PAUSE 6
    · FireChk=0
    · FireChkCount=0
    · GOTO Main


    Pause3:

    · PAUSE 2
    · GOTO Set9


    Pause2:
    · PAUSE 1
    · GOTO Set10


    LastTwo:

    · IF InfS11=1 THEN Pause10
    · IF InfS1=0 THEN Pause10
    · IF InfS2=0 THEN Pause10
    · IF AcqChk=1 THEN Pause3
    · IF InfS9=0 THEN Pause10
    · IF InfS9=1 THEN CageCheckCount



    LastOne:

    · IF FireChk=1 THEN Pause2
    · IF InfS10=0 THEN Pause5
    · IF InfS10=1 THEN FireCheckCount



    Set9:

    · InfPls = 1······················ ' ninth relay
    · PAUSE 3
    · InfPls = 0
    · PAUSE 2
    · GOTO LastOne


    Set10:

    · InfPls = 1····················· ' tenth relay
    · PAUSE 3
    · InfPls = 0
    · PAUSE 1


    · GOTO Main

    AcqCount:
    · AcqChk=1
    · GOTO Set9


    CageCheckCount:··························· 'Checks that you really mean to set Acq bit, no single pulse glitch setting the latch condition

    · CageChkCount=CageChkCount+1
    · IF CageChkCount>3 THEN AcqCount········· ' Must hold momentary Acq toggle on for 3 cycles, about 1/3 sec


    · PAUSE 14
    · GOTO Main


    FireCount:
    · FireChk=1
    · GOTO Set10


    FireCheckCount:···························

    · FireChkCount=FireChkCount+1
    · IF FireChkCount>3 THEN FireCount········ 'Must hold momentary button on for 3 cycles, about 1/3 sec
    · PAUSE 5
    · GOTO Main



    · END

    And then the receive end of the software.

    ' {$STAMP BS2e}
    '

    ' Program Description
    '

    ' Looks for 10 S bits

    '
    ' I/O Definitions
    '

    S1············· VAR···· OUT2·················· 'Relay drive signal
    S2············· VAR···· OUT3·················· 'Relay drive signal
    S3············· VAR···· OUT4·················· 'Relay drive signal
    S4············· VAR···· OUT5·················· 'Relay drive signal
    S5············· VAR···· OUT6·················· 'Relay drive signal
    S6············· VAR···· OUT7·················· 'Relay drive signal
    S7············· VAR···· OUT8·················· 'Relay drive signal
    S8············· VAR···· OUT9·················· 'Relay drive signal
    S9············· VAR···· OUT10················· 'Relay drive signal
    S10············ VAR···· OUT11················· 'Relay drive signal

    X·············· VAR···· Byte

    '
    ' Initialization
    '

    Initialize:
    · DIR2 = %1···································· ' make pin an output
    · DIR3 = %1
    · DIR4 = %1
    · DIR5 = %1
    · DIR6 = %1
    · DIR7 = %1
    · DIR8 = %1
    · DIR9 = %1
    · DIR10 = %1
    · DIR11 = %1
    · DIR13 = %1
    · DIR14 = %1

    · INPUT 0······································ ' Trigger pulse input
    · INPUT 1······································ ' Confirmation pulses and data pulses input


    '
    ' Program Code
    '


    Main:
    · S1 = 0······································· ' Sets all relays to off on initializaton or if no trigger pulse
    · S2 = 0
    · S3 = 0
    · S4 = 0
    · S5 = 0
    · S6 = 0
    · S7 = 0
    · S8 = 0
    · S9 = 0
    · S10 = 0

    StartInf:······································· ' Looks for trigger pulse
    · FOR X = 1 TO 20······························· ' If no trigger pulse goes to Main after 20 tries
    · IF IN0 = 1 THEN StartChk
    · NEXT
    · GOTO Main

    StartChk:······································· ' Confirms that Low Check is there
    · PAUSE 6······································· ' If no Low Check goes back to StartInf
    · IF IN1 = 0 THEN ConfReal1
    · GOTO StartInf

    ConfReal1:······································ ' Confirms that High Check is there
    · PAUSE 7······································· ' If no High Check goes back to StartInf
    · IF IN1 = 1 THEN CheckSwitches
    · GOTO StartInf

    CheckSwitches:·································· ' Checks Switch Data pulses
    · PAUSE 5
    · S1 = IN1······································ ' Sets relay condition equal to switch position
    · PAUSE 6
    · S2 = IN1
    · PAUSE 5
    · S3 = IN1
    · PAUSE 6
    · S4 = IN1
    · PAUSE 5
    · S5 = IN1
    · PAUSE 6
    · S6 = IN1
    · PAUSE 5
    · S7 = IN1
    · PAUSE 6
    · S8 = IN1
    · PAUSE 9
    · S9 = IN1
    · PAUSE 8
    · S10 = IN1
    · GOTO StartInf

    · END

    I am sure the code could be cleaned up a bit, but this works for me.· Basically the timing works out so that everything happens about 11.5 times a second, and my goal was updates every 100 msec or faster, so it works for me.· Using something like a 2px would speed things up a lot, but it is not needed for my use.

    From the control end, a trigger pulse is sent from Pin 0, this starts the timing for everything.· The data is sent on Pin 1, but before the 10 switch positions are sent a low is sent and checked, and a high is sent and checked, just in case the line is broken.· Assuming the low and high check bits are good the program then reads the 10 control bits and sets the relays.

    The first picture attached (TEK0000) shows the trigger pulse (yellow trace), low check and high check only (blue trace), all switch bits are low, as all switches are off.· The second picture (TEK0001) shows all switch bits set high, as all switches are on (blue trace).

    T!

    Post Edited (T!) : 10/24/2006 7:40:03 PM GMT
  • T!T! Posts: 17
    edited 2006-10-28 15:40
    Of course, after you do something you always can find a better way to do it...lol

    I now realize several of my variables should have been Bits vs Bytes, and Bytes vs Words.

    Also, I could have shortened up the pulses using PULSEOUT vs turning the pin on and off.



    What I don't know, is how would I have detected the shorter pulse position·as a function of time after trigger?



    T!
Sign In or Register to comment.