Using RA Hardware on a Raspberry Pi / Beaglebone Black

[dcartier]

After giving up in disgust on using Atlas Scientific probes on my RPI/BBB, it occurred to me that RA hardware should be able to be interfaced to an RPI/BBB over I2C. The Atlas probes lack galvanic isolation, and are not a good fit in the hostile environment of an aquarium because of it. They (Atlas) have now started providing suggestions on how to add galvanic isolation (externally) before their modules, but I am running out of hair to pull out, so time to look elsewhere.

Roberto, I am guessing the USB connector of the probe expansions are (not in order) +5v, GND, SDA, SCL? I assume the expansion hub is an I2C switch?

One thing that gave me reason for pause, is that when I attempted to interface my RA to my Pi over serial, the PH probe became unstable. I have some opto isolator boards on hand to deal with this when I get back around to it, but I am wondering if a similar problem could occur if the expansion hub, probe module are hooked directly to my Pi/BBB (through a 3.3V <-> 5V level shifter of course)?

If it does not work out, I guess I could put the expansion hub on my RA along with the probes and interface the Pi/BBB over serial like I originally planned, but having a dependable set of probes able to be accessed directly from a Pi/BBB would be pretty cool for the RA and Pi/BBB communities.

Dennis

[rimai]

Correct. The usb is those lines (not in order).
The hub is indeed an I2C hub/switch.
You can definitely attach any RA expansion module directly to your Pi if you want to and don't even use the RA head unit.
You would need some sort of script to read the values from the module over I2C and you should be good to go.
There was one person I know of that use Pi with RA relay expansion modules and created her own web interface on Pi to interact with the relays. If I'm not mistaken, she also was reading pH and Salinity from the RA expansion modules. All those Ra modules were connected to the RA Hub and the input port of the hub was connected to Pi instead of the main relay box.

[dcartier]

That is awesome Roberto.

Do you remember the I2C switch part number so I can grab the datasheet to see what I am in for as far as interface code?

My immediate need is for an ORP probe hooked to my BBB, so I will use that as a test case. So for just 1 module I could forego the expansion module for testing?

I will try to use Python for this, and if I get it working, I will update this thread and post the modules for the community.

Dennis

[rimai]

Correct. You can connect the module directly to Pi.
PCA9518 is the part number. There is no code necessary for the hub whether you use it or not.
It will be transparent to RA or Pi.
You can also connect several modules to the same I2C bus, but that will increase capacitance and you may have too much that it will just stop working.

[dcartier]

Oh, I get it. It is electrically isolated, not logically isolated, so everything still needs its own unique I2C address. I as thinking it created separate I2C networks that you could multiplex. Well that is a non issue then.

Dennis

[dcartier]

Something just occurred to me, as I want to use the ORP probe for the purposes of tracking denitrification, is the RA ORP unit capable of reading negative ORP values? Surprising not many of the free standing controllers are able to be set to negative values, but I am not sure if this limitation applies to probe sensors as well. Please let me know

Dennis

[rimai]

Not sure the probe can do it.
I know the module can, but our libraries are coded to disregard the negative side.
You can create your own calculations.

[dcartier]

When you say libraries, you are referring to the RA libs in the head unit, not firmware in the module correct? That is assuming their is a uC in the module and it is not just a ADC -> I2C.

Dennis

[rimai]

Correct RA libs.
It is just an ADC->I2C. So, if you are doing it on python, you can just create your own mapping to be able to read the negative side.

[dcartier]

Awesome!! I will place the order when I get home tonight.

I have been creating graphs by having a webcam take a photo of a free standing (Milwaukee) controller every 5 minutes and then keying them into a spreadsheet for days now. This is going to be so much easier!!

Dennis

[dcartier]

Just as a follow up, using the RA hardware from RPI/BBB (in this case ORP module) is great. As expected, you just need to create some interface classes to allow them to be read over I2C.

Here is an example of the ORP class I created to allow the ORP module to be used. In the example I have hard coded the calibration data, but you could also pass it in. You can re-calibrate by instantiating a new object and calling readRaw() to get the unconverted value and then hard coding the value, or override the calibration datain the instances. In the example I had calibrated at 0mv (1480) and 400mv (367).

The class only depends on the Adafruit I2C library for communication.

Code: Select all

#!/usr/bin/python
from Adafruit_I2C import Adafruit_I2C

class RA_ORP(object):

    def __init__(self, address = 0x4C, busnum = 1, calibration = ( 1480, 367, 0, 400 )):
        self.i2c = Adafruit_I2C(address=address)     
        self.address = address
	self.calibration = calibration
	self.queue = []
    	self.lastRaw = 0
    	self.overCnt = 0
    	self.maxChange = 300
	self.maxOverCnt = 20
	self.queueLength = 20
	self.debug = 0


    def readRaw(self):
	return self.i2c.reverseByteOrder(self.i2c.readU16(0x00))

    def readSingle(self):
	return self.convert(self.readRaw())

    def read(self):
	value = self.readRaw()
	if self.debug: print "Raw value read:",value
        if self.lastRaw == 0 or abs(value - self.lastRaw) < self.maxChange:
                self.queue.append(value)
                self.lastRaw = value
                self.overCnt = 0
        else:
                self.overCnt += 1
                if self.overCnt > self.maxOverCnt:
                        self.overCnt = 0
                        self.queue.append(value)
                        self.lastRaw = value

        if len(self.queue) > self.queueLength:
                self.queue.pop(0)

	return self.convert(self.mean())

    def convert(self,x):
    	return (x - self.calibration[0]) * (self.calibration[3] - self.calibration[2]) // (self.calibration[1] - self.calibration[0]) + self.calibration[2]

    def mean(self):
    	n = len(self.queue)
    	if n < 1:
        	raise ValueError('mean requires at least one data point')
    	return sum(self.queue)/n

Dennis

[dcartier]

I am working on the planning for a new project that will require 2 PH expansion modules on a Raspberry Pi. I have found TCA9548A breakout boards that allow 1 to 8 multiplexing of the I2C bus, so that should take care of the address conflict between the modules. The multiplexer also allows for mixed voltage setups and does voltage translation. Yay!

What I am wondering about are pull ups on the SDA and SCL lines. I had a look at the ORP expansion schematic (there does not seem to be a PH one in the downloads), and it shows 10K pullups to the +5V line. Do all the expansion modules include their own pullups? If so that will make it a lot easier to interface to an RPI using a TCA9548A.

Last question, all the modules use their own power supply, so I expect that I can leave the +5V line on the USB interface disconnected? The RPI will be using 3.3V, so if I hookup only ground, SDA and SCL to the multiplexer I should be good?

Dennis