Taking the Leap Off Board: An Introduction to I2C Over Long Wires

Image result for i2c sensor array
prototyping starts here, but we’re in danger when projects finish with this sort of wiring

If you’re reading these pages, odds are good that you’ve worked with I²C devices before. You might even be the proud owner of a couple dozen sensors pre-loaded on breakout boards, ready for breadboarding with their pins exposed. With vendors like Sparkfun and Adafruit popping I²C devices onto cute breakout boards, it’s tempting to finish off a project with the same hookup wires we started it with. It’s also easy to start thinking we could even make those wires longer — long enough to wire down my forearm, my robot chassis, or some other container for remote sensing. (Guilty!) In fact, with all the build logs publishing marvelous sensor “Christmas-trees” sprawling out of a breadboard, it’s easy to forget that I²C signals were never meant to run down any length of cable to begin with!

As I learned quickly at my first job, for industry-grade (and pretty much any other rugged) projects out there, running unprotected SPI or I²C signals down any form of lengthy cable introduces the chance for all sorts of glitches along the way.

I thought I’d take this week to break down that misconception of running I²C over cables, and then give a couple examples on “how to do it right.”

Heads-up: if you’re just diving into I²C, let our very own [Elliot] take you on a crash course.

 Bugs–What Bugs?

Ok, so maybe I routed a couple feet of cable carrying I²C through my robot chassis to talk to my sensors. What’s the big deal? Once we start running signals over cables, there’s a host of assumptions that start to break down. Let’s take a quick tour of the two biggest challenges that are all too eager to bite us: bus capacitance and EMI.

Stretching out our Bus Capacitance

First, there’s the capacitance of those long wires. Remember, capacitors are just “two conductors, separated by an insulator.” Sound suspicious? If we look at our cable topology, a signal wire and a ground wire form exactly that–an unwanted capacitor! The longer our cable grows, the bigger this capacitor grows.

Image Source: All About Circuits
Image Source: All About Circuits

OK, so now that we know there’s a capacitor in our system, what, exactly, is it doing to our signal? In the ideal world, or at least when our conductors were short, we could expect a pretty short delay between the time our signal takes to exit one device and enter the next. In fact, it’s so short we can pretty much forget about our bus capacitance altogether. However, as that wire distance grows in size, that parasitic cap takes our nice clean signal and starts attenuating it.

Why is this happening? Let’s look at the bus architecture. I²C implements open drain configuration, which means each device has a MOSFET on it’s input, enabling it to pull the entire bus down to “logic 0.”

i2c_digital_bus_model-1

Assuming we’re running our I²C bus over a long cable, let’s now add our parasitic bus capacitor into our diagram.

i2c_digital_bus_model_with_bus_capacitance

With a little re-jiggering, let’s just examine one device and now model its transistor as a switch.

i2c_digital_bus_model_with_switch_model

Behold! A wild lowpass filter has appeared!

i2c_digital_bus_model_with_lowpass_filter_revealed

When any device releases our SDA or SCL line from low to high, modeled above as a switch opening, we can’t just change the value of the bus instantaneously. Why? We must first pass our signal through this low pass filter, or, in more conventional terms, charge up this parasitic capacitor. The result? The received signal emerges not in that pristine, staccato square wave that we all know and love, but a diluted representation of the original, as if staggering back home from a rough night at the pub.

delayed_rise_time-1

Fun Fact: Bus capacitance primarily affects rise time, not fall time, since the N-channel MOSFET which closes to create a “logic 0” signal is essentially creating a short to ground, bypassing the capacitor altogether.

With a stretched signal running over long wires, we need to start worrying about keeping that rise time sufficiently low for our receiving device(s) to read incoming signals correctly. Rise time is the amount of time for the voltage to reach a valid “logic 1” threshold level before it’s read. For I²C, the spec dictates 1000 nanoseconds for standard mode (100 kHz) and 300 nanoseconds for fast mode (400 kHz). If we stretch our rise time any farther, we’ll risk sending over bits that don’t get recognized as either a “logic 0” or a “logic 1.”

Fortunately for us, we have a slight amount of control over this rise time; we control it by changing the value of our pullup resistors. First things first, though: let’s clarify how pullup values influence the I²C bus. Earlier, I mentioned the stray capacitance coming from those looong wires running from master to slave device.

A stronger (fewer Ohms) pullup resistor decreases the rise time of our signals by increasing the allowed current that can flow through either signal line, which, in turn, charges our parasitic capacitor faster.

delayed_rise_time_with_various_pullup_values

OK, so just how far can we go? Just how small of a resistor can we spec? If we want a snappy rise time, why not just go with a 100 ohm resistor–or something smaller? Unfortunately, with a stronger pullup, the amount of current that any one of our bus devices needs to sink will also increase. Let’s have a look at that diagram again.

i2c_digital_bus_model-1

Notice how N-channel MOSFETs are baked into each device? These FETs are responsible for actually driving the bus low, which, in turn, changes the bus values to either “logic 1” or “logic 0.” Since those MOSFETs are internal to each device, they’re limited by just how much current they can sink through the corresponding device without damaging it. Fortunately, the I²C spec actually dictates the maximum sink current; it’s a puny three milliamps. Hence, with only 3 mA, the strongest value pullup resistor gets very quickly limited to the low kiloohm range at best.

If you actually have an application where you’re operating somewhere in the range of these limits, you’re in luck! TI has put together the necessary equations to calculate bus pullup resistor values in one application note. Nevertheless, keep one thing in mind: the range where we can play this trick of reducing bus capacitance with stronger pullups only goes so far. Most people don’t care–and rightfully so, since most people don’t run I²C down a long cable in the first place to such an extent where bus capacitance actually matters.

Our problems with running I²C down a long cable don’t stop with bus capacitance. There’s one more foe that’s arguably far more nefarious.

Mischievous Bit-Flipping

We can thank the smartphone industry for gifting us with some pretty killer MEMs sensors, most of which speak I²C. With sensors like ST’s VL6180 time-of-flight sensor (Sparkfun Breakout) and Bosch’s BNO055 IMU, it’s tempting to cram these sensors into the corners of our robot chassis over long wires. Hold up, though. Robot platforms smell of moving parts, and moving parts smell like motors–which are huge sources of electromagnetic interference!

So, what exactly does EMI do to harm our system? EMI can induce voltage spikes on long cables. Remember: every long wire is, at heart, a good ol’ antenna, susceptible to picking up nearby electromagnetic waves. In a classic analog AM radio, changes in the amplitude picked up by this antenna would convert to audible sound. A digital system, however, doesn’t interpret continuous waveform amplitudes. It only interprets two threshold amplitudes which translate to a binary 0 or 1. While EMI might take on an analog form, we start to see problems when those unwanted EMI-induced voltage spikes cross those thresholds of the digital domain. The consequences? For our I²C bus, these induced voltages can translate to unwanted bit-flipping. Fancier protocols have error-correcting codes designed to handle occasional bit flipping and request a retransmission. Alas, I²C has no such thing.

Solutions for Long Runs

Bus capacitance and EMI are the two most common issues when we decide it’s time to run our I²C and SPI devices over long distances. Luckily, there’s a chorus of off-the-shelf solutions that are ready to handle these scenarios. Let’s take a tour of what’s on-hand.

Shielded Cable

For short cable runs, the easiest way to mitigate the noise risk would be to simply run the native SDA and SCL signals over a shielded cable. By far, this solution requires the least effort because, cablewise, it’s merely a facelift. Note that this solution only mitigates noise, and does nothing to solve the issue of bus capacitance. For that, you’ll still need to spec an appropriate pullup resistor.

Belden - 22 AWG 2 Conductor STP Cable, 24 AWG Drain - 1000 ft (1266A-1000)
Image Credit: solidsignal.com

Using shielded cable properly means we’ll need to ground the shield at one end. A shielded cable with the shield left ungrounded is merely dressed for the occasion, but it’s completely useless. A shielded cable with the shield grounded at both ends is now a ground loop (aka: antenna), which is almost as bad as leaving the cable unshielded to begin with. The rule from here-on-out: ground the shield at one end and one end only.

To make life easy for us, manufacturers usually add a naked extra wire, called the drain wire (seen on the left), which is electrically connected to the shield. Simply ground this wire at one end, and we’re done!

 

Bus Buffers

For long cable runs, some dedicated ICs can buffer the I²C signal, enabling the signals to run down a pair of wires with a much higher capacitance than what’s typically allowed on the I²C bus. The PCA9605 enables devices to run at the maximum allowable bus capacitance (400 pF) of the I²C spec. The PCA9605 takes that limit even further, allowing up to 4000 pF on the cable side.

The P82B96 does that, and a bit more. In addition to allowing a higher bus capacitance, it also enables the bus to run at a boosted voltage, making it even more noise immune. What’s more, the P82B96 can even be optoisolated, enabling interaction between devices on dissimilar power supplies. The datasheet boasts carrying an I²C signal across cables for up to 20-meter cables. Furthermore, by dropping additional P82B96 devices downstream along the cable, the signal can be boosted and regenerated to travel even farther.

Image Credit: NXP P82B96 Datasheet

Keep in mind that systems with P82B96 chips will come in pairs, as shown above. This pairing is necessary to take the boosted I²C signal from one chip and re-encode as conventional I²C with a bus voltage that’s sane enough for our remaining I²C devices.

Differential Bus Buffers

While some bus buffers simply boost the voltages of the I²C bus, others re-encode it as a differential signal. The PCA9615 does just that. It encodes the SDA and SCL lines into two split differential pairs. Differential pairs are one step short of magic. By sending equal-and-opposite signals over two wires spaced closely together, we make the signal far more noise immune than simply by boosting the voltage. (More on differential signals and the PCA9615 in an upcoming post!)

Of all the solutions so far, this one’s my personal fave. Not only do we get all of the noise immunity benefits of differential signals, we also don’t sacrifice the main benefit of I²C: that it is a shared bus and, hence, only a small number of wires. On that note, this chip also supports a multidrop configuration, making it a true off-board extension of the protocol.

Image Credit: PCA9615 Datasheet

In the diagram above, the large bounding boxes reflect multiple PCBs–each of which is connected at arbitrary points along the same cable. By far, my best bet at taking this diagram and turning it into real components was to start with ribbon cable and simply crimp connectors along the cable like so. (Those cable lengths, however, can span a few meters without any problems.)

32667876446_3469749506_z
A PCA9615 Chain

With typical bus buffers, sending a boosted signal across a ribbon cable would still introduce the possibility of EMI in the noisiest environments. With a differential signal, that’s no issue, provided that each pair is closely spaced together on the cable.

As opposed to the prior solutions, each node that connects to this setup has the same topology, just one PCA9615 per drop. There’s one exception, though. The final drop needs to have termination resistors that complete the differential pair topology.

Years ago, running high speed signals over long wires may have been a huge headache. Nowadays, there are boatloads of ICs ready to give us a jump start in this realm. Those drop-in solutions may have have been the toils of our predecessors, so I cited the main application notes at the bottom of this article. Nowadays, in my mind, running I²C over long cables is a solved problem. If we follow the recommended guidelines, we’ll be well on our way to implementing an out-of-the-box solution that “just works.”

Join us in the coming weeks as we look into specific implementations that tackle these problems in gritty detail. Until then, cheers!

References

80 thoughts on “Taking the Leap Off Board: An Introduction to I2C Over Long Wires

    1. I was told in college that RS-485 was dead and not worth learning about (as well as RS-232, 422, LVDS, GPIB, SCSI, IDE, Parallel, several other interfaces, and discrete logic circuits) and was amazed when I started my first industry job and started having to interface MSP-430 and ARM MCUs with all of them.

      I’m seriously considering running RS-485 through the unused pairs in my 10base-T LAN for home automation.

          1. Mwa, “nothing” is a strong expression in this context.
            The physical layer of CAN is somewhat similar to RS485 in that they both use differential signalling. The difference is that RS485 drives both lines in push pull fashion (or both idle if inactive) while CAN only sinks to ground and uses external pullups, somewhat similar to I2C.

          1. Epaulettes. That’s all I’ll say. Just because someone jumped through some hoops and got the equivalent of military rank and costume, doesn’t mean they’re an expert on what they’re teaching you.

            If you EVER find yourself saying “I was told in college that ‘xyz’ because ‘so and so’ professor told me so”, just STOP. Stop and do some actual research or get a second opinion. Objective reality doesn’t start and stop with a single person’s opinion. Unless you’ve actually gotten a consensus from at least a few experts, or actually researched it yourself, then consider it nothing more than unverified claims. Skeptic’s creed. Show me the evidence. Everything else is just opinion.

      1. A lot of those old comms protocols are more like sharks than dinosaurs. They may not be the newest thing, but they’re a lot tougher and more noise resistant than newer and more “high tech” options like USB. They’re protocols that have hung around and not changed because they don’t need to change; the original design can still compete in the environment it was designed for.

      2. We use RS485 in most of our applications due to the cost, distance and relatively low bandwidth requirements. RS485/RS232 are still very common in a lot of industrial modules.

        If only CAN enabled hardware was not so expensive.

    2. Given the very low cost to make a whatever to TCP/IP gateway these days you have to wonder if sending anything else over long wires/air/fibre makes much sense. It will come down to the exact application and the scale of what you are trying to do, the number of sensors etc. With an ESP8266 pulling down NTP data you can hook it to anything and then stream very accurately time stamped sensor samples to whatever back-end you like, you can even multicast the data. The ESP on networking over wires is an option if WiFi isn’t, http://hackaday.com/2016/07/01/wired-networking-for-the-esp8266/

      1. how well does ethernet work when run directly parallel to 660V @20A (full of motor noise/spikes/rf) ??? oh, you need to drill a new hole in the wall thats farther away from the power? the old system worked fine as-is, anything newer should be better, right? I dont get it; theres two seperate conduit holes… should be okay? why are you trying to bill me for a huge construction project and retrofit of ALL our stuff, when we just want our new robot installed andor upgraded. oh right, you think we need 10/100 megabit? the machines only need to transfer 32 bytes per second… WHEN there is a need.

        yes, you are right, the ethernet should not be run that way… but it is, does not work. you get fired/laid-off because you say it cant be done eventhough you removed the one where it DID work, then your replacement re-installs the old one, with an off-the-shelf converter, (after spending days learning outdated stuff, i know, so painfull) ironically, doing the REVERSE of what you reccomend; I2C/SPI/ect to connect a “modern” robot to your existing “working” systems without having to revamp all machines, cabling, holes in walls (proximity to high power EMI) routing, and central control.

        also wifi is not acceptable for secure communications. for example; phosphene gas pressure vent controlled by wifi? i would not even approach the building unless it was to decomission the wifi. that way intruders have to get by the guards and cameras and locks and nothing bad happens. no insurance would cover you if they found out your phosphene gas was “secured” using wifi, and that it “accidentally” got bridged (between the isolated wifi and the world-wide-web) after an employee accidentally got a personal laptop/tablet/smartphone infected with a phishing scam and forgot to turn off laptop when driving to work… but how did they know? you logged into your work email and the scammers now know everything and sell it to much worse scammers that sell it to the very-very bad people.

        leave the wifi for the cameras and web, that way if anything happens, we keep making money. if we put criminals out of buisness, they will turn into web-trolls and wont be able to bother us at work or while sleeping (safety of factory nearby).

        PS: the existing systems already have time-stamp ability and run on a number of sometimes interchangeable comms systems.

      2. TCP/IP requires big connectors, faster, bigger, and more expensive processors, more memory, higher frequency, more power, and much more hassle in configuration. RS-485 just requires a UART, and a small driver chip.

        1. I would leave out the connectors in this. TCP/IP -> RJ45 (small), RS485 normally SubD9 (bigger). Of course RS485 would work over RJ45 too – or some expensive heavy duty waterproof military round connector.
          Bigger Processor, memory, etc. of course true.

      3. The problem is that getting an 8-bit or 16-bit MCU onto Ethernet either requires a lot of heavy programming (leaving little CPU time for actual application code), a more expensive MCU with an integrated Ethernet PHY (I’m using the Tiva-C ARM currently, 90% of the code is the TCP/IP stack), or a module that costs more than the actual MCU ($1 AVR plus a $10 Wiznet or ESP).

      1. agreed.

        i filled my bedroom with smoke by connecting some random low-voltage to the BNC terminal of a THINnet network card, needless to say, it was not up to industrial standards as it was intended for home and office and was labeled as such.

        in industry, you have higher voltages (24V) and higher current (1-5A) then in my expierement. i maintain it was an expierement.

    1. That depends a lot on the routing and noise sources. In a noisy environment, a few inches can already be causing problems. With the PCA9615 you get the best immunity, and the datasheet mentions up to 3 meter (10 ft) cable length for high speed.

  1. The ground loop advice needs to be taken with a grain of salt. The issue is more complicated in regard to digital.

    http://www.sigcon.com/Pubs/news/2_2.htm

    “In high-speed digital applications, a low impedance connection between the shield and the equipment chassis *at both ends* is required in order for the shield to do its job.”

    But (and this is where the advice in the article is correct):

    “In low-speed applications involving high-impedance circuitry, where most of the near-field energy surrounding the conductors is in the electric field mode (as opposed to the magnetic field mode), shields need only be grounded at one end.”

    The type of ground loops you avoid by only connecting it at one end are generally from two pieces of equipment that are earth grounded or share a common ground through some other path. If you have a device that is being powered by a long cable that also supplies I2C, then you don’t have a problem. Connect the shield wire to the chassis of both devices.

    1. Yup, I deal with high frequency impulses from a 3.4KV transistor switch all the time. The best rule I’ve found for signals is to ground everything. Afik, the “ground at one end” guide line comes from situations with large AC magnetic fields, or where the ‘ground’ at each end of the cable is a significantly different voltage. (in both cases, the ground loop leads to ground currents and voltage offsets in the signal wires)

    2. At very high frequencies the ground can be superfluous because you most probably have a capacitive input anyway.

      The real issue with ground is determined by the signalling type. Unbalanced, differential or current signalling is isolated from ground anyway but it may be required as a reference for Vcc of the chips at either end (not always the case) or connected to shield at one end.

      Shield and ground are not the same and shield is normally only connected to ground at one end. Some coaxial cables have two braids and one signal the centre is signal, the inner braid is ground connected at both ends and the outer braid is shield – normally connected to some form of ground at one end.

      In a balanced or ground referenced signal the ground has to be connected at both ends because it *is* the reference. This can produce problems to be solved due to *other* things that are *also* connected to ground.

      1. RS-485 is true differential signalling and you don’t need a ground conductor. High speed differential signalling is typically not true differential signalling and requires a return conductor. The launch times even on high quality drivers are far enough off that it’s more like two single ended signals as far as the rising and falling edges are concerned. Additionally, with high sped signals, when the signal is on the PCB you aren’t going to get enough capacitive coupling between the two traces to get the inductance anywhere near what it needs to be, they need to be referenced to a ground plane. And thus you’ll also need ground reference as part of your cable.

        And again, as far as connecting the shield, just like with all grounding schemes, the answer is always “it depends”. For anyone doing low speed signalling, especially audio (basically DC), the answer is almost always to only ground it at one end. Once you move on to high speed signalling, you usually need to ground it at both ends for it to be effective.

        Just to make the designers job harder, you don’t need to electrically connect ground to have a ground loop anyway, at least ground loops not related to mains. Signals are perfectly happy to capacitively (or inductively) couple to whatever signals you give them. That capacitance can come from either the case, or from capacitors intentionally placed.

  2. The P82B96 has an idle voltage of approx 0.8 volts on the device side whichnis a little too high for a lot of micros to interpret as idle. The PCa9600 is a much better choice in my opinion as it can idle at about 0.6V.

      1. LIN is only 19k2, and the pull-up is 1K, so that makes it less of a problem. It’s also a 1-wire bus, so you don’t have problems with crosstalk. It’s single master, so you don’t have problems with bus collisions. Looks much more robust than I2C.

        1. And it uses battery voltage (whatever that is at that moment) as signal voltage. Except for the higher level protocol I would compare it much more to RS232 than I2C. It also uses a UART.

  3. “A shielded cable with the shield grounded at both ends is now a ground loop (aka: antenna), which is almost as bad as leaving the cable unshielded to begin with. ”
    Ehhh???? This is wrong/bad practise.

    1. A ground ‘loop’ must actually be a ‘loop’ in that there must be two distinctly different path from one point to another.

      Your example is true, where for example, you have audio equipment and the chassis ground from the power outlet is connected to the ground on two different piece of equipment and then adding a shielded cable where the shield is connected to ground at both ends. This creates the two paths of the ‘loop’ one part being the audio cable shield and the other being the ground wire between the power outlets.

      In normal use the ground of a cable is connected at both ends in an ‘unbalanced’ configuration.

  4. Google “24c02 i2c eeprom”

    Ok…. so what?!?…. Atmel are calling it 2-wire protocol to get around some legal BS.
    However don’t cables (reams and reams of it sometimes) for video transfer have i2c since around and maybe before VGA through DVI to HDMI?

    No i2c in DisplayPort AFAIR, uses AUX channel instead… And I’ve epic failed at the timing issues trying to get an eDP hooked up to my E6400.
    The timing tolerances in the datasheet for said LCD are around a K of picoseconds…

      1. But probably not a whole bus with several devices. So it is a point to point connection, probably with good quality shielded cable (necessary for video anyway) and you can use low data rate as the amount of data is small.

  5. Quote: The PCA9605 enables devices to …
    Quote: The PCA9605 takes that limit even …

    The P82B96 doesn’t seem to be much of a step up from the FET output it replaces, it’s still unipolar drive. It would have been good to see the others.

    Op-amps and differential signalling are your friends here.

  6. I have a commercial product that uses the P82B96 to run I2C over cables up to 250 feet long. Passed CE immunity with capacitive coupling to the cable shield. (Testing this was a bit inconvenient!) Pull up is to 12VDC. SCK runs at 40 kHz.

    1. I remember a simple circuit for running I2C over (relatively) long distances over a pair of coax cables. It was a pair of PNP transistors on each end, emitter to core, collector to ground, base to signal. There was also a 50 or 75 ohm pullup to 5V on the emitter and a 1k resistor from emitter to base.

  7. I was able to connect an LSM303D Accelerometer to a Raspberry Pi through ~25 feet of wire by using CAT-5 (4 grounds, 2 Power, 1 SDA, 1 SDL. Been running perfectly for months now.

  8. If 10 meters is considered a long distance, carefully set up I2C with constant current pull ups should do it. There are also some interesting tech docs on the one wire protocol about driving long cable lengths that should provide some ideas. For really long distances, tens of meters to kilometers, RS485 is great. Line drivers are cheap and easy to find and it just needs simple twisted pairs. It is unidirectional/multi-drop but it is easy to set up two circuits for bi-directional use. I use RS485 for wired connections over anything above about a meter.

      1. Yes, that’s right. Once I had to design an interface for around 100 devices daisy chained over around 5-7km of combined cable length.There was an old system which routed the data through the CPU in each device. I did not want this because of complexity, port and power usage. In the end it was some hybrid between RS422 and RS485.
        From Master to the slaves it was probably just a bus line where every slave buffered the signal and listened to it.
        In the other direction each slave combined the received signal with it’s own transmission through an AND gate and the combined signal was retransmitted. So every device worked as a repeater without the complexity of routing the data through the CPU.
        I think this was also used somehow for the bus enumeration as the devices did not have fixed ID numbers but had to get numbers according to their physical position on the cable.

  9. I “designed” an I2C bus for an electric trike, where a RaspberryPI talks I2C to the 2 motor controllers (24V20A each) over a bus 0.5m from the PI to each controller. We run I2C at 500 kbit/s, 10 several byte messages/s to each controller, never saw a single bit error. To achieve that I used I2C bus isolators and the twisted pairs of network cables (power, SCL and SDA) to reduce EMI and crosstalk. Each signal must have both ends of its GND line connected on both ends.
    https://github.com/vnevoa/DiffTrike/blob/MarkIV_RasPi_NJAY/Electronics/PowerBridge/hw/bridge-ctrller-addon-schematics.pdf
    https://myownhybrid.wordpress.com/2014/09/21/integration-jam-session/

      1. In my paper I made some calculations for minimal and maximal values of the pull-up resistors, measured cable capacitances and made predictions that i later experimentally tested. Calculated minimum pull-up value, from the the 4mA current limit per pin the KL25Z has, is 750 ohm. But since it was used as a open collector output i guess I sinked maybe double that.

  10. I would love to see more low budget solutions using UART to low speed data over power line bridges.
    In some cases a 50m or longer live 220vac pair wired to a switch or breaker is all you will have to bridge the divide especially in legacy dumb systems you are trying to turn smart.

  11. The article was very well explained! I was able to immediately understand bus capacitance based on your diagrams, even though I always struggle with understanding capacitive coupling

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s