Hey,

Thanks for the quick replies. I see what you mean about the protocol and hardware being different. I'm not that good with encoding protocol libraries. The project involves 1 x master (esp32) and 3 x slaves (VL53LOX). Unfortunately the expressly use I2C. I was considering putting an Arduino nano on each of the LV53OX devices then use RS485, but I feel like, logic 'NOT' gates and opamps transmitting I2C would be more elegant, smaller and easier.

Sorry about the slow reply, I'm in Australia and sent the last message at my bed time.

I've drawn a rough diagram of what I was talking about. Let me know what you think. Sorry, I couldn't find NOT gates so I've tied the 2 inputs of some NAND gates to make them functional NOT gates.

View attachment 181270

This TI paper describing the I2C bus might be helpful:

http://www.ti.com/lit/an/slva704/slva704.pdf

Among other things, it describes how every I2C device uses open drain outputs to connect to both lines, with pull up resistors providing the high signal, and every device only having the ability to pull it low. Since no device is capable of driving line high, there's no risk of ever shorting a high output on one device and a low output on another.

Your scheme doesn't include pull up resistors, meaning it currently has no way to drive signals high. At first glance I don't see how to add those pull ups without interfering with the output resistors on your op amps. (I'm not saying there isn't a way to get it done, just that I'm not seeing it.) Basically I'm not seeing how each device can switch between driving the line and releasing the line in your scheme.

There may be a way to fix this into something workable, but I don't think you're there yet. If you read through the TI doc above, I think you'll see why.

Also, looks like SparkFun may have a ready-made solution for you that doesn't require more microcontrollers:
https://www.sparkfun.com/products/14589

I don't want to take away the fun of creating your own solution, which can be very satisfying, but if you just want to get the job done, these boards might do it. And of course if you don't want to pay someone else for their board layout, you can always just get the chips yourself and incorporate them into your design:
https://www.nxp.com/docs/en/data-sheet/PCA9615.pdf

 

To be honest, I was wondering how the microcontroller drove it high. I knew they have 20k pull ups but I was praying they didn't use them for i2c.

Yes now I have a lot to think about.

I've seen people increase their i2c range to over 10M by simply using twisted pair with ground and signal... But I need reliability.

 

Hi ebeowulf17,

How do you think this might go (see ammended diagram below)? I have ordered the parts so I cant really check it now. But if you see any glaringly obvious mistakes or if you know of a better design please let me know. I'm still kinda new to electronics.

I already have some TH opamps and 2n222 transistors, just need to wait on the logic gates to arrive so I can test.

Thanks again for all your help!


(Sorry R3 should also be a 20k pull-up)

 

I've never done anything like this before.
What to you think are the odds of this not working at all?

Also, yes, you're right I do like the challenge of this kind of stuff and I'd rather pay a few dollars for the parts and design something myself, with more satisfaction, rather than pay $80 for 8 x $10 pre-made boards to accomplish the same thing (4 nodes, 2 boards per node, daisy chained).

 

Hi ebeowulf17,

How do you think this might go (see ammended diagram below)? I have ordered the parts so I cant really check it now. But if you see any glaringly obvious mistakes or if you know of a better design please let me know. I'm still kinda new to electronics.

I already have some TH opamps and 2n222 transistors, just need to wait on the logic gates to arrive so I can test.

Thanks again for all your help!


(Sorry R3 should also be a 20k pull-up)



View attachment 181278

At first glance, this one looks very promising. You're making great progress here. Unfortunately, I still have some concerns, one of which may be critical.

1) This may not be a problem at all, but I'll mention it just in case. You're showing BJT outputs driven by the op amps, whereas the I2C paper shows MOSFET outputs. MOSFETs can pull the voltage lower than BJTs, so this *might* effect something. If you have datasheets for both devices, you can check the input low threshold levels (including tolerances or min/max levels) to see if this is an issue. I would guess that it's fine, but still worth double checking.

2) Adding a transistor stage, whether BJT or MOSFET, inverts the logic of the op amps, so you'll need to double check the polarity of the +/- inputs to your op amps. If I'm reading it correctly, they'll need to be reversed.

3) This last one is the potential deal breaker... it looks to me like the first time either device pulls its SDA output low, the whole SDA bidirectional circuit will latch. Imagine the master pulls low. This causes U4 and U5 to drive signals to U6, which pulls the slave's SDA low (assuming logic polarity has been corrected.) The low signal at slave SDA forces a corresponding series of events to send signals which hold the master SDA low. Each side is holding the other side low, so the line never goes high again. Like most of my assertions, I'm not totally sure about this; please double check my logic.

 

I'm a bit scepitcal the it will work as you have drawn it.
But if you want to try, I'd use RS485 driver chips, not inverters and comparitors/opamps. Add a diode to the o/ps so they can only be pulled low, not driven high. But I think the data line will either lockup or oscillate.

 

I'm a bit scepitcal the it will work as you have drawn it.
But if you want to try, I'd use RS485 driver chips, not inverters and comparitors/opamps. Add a diode to the o/ps so they can only be pulled low, not driven high. But I think the data line will either lockup or oscillate.

Yeah, I just did a rough sim in LTspice, and it latched low as soon as I pulled it low from either side. Once low, always low, at least in that simulated version.

Makes me really curious how the NXP chip and corresponding SparkFun breakout board get it done. They've apparently found a way that doesn't require any external logic or steering components. I sure can't figure out how you'd do it, but of course it's their job to be much more clever than me in the realm of electronics!

 

Add a diode to the o/ps so they can only be pulled low, not driven high.

Don't the 2N2222s take care of that? Or are you suggesting that as a simpler option to replace them? Come to think of it, using comparators with open collector outputs would achieve the same thing without extra diodes or transistors... of course, this is all moot if the latching issue can't be resolved.

 

MAX485 chips would be a lot better that the logic used there. And the diodes with pullups on the o/ps of them should work, just cheaper that a transistor.
But the circuit design is flawed. It would be better to run RS485 between small micros, like Arduinos, and have them talk to the I2C devices.
RS485 is designed for long distance, I2C is not.

 

MAX485 chips would be a lot better that the logic used there. And the diodes with pullups on the o/ps of them should work, just cheaper that a transistor.
But the circuit design is flawed. It would be better to run RS485 between small micros, like Arduinos, and have them talk to the I2C devices.
RS485 is designed for long distance, I2C is not.

Doh! I misunderstood your diode comment before - you were referring to your RS485 suggestion, not to the posted schematic. That makes perfect sense. Sorry for my confusion there.

And I agree that the current plan is flawed. I do wonder if the NXP differential I2C transceiver would work without requiring micros. They claim to have it all figured out...

 

To be honest, I was wondering how the microcontroller drove it high. I knew they have 20k pull ups but I was praying they didn't use them for i2c.

Yes now I have a lot to think about.

I've seen people increase their i2c range to over 10M by simply using twisted pair with ground and signal... But I need reliability.

One way to extend i2c is lower the signal frequency. The normal frequency is something like 400 kHz. You can lower than.

 

Hi ebeowulf17,

Thank you so much for your feedback. So I've reworked the schematic and I think its looking better now. I'm not too sure about the type of mosfets I'm using, but maybe these'll do the trick. I still need to think about multiple slaves also and if these will work with this configuration.

I think I've solved all 3 of your earlier concerns. Fingers crossed. now all i have to do is buy a bunch of these mosfets.

 

What kind of information is being communicated between devices?
I agree with @dendad in post #29.

If you must use I2C devices, use a small MCU and get the I2C data. Then communicate between master and slaves using RS485.

 

Hi ebeowulf17,

Thank you so much for your feedback. So I've reworked the schematic and I think its looking better now. I'm not too sure about the type of mosfets I'm using, but maybe these'll do the trick. I still need to think about multiple slaves also and if these will work with this configuration.

I think I've solved all 3 of your earlier concerns. Fingers crossed. now all i have to do is buy a bunch of these mosfets.


View attachment 181373

Very clever! It took me a few tries to figure out what was going on, but I finally did. I believe you have the gates of the new MOSFETs (Q4 and Q5) being driven by the wrong line. If you connect them to the non-inverted line (the one connected to the inverting input of the op-amp) it seems to work. I wasn't confident in my understanding, so I simulated the circuit in LTspice and it worked after that small change.

I also tinkered a little more and made a version which uses comparators with open-collector outputs (which most, but not all comparators have) instead of op-amps driving MOSFETs. Of course, this messes with polarities again, so I had to twist the lines around. If you want to implement this change, make sure you pay attention to polarities!

Also, ignore the resistance values and component part numbers in my simulations. I just chose parts based on what I had models for and chose resistance values arbitrarily. I wanted to see the concept work, but I wasn't putting any effort into the details.

I will say that, although this works in simulation with ideal models of parts, it might be a tricky circuit in reality. There's a potential race condition where one MOSFET needs to switch at least as fast as (or preferably faster than) another switch changing states. As such, subtle specs about transition timing could be more important in this circuit than in most I've dealt with. My gut feeling is that it won't be a problem, but it's something to keep in mind.

 

Hi ebeowulf17,

Thank you so much for your feedback. So I've reworked the schematic and I think its looking better now. I'm not too sure about the type of mosfets I'm using, but maybe these'll do the trick. I still need to think about multiple slaves also and if these will work with this configuration.

I think I've solved all 3 of your earlier concerns. Fingers crossed. now all i have to do is buy a bunch of these mosfets.


View attachment 181373

gkeep:
Referring to your schematic in comment #32, you may have problems in how you use the TL084 op-amps. Your schematic does not show the power supply connections but I assume you are powering the devices between Vcc and ground. You have not shown a value for Vcc but I assume it is either 3.3V or 5.0V. If those are true assumptions about power connections, then there are two problems: (1)Input common mode voltage range of the TL084 and (2) output swing range of the TL084. Let's discuss each problem.

(1) From the datasheet for the TL084 we find that the minimum input (either + or - input) must be more than (about) 4V positive relative to the neg power terminal of the device. If inputs are below this level, device operation is not guaranteed; specifically, the output voltage may not respond to the input voltage levels as expected. For more info, search/read about "op-amp common mode voltage range."

(2) From the datasheet for the TL084 we find that the output terminal is not guaranteed to swing closer than about 3V to the negative power supply terminal. That is for light loading (>10K); for heavier loading (2K) the swing will not come within 4V of the power supply terminal. Thus, when the output terminal of the TL084 is "low" (i.e. at its minimum) it will almost certain turn the MOSFET partially or fully on, pulling the MOSFET drain voltage to ground. When the TL084 output swings to its max value, it will certainly turn the MOSFET fully on. Thus, the MOSFET will be "on" all the time, regardless of the TL084 input conditions.

There are many solutions but two of them are:
1. Power the TL084 from higher and bipolar supplies, e.g. +15V and -15V. A bad solution unless you already have such power available.
2. Instead of the TL084, use a device that is designed to operate between ground and one positive supply, e.g. +5, and having (a) a common mode range that includes ground and (b) an output swing that is rail-to-rail. Most op-amp suppliers offer many such devices.

Before you buy parts, simulate the circuit and make changes as necessary until it works as desired. Then order parts.

 

Hi Guys,

thanks for all the support. I did realise the opamps were wrong. So I will be using LM358 opamps, I hope they will be better suited, as im not 100% sure considering my limited knowledge and research. I also need to learn how to use LT Spice, I'll hopefully try and have a good go at it tonight. I've never used simulation software before so I will check those op amps will work. Unfortunately Ive already placed the order for LM358 opamps. So I'll find out soon enough if they are wrong.

Also
ebeowulf17, im not sure why the gate of Q3 and Q4 are going to the wrong differential signal? I thought N-channel mosfets get turned on from a negative signal. and as the Q4 should only be turned on (so the device on the right hand side can transmit), will be when the device on the left is not transmitting, and the line will be pulled high, making the line low after the first NOT gate (U4). that LOW signal will then switch on the mosfet Q4 and allow signal transmission.

 

Hi Guys,

thanks for all the support. I did realise the opamps were wrong. So I will be using LM358 opamps, I hope they will be better suited, as im not 100% sure considering my limited knowledge and research. I also need to learn how to use LT Spice, I'll hopefully try and have a good go at it tonight. I've never used simulation software before so I will check those op amps will work. Unfortunately Ive already placed the order for LM358 opamps. So I'll find out soon enough if they are wrong.

Also
ebeowulf17, im not sure why the gate of Q3 and Q4 are going to the wrong differential signal? I thought N-channel mosfets get turned on from a negative signal. and as the Q4 should only be turned on (so the device on the right hand side can transmit), will be when the device on the left is not transmitting, and the line will be pulled high, making the line low after the first NOT gate (U4). that LOW signal will then switch on the mosfet Q4 and allow signal transmission.

gkeep:
Using LM358 could still be problematic, although there is a fair chance of working. The problems are two.

(1) The input common mode voltage range includes ground (good) but does not include the positive power supply (bad); using 5V power, operation is guaranteed only for inputs up to Vcc-1.5V; i.e. 5-1.5 = 3.5V. If the logic gates you use are CMOS operating from 5V, their outputs will swing up to 5V--beyond the common mode range. This may not be a serious problem depending on the particular LM358 design you get; some LM358's guarantee "no phase reversal" outside the common mode range. That means the LM358 won't operate well as an amplifier, but it will still function correctly as a comparator. From the analysis I just gave, you can see that operation from a 3.3V power supply is not likely viable.

(2) The LM358 output swings close to ground (good), usually less than 100mV. Unfortunately, the output has a limited positive swing: power - 1.5V. (This can be improved a bit by providing a pullup resistor from the op-amp output to the power supply.) Using 5V power, that gives a max output of 3.5V. You must use a MOSFET that can be turned on with 3.5V. There are many such devices in the market, usually called "logic level MOSFET". Again, if using 3.3V power, the LM358 output swing is only guaranteed to reach 3.3-1.5 = 1.8V, placing an even more stringent requirement on the MOSFETs.

Obviously, if you have a choice of 3.3V or 5V operation, 5V presents fewer problems. Another (partial) solution would be to use LM339 (LM2903) comparators rather than op-amps. The comparators are faster switching than the op-amps and the LM339 outputs are open-collector NPN transistors; that is, a pull-up resistor is required but that allows a max swing up to the power supply voltage, easing the driving of MOSFETs. You might discover that the LM339 approach could eliminate some of the MOSFETs. Repeating earlier advice, the best op-amp choice would be a device called "rail-to-rail input/output op-amp."

There are many other circuit variations that offer solutions, but I am not offering to provide multiple designs (some quite different from your approach).

Despite all the discussion, I can find no mention of the speed (e.g. bits/sec) at which you need to operate. At very low speeds simpler circuitry may suffice. I have successfully used I2C (from a PIC microcontroller) to read a remotely positioned temperature sensor (HVAC thermostat), over a distance of more than 50 feet, using only a 4-conductor (power, ground, SDA, SCL) twisted wire (no shields) cable...at very low speed (12 bit data at 50us/bit). I did use a rather simple "trick" to achieve reliable operation. If (and only if) you can tolerate operation at such low speed, we can discuss the "trick" further; otherwise that ought to be in a separate thread (advice from more experienced forum users welcomed).

 

I thought N-channel mosfets get turned on from a negative signal. and as the Q4 should only be turned on (so the device on the right hand side can transmit), will be when the device on the left is not transmitting, and the line will be pulled high, making the line low after the first NOT gate (U4).

It's easy to get turned around on this stuff, so hopefully I get this right...

I believe there are two errors in your analysis there:

1) N channel MOSFETs are activated by a *positive* voltage on the gate, relative to the source (remember that in all transistor operations, it's the relative voltage between two terminals/pins that matters, not the "absolute" voltage relative to ground.)

2) At the moment when you want Q4 active, passing a signal from the slave device, the source pin, which is connected directly to slave SDA, is low and the signal from master to slave is high (idle state, provided by pull up resistors.) There's no need to pass a high signal through Q4, as that's the default state handled by the pull up resistors. When you need to pass a low signal, the source pin is being pulled low, so you need to drive the gate high. You want Q4 to be inactive when the master is transmitting (low) and only allow Q4 to be active when master is idle (high.) Since you need a high Q4 gate voltage, you want the non-inverted signal from the master lines.

 

As @TeeKay6 correctly points out there was no mention of desired data rates.

In all forms of communications the assessment of rate vs distance is critical.
If low data rates are acceptable then 4-20mA current-loop is a possible solution over long distances.

However, since multiple devices were mentioned my choice would be RS-485 network.

 

However, since multiple devices were mentioned my choice would be RS-485 network.

Good point!

Although it looks to me like the latest versions of the thread starter's ideas might work for simple bidirectional communication, it would get even trickier to implement with multiple slave devices. Might still be possible, but it's an awful lot of work to stretch a protocol so far from its intended use.