So I know that there are voltage thresholds that you need to keep but I am trying to send info to a display 40 feet away the display needs I2C and with that lenght it is not working the best.
So I am putting an arduino at the display to recive a signal and convert it for the display.
Limits, I only have 4 wires total, one power, one ground, and two for data. I have hope that the TTL serial will work to send the data from the first arduino to the second and then the second i will make to drive the I2C display.
"Rule of thumb" is (much) less than 40 feet, and "slower goes further", and "some chips do better than others." You can try it to see how it works, but if you get to the point where you need driver/receiver chips at either end it probably would make sense to use something designed for distance rather than TTL "Bus Drivers" and receiver circuits.
Are you sending 5V over your "power" wires? At 40 feet, you might just have a power problem...
The I2C standard was designed for intercommunications between chips on the same board or chassis. 40 feet is a streach and I can't really give you much advice other then possibly playing around with the two external I2C pull-up resistors values. There are special I2C drivers/extenders but I suspect they are not all that simple or cheap for the average hobbyist.
If you really want to be successful at this, you will want to look into what are known as "line driver"/"level converter" ICs; these are devices designed to convert a TTL (or other signal) so that they can be sent across long distance cables, then converted back. For instance, the commonly used MAX232 is such a chip, for conversion of serial data from 5V TTL to standard RS-232. There are others for such things as RS-422, among other standards. Some will allow you to just boost the TTL level up to 12V and back down at the other end; others perform more complex functions.
Think of the 40 feet of wire as a resistor (it will have some resistance, depending on length and gauge of wire), and design accordingly. Your best (and most documented) option, though, would be to send the data using RS-232, via a MAX232 (or equivalent) level conversion on each end.
I don't know if simple line driver/receiver chips will adapt well for I2C where the data and clock signals need to be bidirectional and pulled up externally and outputs tri-stated at the proper time?
I know that the I2C has the length limit. I am able to do 2 meters but if I coil the wire I lose the siginal. This is why I want to do something else using a more robust signal. I know that RS-232 can go 50 ft with normal wire but can be streched if you use low capacitance cable, I was hopeing that the TTL would be able to do the 40 feet if you gave t good wire but I think that I am limited to around 10 feet with the ttl.
Is there a chip to go from ttl to RS-422 or RS-485, I can find conectors that do this but they are around $50 and you need 2. This would be nice in that the 4000 ft limit is more than I would ever need. but with just the RS-232 I am not liking how close I am to the 50 ft limit.
As for the power, I am sending 12V and then regulating it down to 5 in the remote box. I know that the power will work like this.
The 40 foot line I can test on my bench, but I need to send it to my dad so he can install where it needs to go and then run it.
This is how I found out about the I2C coil problem. I had the wire un-coiled and it all worked fine for me with the 6 ft run. he did not need all the 6ft coiled the extra and made the system not work.
I am trying to design a proper system before I jump into it and just hope it always works.
I am going to get (2) MAX232 chips to test the RS-232 but I am also going to get (2) MAX3081, or MAX488E so if the RS-232 does not work I have a backup with the RS-422.
It looks like I would need to use twisted pair wire to do the RS-422 Does anyone know if Cat 5E would work for RS-422?
There are I2C buffer chips like the ADUM1250/1, bidirectional, isolated (if you want) and can sink 200mA IIRC so should be able to drive a longish line.
I know this is not the circuit but I just wanted to show Richard C. that I am not trying to just swap the I2C to TTL, I am going to use the arduino as the brains on both ends.
Doing this does leave me with the problem of checking the comunication between the arduinos. I am planing on using the TX and RX ports so I dont miss something but then I still need to check the data to make sure I get it all.
i had and Idea on how to do this but I would gladly take any input on better ways.
The First Arduino is only going to send data. about 3 times a second.
The data I was going to make my own packet The * is where the number data goes "SS**BGE" So a sample would be "SS0025B2G1E" Then I just need to have the reciver Check for the format if something is messed up in the packet for the reciver I can just go back and start looking for the SS of the next packet. I am working on the code that I would need to do this and will post both the TX and RX code when I get something but does this seem like an Idea that would work and keep the data in line?
All the options should work, even the TTL over 40' depending on the speed.
Electrically options 2 and 3 (interesting you chose RS-422 when 485 is way more common) will both work, the difference is that with 422/485 you cannot easily have a back channel so the comms is one way.
How secure does this link have to be? If you need to acknowledge the data reception then RS-232 is the best because that only needs 1 wire so you can easily talk both ways. You can do that with 485 as well but you'll be into enabling transmitters to arrange a half-duplex link. Much easier with a simple Rx and Tx.
It sounds like you've got the general idea for the comms, the format is quit specific and easy to test, once again if it's critical info then I'd add some more security in the form of a checksum or something.
Also, two Arduinos is a lot of overhead for a simple serial link, I think it's worth giving the I2C buffers I mentioned before a try.
Just thinking about the data format, the "SS**BGE", that's not what comes out of the ADC presumably, is that the format you will display on the LCD?
If so there's no point sending the alpha characters.
Here's a code snippet for receiving a packet I did the other day, it's cut down and not tested.
// assumes a format like <???>
// NOTES:
// no checking for buffer overflow
// will hang if ">" never received
// only designed for an app that has nothing else to do
//
boolean in_packet = false;
char buffer[30];
int bptr = 0;
void loop()
{
while(Serial.peek() == -1) {}; // wait for a character
char c = Serial.read(); //reading from the serial
if (c == '<') { // check for start of packet char, if not then ignore
bptr = 0;
in_packet = true;
while (in_packet) {
if (Serial.available()) {
incomingData = Serial.read();
if (c == '>') {
handleData();
in_packet = false; // end of packet
} else {
buffer[bptr++] = c;
}
}
}
}
}
void handleData () {
// deal with the data here
}
Since you only need to send in one direction, the 75179 is probably your best bet: it's widely available at a cheap price, and easy to interface (no charge pump caps like the MAX232, and only an 8-pi DIP). If you decide to go bidirectional, the MAX232 is cheap and easy. For really long links, the 75176 gives you RS-485 reliability, but you have the hassle of switching the direction back and forth if you only have two wires.
You had said you could use cat5? I am working on a project where I needed to send a pair of signals some distance. I ended up using a pr of max485 on each end, one for data the other for clock. I have ONE Arduino at the source and just the display at the end of the line. I tested to 80 ft with no problems. Maxim makes some chips that can work as full duplex with 2 pairs of wire. Cat5 is the proper impedance for rs485.
