My Neptune Apex web interface compatible DIY reef controller

FYI - I don't have the dips with the Temp Sensor as you guys do. I'm running only 2, and they both work flawlessly.

Now sad times I broke one of my pH probes last night.
 
if you go to setup/sensors page, are the info for each sensor correct?

I just updated github with the following fixes
add temp range check back
fix lcd display for inverted outlets
add CELSIUS define to display temp in C
 
Here is the attached screen shot. (Sorry for the size, couldn't edit it on my iPhone and I'm not near a computer)

sensor.PNG


d0ughb0y - Yes it does show the correct info for both sensors.
 
that question was for mark/moomin, since the _cond and _ph info seems to be mixed up.

sorscode, did you keep the temp range check in the code? if it is there, then it is impossible to get a reading of 0 and 185.
 
if you go to setup/sensors page, are the info for each sensor correct?

I just updated github with the following fixes
add temp range check back
fix lcd display for inverted outlets
add CELSIUS define to display temp in C

Not quite what I am expectig for a fresh glass of saline!

Screen Shot 2014-09-17 at 17.16.10.PNG
 
try to change atlasSerialHandler function in Sensors.ino as follows

Code:
void atlasSerialHandler(){
#ifdef _PH
  for (int i=0;i      if (phdata[i].saddr.available())
      atlasHandler(phdata[i]);
  }
#endif
#ifdef _ORP
  if (orpdata.saddr.available())
    atlasHandler(orpdata);
#endif
#ifdef _COND
  if (conddata.saddr.available())
    atlasHandler(conddata);
#endif
}

the format above got messed up. just remove the word return in call to atlasHandler(...)
 
I'm running without checks. As I am running 1 revision behind your latest. I need to look at all your changes and migrate them over.
 
try to change atlasSerialHandler function in Sensors.ino as follows

Code:
void atlasSerialHandler(){
#ifdef _PH
  for (int i=0;i      if (phdata[i].saddr.available())
      atlasHandler(phdata[i]);
  }
#endif
#ifdef _ORP
  if (orpdata.saddr.available())
    atlasHandler(orpdata);
#endif
#ifdef _COND
  if (conddata.saddr.available())
    atlasHandler(conddata);
#endif
}

the format above got messed up. just remove the word return in call to atlasHandler(...)

sadly not, cond does not init with this change

Yours is on order, there must be bigger wins in the mean time?
 
I'm running without checks. As I am running 1 revision behind your latest. I need to look at all your changes and migrate them over.

ok, then perhaps it is using more than 2 that is causing it. Maybe the pullup resistor value needs to be changed. but only one sensor can be active at any time so the number of sensors in the circuit should not affect it much. And max current draw for each sensor is only 1ma.

wgraham, do you know if any of the temp sensors you are using has a built it pull up resistor? I think those that are packaged as probes do not have pull up resistor.

sadly not, cond does not init with this change

Yours is on order, there must be bigger wins in the mean time?

I'll be able to test this once I get my conductivity kit.


as to power supply, I checked the specs of the arduino mega voltage regulator, and it can handle the new EZO stamps.
 
I only have the test code for the led pwm driver working.
I will get my parts for the fan circuit this week, so will probably complete the fan hardware and software sometime next week.
I'll resume work on led after that.
 
I only have the test code for the led pwm driver working.
I will get my parts for the fan circuit this week, so will probably complete the fan hardware and software sometime next week.
I'll resume work on led after that.

Ok, if you want please run it past me, I have boxes and boxes of components so I can knock up circuits.

I have the I2c to PWm board, and a bunch of 350ma, 750ma, and 1000ma Constant current LED drivers.

M
 
This allows cond to init.

/////////////////////////////////////////////////////////
// Atlas Sensors Functions
/////////////////////////////////////////////////////////
boolean initAtlas(AtlasSensorDef_t &data) {
char responsechars[15];
responsechars[0]=0;
data.saddr.begin(38400);
for (int i=0;i<255,strlen(responsechars)==0;i++) {
if (data.type==_cond)//set conductivity stamp to return SG only, K=1.0
data.saddr.print("response,0\rc,0\ro,ec,0\ro,tds,0\ro,sg,0\rk,1.0\rr\r");
else {
#ifdef _PH_EZO
if (data.type==_ph) {
data.saddr.print("response,0\rc,0\rr\r");
} else
#endif
data.saddr.print("e\rr\r");
}
#if defined(_PH_EZO) || defined(_COND)
delay(1000);
#else
delay(384);
#endif
data.average=0;
getresponse(data, responsechars);
}
if (strlen(responsechars)==0) {
data.initialized=false;
return false;
}
data.value=atof(responsechars);
if (data.value>0) {
data.isReady=true;
data.initialized=true;
updateAtlas(data);
// data.isReady=false;
} else
//return false;
return true;
}
 
wgraham, do you know if any of the temp sensors you are using has a built it pull up resistor? I think those that are packaged as probes do not have pull up resistor.

I have the ones that are packaged as probes. I don't think they have pull ups. I had 4.7k pull up at first and then change to 3.3k and still the same thing. I haven't tried with just 2 probes to see if there any different.
 
I am using the pwm pins with transistor npn+pnp circuit to drive 3 fans, since I'm not using the pwm pins anymore and will be using the i2c pwm driver.

the led work will be all software work. I don't plan to do a diy led build just to test it. so I will just let people who need the feature test it.

from your changes, I'd say the r\r from the init string did not take, or more time is needed to get the value.

are you able to see one reading if you write a test sketch that sends this string?
"response,0\rc,0\ro,ec,0\ro,tds,0\ro,sg,0\rk,1.0\rr\r"

your changes basically initialized on a second r\r
hence either the first did not take, or program just need to wait a little longer.
 
also I notice the temp is only affect in the second and third probe the first probe is not affected.

if you switch the probes around, it still affects 2nd and 3rd?

my main suspect for this is the connection. I find the stereo plug I got the quality is not good. make sure nothing shorts when the cables are moved. likewise for the splitter.

I also did not see this problem when I have 2 temp sensors, and I was using the splitter I got from sparkfun. With 3 sensors, I am using a splitter I got from china, and I know I have to rotate the plugs a few times before I get a good contact and get good readings on the OneWire test sketch for DS18B20.

here is what you can do.
with all your temp sensors connected, run the OneWire test program.
monitor the readings on the serial monitor output and make sure you are not getting any wrong reading. once you see that, then load the chauvet program again, without moving any of the temp sensor connections and see if you still get the 0 reading.
 
Last edited:
Curious, what does the reset in misc setup do?

that is this

#define EEPROMSIG 0xA5

displayed in decimal

if you change the value, it will reset the controller to default values (defined in config.h) next time you reboot.
its probably not needed. I'm thinking of changing to use checksum instead of a signature value to test if eeprom needs to be initialized or not.

eeprom needs to be initialized if I change the structure of conf record. say I add a new field, like when I add LED.
 
Back
Top