Extending programming distance

Jonathan

Hi All,

I want to be able to program a prop from the PC in my house to about 50' away at my solar power/ battery bank. I have a phone wire run out there, 4 conductors. Round trip resistance is about 2.5 ohms on each pair.

Just hooking up a Prop clip won't work, not suprising. Anyway to boost the distance with simple hardware? I took a look for a bootloader that might allow me to send a program via serial coms, but didn't see any such thing.

Thanks!

Jonathan


▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.madlabs.info - Home of the Hydrogen Fuel Cell Robot

Jonathan

Leon,

How about RS232? I have some chips laying about for that.

Jonathan

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.madlabs.info - Home of the Hydrogen Fuel Cell Robot

Mike Green

RS232 should work fine. If your PC doesn't have an RS232 com port, you could use a USB to RS232 adapter. I know the Keyspan High Speed Serial Adapter works. On the Prop side, you could either use the 3-transistor adapter shown on the Prop schematics webpage or a MAX3232 RS232 to 3.3V logic level converter.

Jonathan

Mike,

So, can I connect my propclip to the PC and run the RES/TX/RX lines from the clip into the inputs of the RS232, output RS232 connected to phone line, then another RS232 on the other end with 1k resistors from the RS232 to the RES?TX?RX lines on a protoboard? Would I even need to do the RES line?

Jonathan

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.madlabs.info - Home of the Hydrogen Fuel Cell Robot

Mike Green

No, you don't use a PropClip with what I have in mind. Your PC needs to provide an RS232 com port, either one that's built-in or, if your PC only has USB, then you need a USB to RS232 adapter like the Keyspan one I mentioned. You then run the RS232 TX, RX, and DTR signals along with a ground through your 4-wire cable to the Propeller where you use either a MAX3232 RS232 to 3.3V logic converter or the 3-transistor RS232 serial to Prop adapter shown on the Propeller schematics webpage.

You need the RES line at the Propeller for programming and you need the RS232 signal levels on the long cable.

You could use a MAX3232 with a PropClip to convert to RS232 signal levels, then use another MAX3232 at the Propeller end to convert back. You'd need to carry TX, RX, and RES. The MAX3232 has a pair of transmitters and a pair of receivers, so you'd use 3 out of the 4 at each end.

Another alternative would be to use RS485 transceivers, but that would need 3 twisted pairs in the cable between the PC and the Propeller.

Post Edited (Mike Green) : 1/7/2010 8:18:38 PM GMT

Jonathan

Mike,

The second scheme is what I had in mind. I have a couple of MAX3235's. If I put a series resistor to the Prop from the RS232, that should work, right?

Thanks for the help!

Jonathan

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.madlabs.info - Home of the Hydrogen Fuel Cell Robot

Mike Green

No, you need the MAX3232 at the Propeller end as well. The download protocol is bidirectional. The Propeller has to reliably talk to the PC as well and you need the RS232 voltage levels to maintain a reliable connection over the 50' distance. The same is true for the RES line. If you just use a series resistor, you run the risk of the Prop resetting on every little noise pulse coming along. A series resistor has to be large enough to limit the current into the Propeller if you accidentally connect the wire to a source of voltage above 3.3V. For an accidental 12V connection, you'd need about 24K. That along with stray capacitance can slow down signalling on the line, maybe not enough to cause problems, but you'd be better off using a MAX3232 for RES as well.

VIRAND

Oh no, Not more short wire problems!

Ideas: (ALL GOOD HUMOR INTENDED!)
Do you think it might work if you run a phone extension and connect two old Hayes modems to it?
How about wi-fi and a laptop? Fiber optics?

Behold, the Miracle! Heaven has cursed the Copper Headed Serpent, which hath stretched its great Coil around
the earth, to listen to the seas, and to speak to the other seas. Nevermore shall this serpent hear words in one place
and speak them in another, nor shall it even rattle its tail! It tried to squeeze the earth like a boa constrictor,
and bind it like spider's silk, and spill blood. But now even divided into many small ones, it is deaf and dumb,
and turning into moss, and its evil spirit whispers only silence. In this millenium, the dark days of the Talking Snake
Uncoiled will be remembered with amazement, at how its own Blue Venom fell down from the sky upon it,
and it became blue, and fire becomes blue as it burns. Speak to the Copper Snake, Listen to the Copper Snake,
Remember how it used to Talk, and Marvel at its Silence!
( IOW... Hmm. Wires don't work anymore. {shrug} )

Jonathan

Mike,

I know I need two RS232 chips. In fact, I have them here on the desk and, according to my Propscope, working fine. However, when I try to use the connection to program, no joy. I can't even substitute one line from the direct propclip connection successfully. Looking at the scope, with one probe on the propclip output and one one the 232 output, they seem the same. The circuit shares a common ground. I can't think why it doesn't work. The sreies ressitor mentioned above is just to protect the Prop from the 5V of the 232.

Off for a grueling 48 shift. I'll check back here when I'm done.

Jonathan

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.madlabs.info - Home of the Hydrogen Fuel Cell Robot

Mike Green

I don't know if the PropClip is 5V tolerant. You may have damaged the PropClip by trying to use it with a MAX3235 with its 5V output.

The scheme you described should work. Since it doesn't, there must be something else going on. There's not enough delay in the MAX3235s to affect the download protocol.

Beau Schwabe

I think the biggest problem at that distance could be propagation delay and insertion loss. Using a different type of cable such as CAT5 instead of phone cable "might" help with the insertion loss, but your propagation delay in just the wire alone there and back is going to be about 167ns (About 6MHz) adding any kind of buffer/amplifier on either end will definitely help to overcome the insertion loss, but now the problem introduced is the propagation delay within the buffer/amplifier itself. For example a 74HC14 would work at 5V but not at 3.3V since at 5V the propagation delay of the 74HC14 is about 21ns increasing the total round trip propagation delay to about 209ns (about 4.78MHz) while at 3.3V the propagation delay of the 74HC14 is about 75ns increasing the total round trip propagation delay to about 317ns (about 3.15MHz)

Since the transmitted signal during programming is about 2MHz (Jeff Martin should confirm this), the 74HC14 example fails at 3.3V due to Nyquist stating that the frequency capability should at least be twice what you are sampling.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Beau Schwabe

IC Layout Engineer
Parallax, Inc.

Mike Green

The boot downloader (on the PC side) was described by Chip as running at 115200 Baud which would leave plenty of time for the propagation delay through the MAX3235s. On the Prop side, the speed of the bootloader is set by the received sync codes (from the PC) since the system clock is not accurate using RCFAST.

Beau Schwabe

Mike Green,

Ok, I wasn't sure, I seem to remember Jeff mentioning that there were some tricks that he did to make the effective throughput much faster though.

That being the case (115kBaud), I would try two 74HC14's on both ends to see if that would clean the signal up enough

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Beau Schwabe

IC Layout Engineer
Parallax, Inc.

Jeff Martin

The PC side (Propeller Tool and Propellent Library/Executable) is running at 115.2k baud, as Mike suggested.· The only other factors at work here are timeout constraints:

• The Propeller times out if the delay between two bytes (say, in the identity stream for example) is 100 ms or greater.
• Similarly, Propeller Tool / Propellent will timeout after 100 ms of no response from the Propeller.
• The reset signal generated is 25 ms in width.

Those delays are plenty high enough, based on the discussion so far, to accomodate the transfer.

I'd suspect some kind of noise,·loss, or wiring problem·introducing itself along the way.

Cat 5 cable is wound at very strict specifications to support extreme communication speeds; it may be final part of the equation you need.

If it's proving not possible using the current methods might I suggestion that over really long distances though (not sure if this qualifies)·a differential protocol may be best since it is much more reliable and immune to noise.· RS422 or RS485.



Regarding Beau's memory:· We tried higher speeds, and it definitely works under the right conditions, but there is too much likelyhood of problems caused by process variations in various environments to justify it, so we bumped it back down to the original-spec of 115.2 k baud.




▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Jeff Martin

· Sr. Software Engineer
· Parallax, Inc.

Post Edited (Jeff Martin (Parallax)) : 1/8/2010 6:43:07 PM GMT

Dr_Acula

115k is pretty fast. Back in the olden days when you had a computer and a terminal connected with RS232, and maybe 3-4 metres of cable (unshielded, seperate wires, all in a bit of a tangle) I had trouble going over 9600 baud.

Even now with my PC talking to other things using 4 metres of 9 way ribbon cable I'm struggling to get over 38400 baud. (1200 on the other hand can go 500 metres or more)

Ribbon cable isn't the best, and certainly it could be improved with every alternate line grounded, or twisted pairs etc. But I think for long runs 115k is going to be very dependent on the type of cable, shielding etc.

For a start try cat5/6 as suggested.

Then maybe it is going to be a matter of a small .net program (or anything really) on the PC spitting out character U (01010101) continuously and snake the cable round the shed and scope the other end and see how square the edges are.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller

localroger

You're going to have a problem because no matter what you do you'll have two signal wires wrapped around·each other·in a pair. Instead of the signal and ground twists cancelling out noise, the twisted-together signals will capacitively couple, causing interference.

You might be able to get away with twisting RES around TX or RX. For best results -- and this is also true if you are using RS232 -- you need TX, RX, and RES all twisted around a GND. All the GNDs are connected together at one end, only one at the other to avoid ground loops. Of course it's better if you're using individually shielded pair instrumentation cable, but at 50 ft cat3 phone cable should be fine even with TTL. If you had run cat5, even though you don't need its tighter twistiness, you'd have another pair to twist RES around GND and you'd be OK.

The other thing you can do (which isn't too hard since, unlike IIC, all the signals are unidirectional) is to convert them all to a current signal with a NPN transistor transmitter at one end and an optoisolator (LED+photogransistor in a sealed enclosure) at the other. This will give you a robust signal that can be driven for miles while ignoring what's twisted around what.

kwinn

I am surprised anyone uses RS232 drivers any more unless one has to connect to legacy equipment. RS422/485 drivers can be used in their place with the same signaling protocol and has the advantage of not requiring a +/- power supply. There are driver chips that can run directly from the single 3.3V or 5V power supply. On top of that it can be done at much higher speeds and greater distances.

BradC

Jeff Martin (Parallax) said...

Regarding Beau's memory: We tried higher speeds, and it definitely works under the right conditions, but there is too much likelyhood of problems caused by process variations in various environments to justify it, so we bumped it back down to the original-spec of 115.2 k baud.

I've played with this a _lot_. The speed spread of the propeller under an RC oscillator is still fast enough to cope with 230.4k downloads, but when the clock slows right down (as it does when you heat the propeller up) you run into problems at the end of each transmitted long when the bootloader goes to write it to the hub. The simple answer to this is to make sure you have an extra pause bit at the end of each long to allow the prop to catch back up.

After implementing this, I managed to do about 10,000 consecutive reliable loads to a propeller sitting at an ambient temperature of 80 degrees C, whereas it would routinely fail prior to adding the extra pause.

Of course if you slow it down to 115.2k it works all the time too.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Life may be "too short", but it's the longest thing we ever do.

localroger

kwinn, RS232 has the considerable advantage that when it isn't working, you can readily troubleshoot it with a voltmeter. Ditto 20 mA current loop. But the valid range of RS422 voltages is so wide that a transmitter can be hosed or a receiver shorted and you can't tell it from a working port.

kwinn

@localroger, No argument about 20mA current loop being very simple to troubleshoot as well as being a very reliable data transmission method but I have never had any problem finding a hardware fault on an RS422/485 driver with a multimeter or even a simple home brewed single led logic probe. Even for problems with the data I have rarely needed more than a simple probe built using a high speed comparator and a serial port or USB to serial adapter and a computer.
The only problem area I have found is on multistation systems when you have a shorted driver or receiver somewhere, and that would be the same regardless of the physical protocol.

PS - in this case I would have used current loop signaling with opto isolators for safety since there were only four wires for the signals. A common ground, Rx, Tx, and res on individual wires.

Post Edited (kwinn) : 1/9/2010 3:17:24 PM GMT

hippy

Lower baud rates are likely to have less issues than faster and a home-grown loader can program the Propeller at fairly low speeds. I recall getting download to work at 4800 baud, possibly lower. Minimum speed depended on OS and the pacing of data sent. It's also possible to get packing density of downloads better than the simplistic '11 bytes for 32 bits' to gain some increase in speed.

Unfortunately the PropTool doesn't have selectable baud rate nor any hooks for invoking a third-party loader instead of the default so using a separate loader isn't as smooth as it could be.

sderyck

Mike Green,
I was surprised to see the 3 transistor circuit you referred to at the Prop schematics web page. I found a 2 transistor circuit that I'm sure I worked on out of a prop manual somewhere (can't find it now but i still have the JPG of the circuit, see attached). Could never get to work for downloading. I had taken the RESn components out and it works fine for up and down serial communication on a com port.

well anyway,
have you ever used the 3 transistor circuit successfully, or know anyone else who has?

Thanks

sderyck

I found the manual that had the 2 transistor setup on the Parallax website here
http://www.parallax.com/tabid/442/Default.aspx
It's the PropellerDatasheet-v1.2.pdf
I could never get this to work for downloading into the prop
after I removed the connection between RESn and DTR, including capacitor and 4.7ohm resistor connected to Rx(2) the circuit has worked fine as a com port communication portal and I don't have to worry about closing hyperterminal or Parallax Serial Terminal communications

so... should this 2 transistor circuit have worked?
if not
then should this manual be updated and replaced on the web?

can anyone confirm the 3 transistor circuit worked for them