SPI over 3 meters

Go To Last Post
27 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hello

I am making a project which is going to have to be functional on a small musical stage so there will be audio and power cables lying around . There will also be a strobe light.

I am going to need to communicate one Pillar on the left side of the stage with the right Pillar on the right side of the stage with SPI. The distance will be about 3-4 meters .

The communication will be sent from the master to the slave only with no feedback.

Would 3-4 meters be ok for SPI?
Would it be better if I used a slower clock for the SPI?
Would it improve noise shielding if I used RCA or even shielded Mono jack audio cables to transmitt the SPI signal?

Also I got advised to make differential pair signals for each SPI wire (3 in total , could maybe make it 2 if I tied the shift register clock and shift register
latch to one pin) .I'm using HC595 shift registers.

If for each pin I sent the signal and a mirror of the signal using an inverter and at the reciever used an op amp in a differential configuration would that do the job?

I'm using an atmega32

Thanks in advance for any input.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Our usual method of attacking your situation would be to use RS485 and USART comms, with a shielded cable and good connectors.

SPI may well go that distance in a tame bench setup. You'd have to try your method in a variety of conditions to see if it is robust.

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Problem is that I don't have much time for experiments as I need to complete it before friday so I need a solid solution (I know it sounds naive but yeah..)

My project is finished , but I'm just making embellishments now.

Quote:
SPI may well go that distance in a tame bench setup. You'd have to try your method in a variety of conditions to see if it is robust.

How tame are we talking here?
If I used SPI with shielded audio cables without any RS485 etc do you think that it would be okay?
keeping in mind that there will be sound and power cables scattered about and a strobe light which I don't know if it emmits strong EMI or not

Also I haven't used USART yet (although I've read the theory) and my programm sits around SPI so that is unfortunately off the drawing board.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I concur on RS485 (or its close cousin RS422).

Having all that power and audio wiring close by is likely to be a problem.

RS422/485 would allow you to network the devices, reducing the total wiring that you stuff adds to the stew of things on the stage.

There are several reasons why SPI is less robust than async serial for starters. Then, there are several reasons why differential signaling is more robust than single-ended signaling.

For starters, SPI is a very noise intolerant protocol, At one clock edge, a new data bit it put onto the bus. At the next (opposite direction) edge, the receiver latches the data value at that instant. If noise were to interfere at that instant, the data bit is incorrectly read,. Async serial (done correctly, as in a hardware UART), samples each bit a number of times in the receiver (often 8 ) and it takes the majority reading for each bit. Thus, if noise were to interfere with any one of the samples, the majority is still correct; noise would have to disrupt two of the samples in the same way for an error to occur. You can also add parity checking or even a checksum to raise the reliability level.

Secondly, most electrical noise sources will act on both lines of a differential signal in the same way, retaining the differential state. Single ended lines are more prone to externally generated electrical noise, though it can sometimes be reduced by using a twisted pair (or 4-wire bundle).

Finally, RS422/485 transmitters and receivers are themselves far better suited than simple logic. Transmitter/receivers are built to tolerate noise and have the drive capability to drive longer lines. Logic is relatively weak in this regard and tends to be more sensitive to signal line noise.

Hope this helps
Jim

 

Until Black Lives Matter, we do not have "All Lives Matter"!

 

 

Last Edited: Mon. Sep 16, 2013 - 04:21 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

My friend use SPI in power drivers (4 channels, ~100A PWM with 20kHz carrier frequency). He use the RS485 as hardware layer (each SPI signal has their own 2-wire line) and he never has any problems with noise.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Okay so it is evident that the RS485 is the way to go .
I'm also considering the other choice that I offered due to the fact that I don't have any RS485 chips lying around at the moment.

So the other choice that I'm considering is as I mentioned above :

If for each pin I sent the signal and a mirror of the signal using an inverter and at the reciever used an op amp in a differential configuration would that do the job?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Shagas wrote:
If for each pin I sent the signal and a mirror of the signal using an inverter and at the reciever used an op amp in a differential configuration would that do the job?

Yes, but not as well as RS485. RS485 and twisted pair are made for long distance communication with high speed rate. Drivers and receivers for ADSL may be even better and more reliable in Your application that RS485, but this solution is much less popular.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Your solution is probably better than what you originally proposed.

You would gain a lot just shifting from SPI to UART, for the reasons I described. THEN, your choice would be RS232 vs RS422/485. RS232 gets its noise "immunity" by using large signals (hopefully bigger than the noise). RS422/485 gets it from differential. In your application, RS232 is probably not desirable because it is not readily networked.

Jim

 

Until Black Lives Matter, we do not have "All Lives Matter"!

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thank you guys for the information.

Yes I am aware of the functionality of the Rs232 and I know that it would solve my problems but the thing is that I have no experience with them yet and I'm planning to design the PCB's tonight so it has to be something that I can work with right now .

Question: The noise is such a problem because of the high impedance of the SPI and the shift registers am I right?

For example when unbalanced audio cables are used to send analog signals there is no more than maybe a millivolt of noise on them so the relatively low impedance keeps the signal resistant to noise.
Is my analysis even close to being correct?

Keep in mind that it probably won't kill me if a packet gets lost here or there.

I'm thinking of another solution.
The spi in the master pillar has to adress 2 shift registers in the slave which means 16 bits of data.
The shift register parallel outputs are going to be connected to transistors to power led's .
If I just keep all 4 shift registers for both pillars in the master pillar and just send out a 16 wire bus to the transistor bases in the slave pillar would that be more resistant to the noise? Assuming that I have say...5k pull down resistors on the slave pillar transistors or something like that.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

RS485/422 is really the only way to go in a stage environment. It is in fact the basis of DMX. Messing with anything else is going to cause you reliability problems.

If you just need it to work 'that one time', you may get away with a less robust solution, but you should consider re-designing at your earliest opportunity.

Quote:
I'm thinking of another solution.
The spi in the master pillar has to adress 2 shift registers in the slave which means 16 bits of data.
The shift register parallel outputs are going to be connected to transistors to power led's .
If I just keep all 4 shift registers for both pillars in the master pillar and just send out a 16 wire bus to the transistor bases in the slave pillar would that be more resistant to the noise? Assuming that I have say...5k pull down resistors on the slave pillar transistors or something like that.
Possibly. It depends upon how quickly you were intending on modulating the drive signal for each channel. If you're just doing simple chases and the like on a 'stack' of leds in the pillar, you probably won't have any trouble.

If you were going to try PWM, you might have some heat problems with the transistors. Capacitive coupling of those very long signal wires would slow the slew rate of the voltages at the bases of the transistors, keeping the transistors in their linear region for longer.

If you can get your hands on 32-conductor (or wider) ribbon cable of sufficient length, you could interleave each signal with a ground. This is in fact how 80-wire PATA cable works in your desktop (reduces capacitive coupling between signals). To be honest, I'd expect that you may not even need the extra grounds, but it can't hurt.

Ribbon cable is not especially strong. It doesn't like to be trod upon. You'd need to tape it down to the stage, and preferably lay a mat on it to prevent damage from the performers and moving set pieces.

JJ

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"Wisdom is always wont to arrive late, and to be a little approximate on first possession."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks for the answer Joey .

I should have mentioned early that there is not going to be any PWM , at least not in this respect.

The pillars are actually Vu meters and they will have about 100hz refresh rate , so every 10ms the spi will send out 16 bits to the shift registers to update the condition of the Led rows. Transistor heat is also not a problem , I already tested all that with higher loads and it's fine.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Why not Use one to work the other?

Use the driver/receivers associated with RS422/485 to drive the SPI lines?

One pair for the clock, one pair for the MOSI line and one for the /CS Total of six IC's. Three set to TX all the time, three set for RX all the time.

If you do end up using MISO then add one more pair of IC's.

Add the 120 ohm termination resistors at each end and you should be good to go.

IC part number MAX485 or SN75176

EDIT: I do realize this is a waste of IC's and wire but if he is backed into a time constrained corner this might be the easy way out for now

I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie

 

"The critical shortage here is not stuff, but time." - Johan Ekdahl

 

"Step N is required before you can do step N+1!" - ka7ehk

 

"If you want a career with a known path - become an undertaker. Dead people don't sue!" - Kartman

"Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?"  - Lee "theusch"

 

Speak sweetly. It makes your words easier to digest when at a later date you have to eat them ;-)  - Source Unknown

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB, RSLogix user

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

can you trust the ground level to be the same at the receiver end?
I guess I would use a optocoupler (2 if you want to use SPI) and load them a bit hard, so there go at least 5ma, when on.(placed at the receiver end)
Twisted pair wire should be fine (CAT5 would be an easy way).

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

So if I used loaded optocouplers for SPI then it would be fine?
Also if I used SPI then I only need MOSI , SCKL and a latch pin for the shift registers so three in total.

But still , I'm inclined more towards the solution where I have all the shift registers on one pcb and I will just send a 16 wire bus across 4 meters to the transistors of the LEDs.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I have seen projects where SPI has been driven several hundreds of metres.

The issue is NOT the communications protocol as in SPI or USART but the drive current/voltage and the line itself.

In other words you could use 2 RS485 chips in driver mode (TX), one for MOSI and one for SCK, use twisted pairs as in CAT5, use 2 RS485 chips in receiver mode (RX) and your "SPI" signals will happily go the full 1.2Km (4000 ft) that the RS485 standard specifies at lowish clock rates.

edit I see some other "wise mind" has suggested the same thing. :oops:

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hopefully you're getting the feeling that using spi is a bad idea. You can fudge up your own differential rx and tx but then you might run into issues with timing skew between your plus and minus signals and hysteresis with the receiver. Using components designed for the job is much simpler.

Optos wont save the day as they need to be chosen carefully.

An old aircraft protocol arinc429 used a synchronous scheme like spi but it had error checking and was differential of course. So spi is not inherently bad, but async using the uart would be much simpler and robust.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks for the info Kartman .

What I'd usually do is learn what you guys advised and apply it but in this case I'm really constrained by component inavailability and time so I have to cut some corners.

So what do you think about my last suggestion?
"if I keep everything on one PCB and just send a bus of 16 wires out of the shift register into the bases of the transistors 4 meters away will I still get a noisy signal?
The refresh rate will be about 100hz

Also let me redefine noise: For me in this case noise would be anything higher than say....300mV since the minuscule flicker of the leds will not even be seen.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Shagas wrote:
The pillars are actually Vu meters and they will have about 100hz refresh rate , so every 10ms the spi will send out 16 bits to the shift registers to update the condition of the Led rows. Transistor heat is also not a problem , I already tested all that with higher loads and it's fine.
Heating would only have been a potential problem with PWM.

If it's just a Vu meter, why does it have to be a 2nd-channel slave to the 2-channel master in the other pillar? Why not just build two identical 1-channel units? Then you just send independent audio signals to each pillar, with no need to communicate between pillars.

JJ

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"Wisdom is always wont to arrive late, and to be a little approximate on first possession."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
If it's just a Vu meter, why does it have to be a 2nd-channel slave to the 2-channel master in the other pillar? Why not just build two identical 1-channel units? Then you just send independent audio signals to each pillar, with no need to communicate between pillars.

Yeah that was my initial plan but then I decided that I want both pillars controlled by One AVR so I can manipulate the code and flash live during the show so it would be pretty crappy If I had to flash one pillar and then run over with my laptop and MkII and pop in the header into the second one.

Edit: Also , I'm saving abit on the cost and time because I don't have to get another micro and etch a second PCB for it

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Shagas wrote:
Edit: Also , I'm saving abit on the cost and time because I don't have to get another micro and etch a second PCB for it
But... now you have to design, etch, and solder a 2nd different pcb to hold either your shift registers and/or driver chips and/or transistors, don't you?

Shagas wrote:
Yeah that was my initial plan but then I decided that I want both pillars controlled by One AVR so I can manipulate the code and flash live during the show so it would be pretty crappy If I had to flash one pillar and then run over with my laptop and MkII and pop in the header into the second one.
It would be pretty crappy if you re-flashed in the middle of a show and it all went sideways.

You would be better advised to design your software to be robust enough, and feature-full enough to obviate the need to re-flash in the middle of a performance (!).

If you wan't to be able to change parameters, identify what those parameters are and then build in some simple ADC-read potentiometer controls that manipulate those parameters. What parameters?

    - refresh rate - bottom-of-scale
    - top-of-scale
    - rolling-window width
    - anything else you might re-code and re-flash
JJ

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"Wisdom is always wont to arrive late, and to be a little approximate on first possession."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
so I can manipulate the code and flash live during the show
? ? ?

That would not be a good plan, in my opinion.

But it appears that you are down to the last minute without a functional system up and running that you can tweak during a dress rehearsal.

Using RS-4xx would seem to be the recommended method suggested by several people above.

I would probably use RS-232 simply because I am much more familiar with it, unless I had the time to learn the nuances of RS-4xx comm's.

RS-232 transceiver chips such as the Max232 are ubiquitous. Using a USART is similar to using SPI. Tutorials will help get you started.

I would use a shielded cable.

I would use a "slow" baud rate, and send each data packet three times, with a checksum byte added to the end of the packets.

That said, I used a logic level serial comm's link, about 8 meters, with shielded cable, with the triple packet with checksums, and it worked fine, in a very noisy environment. It was a prototype and I needed to test a few parts of the system prior to making PCBs which then included the RS-232 driver chips.

Ideally, if you really wanted to manually tweak the system in real time, you would have a real time user interface to the Master PCB which would let you set parameters to pre-configured ranges. For example, set parameter one to range "A", (or B, or C, or D...) The actual ranges having been already incorporated into the program. In real time you just select the range to use.

The User interface could be another micro with an LCD and a couple of push button switches, or a PC running a GUI.

JC

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
But... now you have to design, etch, and solder a 2nd different pcb to hold either your shift registers and/or driver chips and/or transistors, don't you?

Not really . I haven't designed any of the PCB's yet .
The atmega , the sound input circuitry and and shift registers will go on one PCB , the transistors for each row will go on a separate PCB .

I'm doing this for future hardware and software upgrade compatability. With separate boards I can expand the project peripherals without having to redesign the whole thing (but that's for later).

Quote:
It would be pretty crappy if you re-flashed in the middle of a show and it all went sideways.

I've thought about this . The Vu meters are not the main attaction , there is going to be bands/djs playing live to which the pillars add 'visual dynamics'. If they go down for abit then it's no problem.
Besides , I've planned to have the original hex at easy access so if something doesn't work then I can roll back to it immediately . Would only take a few seconds.

Quote:
If you wan't to be able to change parameters, identify what those parameters are and then build in some simple ADC-read potentiometer controls that manipulate those parameters. What parameters?

I will have a few pots connected to the ADC (separate micro) to vary some basic things like RGB colour and other stuff but this will be wired into the "driver PCB" of both pillars.
What I will be reflashing is the actuall animation. There is alot of simple fun stuff with math that you can do to the Led arrays that can look nice.
I could also have parameters be controlled by pots into the ADC of the main micro as you suggested.

Last Edited: Tue. Sep 17, 2013 - 12:36 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
The User interface could be another micro with an LCD and a couple of push button switches,

Hmm , I'm liking this idea...
I definately want to implement something like this as an expansion, it would be pretty cool to have a user interface for live user-programmable editing. But it will definately have to be after this event as it would take me up to a month to make something like this. I have been playing with electronics for about 8 months now and 3 months with micros so I still have to think long and hard on how I'm going to implement an Idea when I come up with one.

By the way , this event isn't me flashing cool lights on the stage.
This is a musical event and these pillars are just as I mentioned above a very 'marketing-like sounding' term :
"Visual Dynamics" to the music. At least that's how I see it.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Shagas wrote:
What I will be reflashing is the actuall animation.
Well, if you're going to get crazy, why stop there?
    - A laptop with wifi and a programmer connected to the mcu/pcb in one pillar. - A second laptop with wifi and a second programmer connected to the second mcu/pcb in the other pillar.
    - A thrid laptop with wifi to remote in to the other two to be able to reflash the firmware on both pillars independently, or at the same time, but in each case at a remote distance. Lets you sit at the back of the house and see what's going on.
Your boards and programmer would have to tolerate running while connected together. I'd suggest bit-banged SPI on GPIO pins instead of on the hardware SPI, would ensure you could reflash, stay connected, and run the app.

Basically, the constraints of the show (including time) are in conflict with your desire to develop a general purpose, extendable product. Don't try to do both. You'll just wind up building an 'El Camino' (all the cargo carying capacity of a compact car, combined with the ride-comfort of a truck). Come to terms with that. Get this show done. Learn from the experience.

JJ

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"Wisdom is always wont to arrive late, and to be a little approximate on first possession."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

When you say flash during the show are you referring to the VU meters or are you talking about reprogramming the AVR?

I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie

 

"The critical shortage here is not stuff, but time." - Johan Ekdahl

 

"Step N is required before you can do step N+1!" - ka7ehk

 

"If you want a career with a known path - become an undertaker. Dead people don't sue!" - Kartman

"Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?"  - Lee "theusch"

 

Speak sweetly. It makes your words easier to digest when at a later date you have to eat them ;-)  - Source Unknown

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB, RSLogix user

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If that is a ~1kHz SPI clock and 5m distance then I would not bother with any RS485. Use a regular single-ended SPI, with push-pull drive.
Just make sure that the gnd line does not conduct any significant static current and connect it with loopback for verification of transmission during debugging.

No RSTDISBL, no fun!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Well in any case , reprogramming or not it is still easier for me to make a master/slave configuration as i'm saving the need for 2 extra pcbs

Quote:
Well, if you're going to get crazy, why stop there?

It's not about that ... Knowing myself , I might be watching the Vu meter live and will want to recalibrate it or change the peak decay or 10 diffrent other things. I want to have the power to be able to do that. Even if I'm not going to need to.

Quote:
When you say flash during the show are you referring to the VU meters or are you talking about reprogramming the AVR?

Yes