I2C Communications between 5v and 3v Arduinos....

[zboblamont]

Been round the houses on this puzzle as it has been my first venture into I2C, hopefully somebody can see where I have gone or am going wrong......

The Hardware is a remote self powered 5v Arduino paged to check an ultrasonic level probe (DYP...) which solution was found earlier from a Russian site using SoftwareSerial... It all works fine as a standalone 5v device, the problem lies in communications between it and a 3v Arduino which acts as the Radio Node, and the I2C connection.. The 3v also has an onboard RTC which was intended to interrupt the Node into action every hour, but currently that aspect is secondary to stable comms...

An alleged bidirectional I2C level converter (MH Level Converter is all I know) was set up on the 3v Node with approximately 1m of Cat5E connecting Vcc, Gnd, SDA and SCL from the 5v device, the shield grounded at the 3v Node/RF end only, but the arrangement ended up with garbage coming through over I2C, forwarded to the Gateway.... What should have been an hourly report at that stage was not working and two sets of batteries (3v and 6v) were rapidly depleting..

I discovered late at night (dark) that the Ultrasonic board was running continuously, as if the entire system was caught in a loop.

Running further tests on Master/Slave devices with one of Gammon's Wake-Up I2c routines did it become apparent that it worked, but when I inverted Slave and Master it did not. The converter did not appear to be bidirectional as claimed...
The flashing LED/Sleep routine worked fine if the 5v device was a Slave and the 3v Master, but worked intermittently when reversed, viz I2C back from the 5v device was not latching...
At least the routine demonstrated the TWI match interrupt worked....

Having read elsewhere that it is possible to run I2C from the Master by driving SDA and SCL lines LOW after SoftSerial is commanded "Begin" on the 5v, tried that but no difference at all....

I have a second separate Node running a JSN ultrasonic similarly set up and the exact same issues, my hope was that in resolving this one the same may be applied to the other, so any suggestions other than a can of petrol and a match?

[gohan]

May I ask you why you are not using the radio on the 5v arduino?

[zboblamont]

@gohan Historical - When this journey started off a little over a year ago, the comms selected was 433MHz, the RFM69 ran on 3v. A pack of "Whisper Node"'s were purchased with onboard RFM69s already optimised for low power, and have proven completely reliable, even with the few available pins.
The ultrasonic boards are where the 5v issue arises - The parking sensor type ultrasonic head suited gun-barrel mounting to the tanks, but every iteration tried either ran out of pins or would not run reliably on less than 5v, so eventually resigned to using a 5v pro mini for that specific duty and indeed it works perfectly in standalone duty.
The problem now was getting the readings back to the 3v to forward to the Gateway, which is where I2C comes in. Gammon's superb repository provided for an I2C interrupt driven 5v pro mini sleeping between commands sent by the 3v, the perfect solution.
What threw me was the four channel FET level converter, purportedly bidirectional and I2C capable, but clearly NOT. When I ran Gammon's flashing wakeup routine where the 3v was Master it worked perfectly, when the 5v was Master it gave intermittent responses.
In the absence of any suggestions, have a YF08E converter board sitting idle, so will try playing with that today, even though the information implies it will not work on long wires...

[gohan]

Why not using the level shifter to connect the ultrasonic sensor? You could use a small transistor to switch on/off the sensor only when needed, as for 5v power source you can use a single lipo battery and a booster (driven by the before mentioned transistor) or 2 lipo cells and voltage regulator.

[zboblamont]

@gohan Yes, had thought of that also... I had a latching relay set up to control the booster which powered the ultrasonic and the HIGH side of the level converter, it worked with one of the ultrasonics but not the other... Hence trying with the 5v pro mini where both worked flawlessly, then looking into the strange world of I2C...
The problem to begin with is the Whisper Node only has 3 usable pins on top of the SDA/SCL lines, 2 if I choose to power an onboard RTC with Vcc... I2C opens up the options at the cost of a small 5v pro mini...

Having run further tests from Gammon's site this morning I managed to get the 5v battery result correctly via the converter on I2C, so the converter does appear to work after all.
When the ultrasonic routine is called the board flashes away without stopping, and the result via I2C is nonsense but the battery voltage remains reported correctly...

Have some Google'ing to do it seems, I can only presume there is some conflict or corruption between SoftwareSerial and Wire libraries going on, somebody is bound to have it happen before...

[gohan]

How many pins do you need to connect the unltrasonics? In addition there is no need to use a relay for such a small power

[zboblamont]

@gohan Only the Trig and Echo, so two... but as said earlier, one of the ultrasonic boards refused to work via the converter previously, although had to look up my notes to find it was the JSN-SR04T-2.0 which is a straightforward pulsein measurement. Did not try the DYP-ME007 which uses SoftwareSerial as needed a common setup by the time it arrived... The DYP resolves to mm, the JSN to cm, and the identical transducers are neatly installed in the water and sewage tanks respectively in 3/4" to 1/2" female galvanised steel reducers on the end of 1/2" pipe, so extremely stable and durable...

The logic behind the signal relay may seem counter-intuitive, but it uses ca 30mA to latch in around 5ms, and being DPDT it enabled complete isolation of two circuits against any possible leakage, the penalty was using two pins on the MCU...

[bgunnarb]

@zboblamont This is maybe OT but I am extremely interested in the mechanical design of the "gun-barrel" mounting of the transducers. I have tried measuring the level in a septic tank using the DYP-ME007 transducer. It all works fine in open air but as soon as I mount the transducer in the tank, the measurement reported is that the tank is full to the brim, no matter what.

I suspected echos in the tank so I enclosed the transducer by a piece of PVC sewage pipe, 70 mm dia and 150 mm long, but this made no change. You mention 1/2" pipe. Is the transducer mounted at one end, transmitting through the pipe? How long is the pipe in that case? Any photo or drawing would be much appreciated!

[zboblamont]

@bgunnarb No worries, thought I had an old photo, but can't find it now, but the explanation is simple enough...
The transducer is a snug fit into a steel 3/4" to 1/2" female adaptor collar, nothing fancy. Had thought to caulk it in place, but wanted any moisture in the pipe to find it's way out. Neither has moved in the last six months, presumably the wire tension is sufficient (plus I injected a little PU foam in one of the collars to keep it taut).
The rest is more standard 1/2" threaded pipe and fittings as would be used for pressurised gas or water, essentially protecting and conveying the cable underground from the tanks (one sewage, one raw water).
It was assembled in parts because of the awkward route to above ground where an adaptor seals it to 16mm electrical duct, then up to the box.
The beauty of it is complete rigidity and the transducer is held at precisely 90 degrees to the surface. Ideally you want to mount the head 200mm+ above top water (deadband of the transducer), 300mm in this case works perfectly for actual range of about 1.5m.

PS - Echoes - Have no issues with the sewage holding tank, but I made sure to drill through the concrete roof near centre and still within reach of the access hatch to assemble. A septic tank has a constant TWL unless the outlet chokes up, if you park the sensor head 300-400mm above TWL you should get zero echoes, and 100 to 200mm warning of backup...

[wallyllama]

Is the level shifter closer to the 5v arduino? Or the 3v? Maybe losses in the cable are dropping the voltage below 3v. So maybe level shift after the cable run.

[zboblamont]

@wallyllama The converter was put up next to the 3v for that reason, the 5v degradation would be less an issue.
Subsequent to the original post however, now getting partial result in that the converter is passing on the battery status, so the problem does not seem tied to the converter but the programs being too long and with delays which clash with interrupts on I2C, and the timing aspect of both ultrasonic devices.
It certainly screws with SoftSerial for the DYP sensor, now looking at alternative comms...

[zboblamont]

@zboblamont After a lot of headscratching I solved part of this puzzle and feeling a little stupid. Nothing to do with Library conflicts, both Wire and softwareSerial work as they are supposed to, the level converter works perfectly, it was a combination of sketch issues and the manner in which sleep was invoked on both Master and Slave, as well as a problem ultrasonic board.
1 - The DYP-ME007Y I could only ever get to read on a Russian developed sketch using softwareSerial. Although I got the reading once, the Slave was locked in an endless loop in the background, never going to sleep or giving the battery reading. By doing the ADC battery measurement first at least I got both readings, but with the Slave running endlessly even with the ultrasonic board shut down, it was killing the batteries.
So I gave up on that one and switched to the second tank which uses time of flight calculation, readily incorporated as a function. This time I incorporated LED flashes so I could see what WAS and was NOT happening.
2 - The JSN-SR04T-2.0 Slave went to almost immediately per Gammon's sleeping Slave routine, would waken when prodded, but would not return a battery reading. The problem lay in Gammon's preparations prior to sleeping the Slave, where he turns off the ADC, but it remained off when awake. Commenting out the ADC shutdown at least solved that issue for now, at least the Slave gave the required readings and went to sleep, but... it never started again.
3 - The Master was going to sleep but never wakened on the onboard RTC alarm set to Int1. Switching to a straight Sleep period did not work either, until it finally it dawned that the Wire service may be interfering. Only when Wire was shut down and re-invoked after wakeup did both Master and Slave sleep and awaken as intended.

Left it running overnight, and it has been consistently reporting every 30 minutes, so will look again today at getting the DS3231M to work properly on the Master and read how to restart the ADC on the Slave.

Frustrating as a relative amateur, but lessons learned.
If there is no function to interrogate the DYP ultrasonic, may just order another device from China and hope it proves simpler, cheap enough even if it takes a month...