Trouble using SHIFTOUT over 10ft cable

michael75

I have placed a DS1620 temperature sensor in a sealed capsule and connected the nessesary pins to talk to a BS2 board to a 10ft CAT5 cable (the intent is its going in the pool, but thats not important). I have another temperature DS1620 directly on the BS2 breadboard and working, but it seems the one connected to the cable is not give believable results. I have checked over the wiring and the coding to look for mistakes, but i think its just having trouble communicating data over the length.

Can I slow down the SHIFTOUT clock rate somehow in hope of getting a better signal or is 10ft just too far?

Thanks,
-Mike.

Duane Degn

I've read you can use longer data transmission wires with slower data rates so slowing down the SHIFTOUT rate might help.

I recently read an application note about how to use SPI over long wires more reliably. The information in the apnote might help you.

It's on this page of the ams website. Look under "Application Notes" for "AN5000_SPI interface_v1_0". You can download the pdf from there. It shows how to add capacitors and resitors to get a better signal through the wires.

Another option would be to use a shielded cable with the shielding connected to ground on the BS2 board (I don't think the shielding should be connected to ground on the sensor end).

Have you tried having your signal wire paired with the ground wire as a twisted pair within the Cat5 cable? What about connecting all the unused wires in the Cat5 to ground? (I'm not sure if this last suggestion would help.)

If none of the above work, you could try RS-485 communication. This would require some additional chips and the sensor might need its own microcontroller to use the RS-485 chip.

Another option I can think of would be to have MAX232 chips at both ends of the wire to use RS-232 logic levels. I doubt RS-232 would work better than RS-485 though since RS-485 uses a balanced pair of wires so noise gets canceled out.

I think there are other alternatives as well, but I don't have enough experience to know what to recommend.

It seems like 10ft isn't too excessive but I have a barcode reader that outputs a 5V TTL signal at 2400 baud and my uC can't read the signal if the line is longer than about 6ft.

Hey, I just noticed. This is post #1 for you. Welcome to the forum. I hope you keep us updated on your project.

Phil Pilgrim (PhiPi)

Resistive termination at both ends of the cable will help, too. Try 4.7K pull-ups to start with.

-Phil

davejames

michael75 wrote: »

Can I slow down the SHIFTOUT clock rate somehow in hope of getting a better signal or is 10ft just too far?

Hi Mike - welcome to the Forum!

I'd suggest something like:

http://cds.linear.com/docs/Datasheet/491fa.pdf

Going the differential method allows both increased drive capability and noise immunity.

I'm looking to do the same thing in a product where the "brain" could be multi-tens of feet from the "controller".

Tracy Allen

The DS1620 is susceptible to power line noise and I have seen this problem before. Do you have a good (1 µF) capacitor across its power supply pins right at the chip, inside the capsule? With that it should work okay on a 10ft cat5 cable.

The BS2 Stamp SHIFTOUT has a bit period of 60µs, 16.67 kHz. Even with 1000Ω source resistance, the line delay due to cable capacitance (~350pF) would be less than a microsecond, so that should not be an issue. For the BASIC Stamp SHIFTOUT and SHIFTIN commands, the line is actively driven both high and low.

davejames

Mr. Tracy,

That approximate capacitance is what has me worried about the DS1620 being reliable.

http://pdfserv.maxim-ic.com/en/ds/DS1620.pdf

There's note #10 on page 12 muttering about "50pF load capacitance". There's no mention if that was the test criteria or an actual specification. And there's no max capacitance load spec in either the DC or AC sections.

I'm guessing that this part was never intended to be hangin' out by 10 feet.

Tracy Allen

The 50pF appears as a test condition for "CLK to Data Delay" in the AC characteristics on page 11, note #10. And that refers to the timing diagram on page 9.

What it is saying is, with a 50pF capacitor loading the DS1620 data line, there is a maximum of 150 nanoseconds of delay from the high to low clock edge to the point at which the data output from the DS1620 is valid. Don't read the data during that 150ns. Extrapolating, the delay with a 350pF capacitor would be on the order of 1 microsecond. Not a problem with the Stamp. I don't know exactly when it reads the data line after the clock pulse, but I'd guess it is something like 40 or 50 microseconds into its SHIFTIN clock period of 60 microseconds, plenty of time for the data line to stabilize.

Not meant to be hanging out on the end of a cable, yes to that, but even more so for i2c and one-wire with their passive pullup resistors. People have those hang out all the time, and the time slots for one-wire are also around 60µs.

davejames

Tracy Allen wrote: »

The 50pF appears as a test condition for "CLK to Data Delay" in the AC characteristics on page 11, note #10. And that refers to the timing diagram on page 9.

...um, I guess I didn't express my thought correctly. Yes, I see what you are saying.

I was attempting to express my concern that the DS1620 could even drive the capacitance of the 10 foot cable. Granted, the data sheet say 4mA for Iol and 1mA for Ioh, but I don't see that as being enough. I guess if it works, it works. But I'd rather scope the circuit with cable included and check the data edges coming from the DS1620 to make sure they are meeting the Stamps input requirements. I'm not too concerned with the Stamp-to-DS1620 end of things as it has 20mA drive capability.

Dave Hein

I don't know the protocol that used with the sensor, but I assume it's clock and data. Did you make sure that your using a twisted pair for each signal? You could be getting some common-mode noise if not.

michael75

I have a .1 mF cap already connected between VDD and VSS directly under the DS1620 at the end of the cable. I don't really want to add more logic at the senor end than I have to because its really just a temperature probe that is sitting in the pool. I think the next step is trying out the capacitor/resistor pairs that someone suggested.

Then again, is there a better chip to use than a DS1620 for this kind of application?

Tracy Allen

Here is a link to a project where the DS1620 was out on 100 feet of CAT5 cable, with problems, and with marginal success. Unfortunately there is not a followup on how it turned out in the end.

I see I suggested the capacitor there too, 4.7µF or 10µF, also that the chip be accessed in single-shot rather than continuous mode.

My suggestion of the extra capacitor comes from working with a company that was installing the DS1620 in a vending machine, out 3 or 4 feet from the microcontroller. It was the 10µF bypass capacitor that did the trick in that case.

Phil Pilgrim (PhiPi)

I have an old DS1620DK (development kit), which is a DS1620 PCB with a 4-conductor modular telephone connector. It was designed to be used over a longish cable and thieves its power from the three signal lines via diodes and a tantalum cap. Its only design concession to the cable length is a low-pass filter on the CLK line, consisting of a 200-ohm series resistor and a 300pF cap to ground. This was obviously put there to eliminate false clock pulses due to ringing and cable reflections. You might give that a try to see if it helps.

-Phil

Tracy Allen

Phil, how is that 200Ω and 300pF arranged? Is it something like the following:

If there is crosstalk from transitions on the data line, via the cable capacitance shown as blue, then it could induce glitches on the clock line and the RC filter could remove them at the DS1620. The cable wiring would make a great difference. The worst thing would be to run the clock and data together on one twisted pair. Better would be to run them each on a separate pair, as far apart as possible. Say clock paired with Vss and data paired with Vdd, along with a capacitor from Vdd to Vss at the DS1620. Ground all unused pairs in the CAT5. That makes the capacitance from the clock line to ground larger than the capacitance from data to clock, so the effect of the coupling is less. Even add just 100 pF from clock to ground at the DS1620 to help absorb the glitch. And/or 100pF on the data line to temper its slew rate.

Phil Pilgrim (PhiPi)

Tracy,

Here's the schematic for the DS1620DK board, with the signal order as it appears on the modular cable:



-Phil

michael75

Solved! Well, sort of... I cut the cable in half and tried it out only to get the same result. I then tried adding a, I guess it would be called a "pull-down" resistor, to the data line and it just started working. Now I'm wondering if that would have worked on the longer cable?

Anyway, thanks for all the help. I wasn't expecting so many thought-out responses in just a week!

-mike

davejames

Phil Pilgrim (PhiPi) wrote: »

Here's the schematic for the DS1620DK board, with the signal order as it appears on the modular cable:

Well, that "thieving"(sp?) power technique is very clever!

Did by any chance you measure/scope Vdd to see what was actually there?


Curious in San Jose.

davejames

michael75 wrote: »

Anyway, thanks for all the help. I wasn't expecting so many thought-out responses in just a week!

This forum is not want for thoughts!

Glad to hear you have something working.