Serial control problem

[JackMan]

Now that Halloween 2012 is over, I'm re-doing a few things in the controls for my Haunted Graveyard Show. One of the changes is how I'm controlling the AP-16+ in Captain Jack. He is my show opener and closer in addition to having a random comment in the middle of the show. I was triggering the AP-16+ with 2 relays for AUX files and also using the voltage input trigger for random SFX files but I needed to free up some outputs on a Prop-1 so I have switched the program to serial control of the AP-16+. I was using about 35' of 4 conductor phone cord with the relays and the voltage input trigger which worked flawlessly for 3 seasons. Now that I changed the program to serial control I'm having issues. I tested my program several times with a short serial connection (12") and it works fine everytime but when I go with the 35' phone cord it's hit or miss. My Prop-1 program does not have a trigger, the code initiates each time the Prop-1 is powered up. The AP-16+ is powered up all the time so that's not the problem. I have the usual PINS, DIRS under RESET and then the first line of code under MAIN is a SEROUT for Captain Jack to start the show. I'm guessing that maybe due to the immediate power up and the long wire length that the Prop-1 isn't able to send the command properly? Can I just double up the SEROUT command to be sure it gets through? I really don't want to add a PAUSE at the beginning but maybe I'll need to.

[bsnut]

The wire length is killing you. RS232 is good under 25 feet and since you want to go more than 25 feet, you may want to do RS485.

[JackMan]

 There are 2 more serial commands later in my Prop-1 program and they both seem to work fine, it's just the first one at the very beginning that's hit or miss. On another prop I have 50' of phone cord connecting my HC-8+ serial output to MiniSSC's and it works perfectly.

[bsnut]

Ok, since the problem isn't the wire length, you may want add the Pause command at the very beginning to see if that works. I know you don't want too, but it gives the Prop-1(Basic Stamp 1) a chance to power up.

[JackMan]

Well, that seems to be the issue. I added a 2 second PAUSE in Initialization and so far it works every time. I still don't understand why it worked with a short serial cable without the PAUSE.  ???

[bsnut]

Well, that seems to be the issue. I added a 2 second PAUSE in Initialization and so far it works every time. I still don't understand why it worked with a short serial cable without the PAUSE.  ???

The Pause command is giving the Propeller chip (the AP-16+ brains) a chance to receive the whole serial packet from the Prop-1, since you are pushing the limits of RS232.

Also, I found this on Wikipedia http://en.wikipedia.org/wiki/RS-232 on RS-232 which should help you answer part of your question that you have about why it may be better at short lengths over longer lengths of cable. I was kind of surprised :o myself and understand why you are able to go the distance that you did with phone cable.

The standard does not define a maximum cable length but instead defines the maximum capacitance that a compliant drive circuit must tolerate. A widely used rule of thumb indicates that cables more than 50 feet (15 m) long will have too much capacitance, unless special cables are used. By using low-capacitance cables, full speed communication can be maintained over larger distances up to about 1,000 feet (300 m). For longer distances, other signal standards are better suited to maintain high speed.

[JackMan]

OK, I understand all of that and it makes sense but without the 2s PAUSE the Prop-1 is obviously able to send the serial command because it works with a short cable. The only thing the 2s PAUSE does is to allow a little extra time for the Prop-1 to power up before that command is sent, it doesn't extend the time it takes to actually send it.

[JackMan]

Hey Jon,
   Any thoughts on this?

[JonnyMac]

We have to remember that we're not actually running RS-232 here, we're running TTL level serial.  The problem with long lines is signal loss and capacitance which can re-shape the signal. 

Suggestions: If you're going to run more than about 10 feet you should...
-- use much bigger wire size than you think necessary
-- use shielded cable (connect shield to ground)
-- slow the baud rate down (this helps either end tolerate the signal shaping)

I think it's the phone wire that's killing you here.  If you consider the circuit what you have is a voltage divider formed by the resistance of the serial line and a 10K pull-up on the receiver.  When the transmitter pulls the line low current flows a line with a lot of resistance (e.g. your phone cable) may not allow the RX input to be pulled low enough to create a "0" bit (the pull-up takes care of the "1" bit when the line is floated by the transmitter).

Funny... I've been fighting these wire size things my whole career. When I worked for Toro I was flown to Germany to troubleshoot the irrigation control system which used a number of controllers on a multi-drop setup (just like our serial control).  Instead of using the prescribed shielded twisted pair, the contractor used... yep, four conductor phone cable.  It was an expensive mistake on the part of the contractor. 

Bump your wire size and remember that a long wire acts like an antenna so noise could be an issue, hence the recommendation for shielded wire.

[JackMan]

Well, the wire length/size was my first thought also but why does it work after I added a 2 second PAUSE in Initialization? That's what I don't understand.  ???

[JonnyMac]

Again, that big long line is acting like a capacitor, especially in phone cable where the wires lay side-by-side. I suspect the delay is allowing this capacitance to be discharged by the system while in the idle state. 

Let me re-state: TTL level serial is not intended for more than a few feet. You're going the speed of sound without a seat belt -- be careful!  ;D

Somewhere in the forums (I'll find it) I posted a schematic for converting the TTL serial to RS-485 on both ends; it's pretty easy to do though you are limited to one direction with the circuit. For bidirectional comms there are chips made for extending I2C signals (which work the same as open-mode serial) and that might be worth looking into.  What you don't want to have is a condition that is not reliable.

[JackMan]

Yeah, I'd be interested in that schematic. I have 50' of phone cable connecting the serial output of my HC-8+ to the MiniSSC's in my Thriller prop and it worked flawlessly for 6 weeks, is that different in some way?

[JonnyMac]

It is a little different because the HC-8+ TTL outputs are using drivers which provide a bit more oomph to the signal than the open-collector mode we use. In the latter you have a moderate impedance connection (10K) to 5v; with driven (HC-8+) you have a low-impedance connection which can overcome the line capacitance.

I found the thread where this topic came up before:
-- http://www.efx-tek.com/php/smf/index.php?topic=1121.msg6336#msg6336

[bsnut]

I almost forgot about this thread and thanks to Jon for jumping in on this thread.

I found the thread where this topic came up before:
-- http://www.efx-tek.com/php/smf/index.php?topic=1121.msg6336#msg6336

But, if you want to make your own it would be easy to do. This company from what I can tell from there website they sell them and you can order a sample of this chip. They also have these in the DIP package form.
http://www.intersil.com/en/products/interface/serial-interface/rs-485-rs-422/ISL8485.html

Sorry for not being able to answer all your questions that you had Jack. But, you give me an idea for something else that I was working on.

[bsnut]

BTW, I forgot to provide the datasheet for ISL8485 that is shown in Jon's drawing.
http://www.intersil.com/content/dam/Intersil/documents/fn60/fn6046.pdf