pH Transmitter & DS2450

[pista01]

I finally connected my newly acquired pH transmitter I picked up on eBay. I know there has been some discussion on how to read pH probes for use in a DIY controller, so I thought I'd post what I did. I'm no electrical engineer, but it seems to work.



I'm using an old laptop power adapter that puts out 19 volts. The DS2450 is reading the voltage difference across the resistor. The transmitter adjusts the load on the current loop based on the pH reading. A good transmitter like the one pictured will let you adjust the output levels. For example, my transmitter is configured to draw 4ma at pH 7 and 20ma at pH 10. These are completely adjustable. I used these setting because my current software is setup to calibrate using pH7 and pH10 references. Then I just have to set the voltages read by the DS2450 at pH7 and pH10 within the controller. With my previous pH transmitter, I had to adjust these voltages every time I calibrated the probe. Now I just calibrate the probe to the transmitter. The voltage at pH7 is around 1 volt. At pH10 it's around 4.3 volts. I'm using the 0-2.5 volt mode for better resolution. I used a voltmeter to read the pH10 value because it's beyond the 2.5volts that the DS2450 can read. I'll only need to do this once since all further calibration is done in the transmitter. Normal pH values are in the 2.1 volt range. If the transmitter encounters an error, it sets the output to 20ma, which will show as 0 volts by the DS2450 since it throws the voltage out of range, but still under the max of 7 volts that the DS2450 can handle. The value my controller calculates is within .05 of the display on the transmitter. I suspect this is because I didn't use the DS2450 to read the pH10 reference. I may switch the DS2450 into 0-5 volt mode to read this value. The transmitter also provides the slope in mV/pH. The manual says between 54 and 62 mV/pH is optimal. My one year old probe is 50. Since it provides the slope, I may adjust my controller to use this slope value rather than using the voltages at 7 and 10 to calculate the slope. I can then use the voltage at pH7 as a starting point.

I have a second transmitter, so I'll try ORP next. I suspect it will work the same.


Steve

[ufans]

Steve,

How did you connect your Ph Probe to your transmitter. Does your transmitter have a BNC connection?

UFANS

[pista01]

It didn't come with a BNC connector. I attached one to the side of the case, then wired it to the terminals of the transmitter.

[funman1]

What controller are you using? PLC based or other?

[pista01]

I'm using a mini-ITX board running Linux. The controller is written in Java, with an embedded SQL server (Derby) and embedded web server (Jetty). All the sensors and switches are 1-wire devices. I develop it on Windows, then deploy the changes to the Linux box.

[funman1]

Wow, do you have a thread on that controller?
I'd like to know more..

[pista01]

Originally posted by funman1
Wow, do you have a thread on that controller?

No, not really. I did start a thread on another board several months ago, but the controller wasn't anywhere near finished then.

It's not like any of the controllers I've read about. It's probably far too complicated, but I wanted something with more control than using something like OWFS and batch files. With the 1-wire Java API, I'm able to have more granular access to the devices. I can trap for the various errors that crop up on the 1-wire bus, mostly CRC errors. Embedding a SQL server and web server keeps the entire controller within a single Java virtual machine. No need to load separate processes for SQL and web server. A single command line starts it all, on Linux or Windows (maybe MAC too, but I don't have one). Another aspect I'd like to explore is storing configuration data directly on the devices. Some devices can store files. Imagine a total cold boot (no configuration data in SQL) and having the missing configuration data load off the network. Another area worth exploring is a PC on standby that will remove the controller from the network if it dies, then insert itself as the bus master and take over.

I don't have the internals documented yet. I generated javadocs once for it and realized then how much coding I did on it. I'll go into a high level version of what I have.

Outside of Derby and Jetty, there are 3 main parts of the controller. Devices, profiles, and a logger. The devices are just objects that are centered around a specific hardware device, like a DS2450 A/D converter. These objects handle the I/O with the physical devices, as well as the error handling. One of the devices is a DS2409, which is a 2 port MicroLAN controller. I have three, which means I have 6 separate 1-wire networks. This gives me a bit more flexibility wiring the network and prevents one bad network from bringing down the entire network. Profiles are the logic. For example, one such profile is a lighting object. Within this I can configure the 1-wire device that controls the light and the schedules that determines when to turn the light on. A single schedule can be created to turn a light on between two time ranges on any day (or multiple days) of the week. Any number of schedules can be created for a light. I plan on dynamically changing these based on the sunrise/sunset of a particular latitude/longitude, but that will come later. I also have profiles for temperature, pH, and switches in general. I still need to add a moonlight profile. I'm adding a second temp sensor as input to the temperature profile to act as a backup for heater/chiller control. The temp sensors are cheap. I will put the second one in the sump and watch for too large of a differential between the two (could indicate a return flow problem). I may even strap one to the individual heaters to verify they are working. It would be trivial to monitor the temp sensor in the ballast and shut the power off if the ballast gets too high. All profiles can read/write to all devices. Profiles log data as well, at intervals specified in the profile configuration. The logger is the 3rd piece of the controller. Any errors are registered in the logger object, which then controls the notification. All events, whether they are errors or normal status messages, go through the logger. I can set different debug levels and control the log output. Some errors only notify if there are several errors from the same location in a row, like if a sensor repeatedly returns CRC errors or a temp sensor is reading too high or too low. CRC errors happen once in a while, especially with the temp sensor I stuck inside the magnetic MH ballast. It's rare to get notification for CRCs. Most of the time they happen once or twice in a row. Of course temps outside the set range produce notifications, as do any reoccurring device I/O errors. Right now I'm just notifying via e-mail, next I will have it IM me at work if I'm online. I'm thinking of SMS notification directly through a cell phone as well. I always loose my internet connection when there are power failures, even though everything I have is on a UPS. No point in notifying anyone of a power failure when the internet isn't working. I may put one of those flashing siren like lights behind the tank and trigger it when an error is triggered.

These three object types run in a loop. Once all the devices process (reads/writes), then all the profiles are processed, then the logger checks to see if it needs to process any error messages. Then the loop starts over. It takes about 8.5 seconds to run through a loop. Here is the normal log output for a single loop.

Run # 2252/10000
02-01-08 20:05:58.169: (Channel 1:setAllPortsOff) Channel 1
02-01-08 20:05:58.719: (Channel 3:setChannelState) Changing channel 0 - true
02-01-08 20:06:00.499: (Main tank temp:readTemperature) Current temperature is 26.75
02-01-08 20:06:00.849: (Sump Light:readSwitchState) Switch is on
02-01-08 20:06:01.199: (Heater:readSwitchState) Switch is off
02-01-08 20:06:01.549: (PC Actinic:readSwitchState) Switch is off
02-01-08 20:06:01.899: (PC White:readSwitchState) Switch is off
02-01-08 20:06:02.609: (Channel 2:setChannelState) Changing channel 0 - true
02-01-08 20:06:03.039: (Channel 3:setAllPortsOff) Channel 3
02-01-08 20:06:04.869: (Left MH Ballast Temp:readTemperature) Current temperature is 67.75
02-01-08 20:06:04.869: (Channel 1:setChannelState) Changing channel 0 - true
02-01-08 20:06:05.299: (Channel 2:setAllPortsOff) Channel 2
02-01-08 20:06:05.899: (Sump Temperature Profile:process) Fahrenheit: 80.15
02-01-08 20:06:05.907: (Left MH Ballast Temp Profile:process) Fahrenheit: 153.95
02-01-08 20:06:05.909: (Sump pH Profile:readpH) Current pH is 8.247021043661945
02-01-08 20:06:05.912: (Left MH Profile:process) on
02-01-08 20:06:05.914: (Right MH Profile:process) on
02-01-08 20:06:05.917: (Sump Light Profile:process) on
Loop completed in 8350 milliseconds

The first 12 lines are the devices and the MicroLAN devices switching between channels. In order to access a device, it's LAN segment must be turned on. I once thought about nesting LAN segments, but determined that the insanity level would be higher than my normal threshold. No, it doesn't print smiley faces in the log

For the SQL server part, everything is stored in the SQL database. Each profile saves it's state to SQL in every loop. If the controller dies for some reason (never has), the very last state is saved. The state data is loaded at initialization. It updates it configuration after so many loops have passed, which is currently set to 10,000. I can manually reload via the web page.

The web interface is a series of servlets. Some display historical data from SQL, some display data directly from the profile and device objects. Changing profiles is possible from the web interface as well, such as overriding a lighting schedule and force a light to go on or off for a certain number of minutes. One time I got notified because the tank temp had dropped too low. The heater wasn't large enough for the room temp. I logged in to the controller from work and turned on the MH lamps a couple hours early. There are a few servlets that output data in XML so it can be easily read by outside programs. I threw a quick Flash app together that displays the current status. Maybe one day I'll create an entire interface using Flash. More than likely I will create a front end for my BlackBerry, as I use it more than anything to monitor the controller.

I still have a lot more I'll be adding, like sump level monitoring/control (more monitoring than control at first) and water sensors around the tank and sump. Will be adding switch logging to SQL too. Eventually I will be adding a smoke alarm with a built in light, so I can trigger on the voltage across the bulb. I'm almost finished with the main functionality I wanted in the web interface, so I'll start moving on to the extra monitoring next.

The hardware itself is an old slot machine controller based on a mini-ITX board with 128MB RAM. I had a 2.5" hard drive I bolted on to the frame. I once ran the controller off a bootable USB memory stick loaded with Linux. It worked well, but had to come up with a way to move the SQL db to permanent storage. CD based Linux like Knoppix didn't work so well because of the 128MB RAM. Using a HD was easier by far.

On the surface it's seems way too complicated, but in reality everything is just a small piece that functions as a larger whole. The only limit is the number of 1-wire devices on a network. I effectively have 6 networks, so I can have hundreds of devices. Of course that wouldn't be very practical. There are other parts I didn't go into, like web security, preference settings, and the charting (which I still need to complete), debug levels, etc. Sometime soon I'll need to prioritize what needs to be completed first. So far I've been very happy with the performance and reliability. The basic controller (temp monitoring and light control) has been running for 2 years now, if not more. I've just been slowly adding functionality as I needed it.