Atlas-Scientific / Ezo_uart_lib

Library for working with Atlas Scientfic EZO devices in UART mode
14 stars 4 forks source link

Continuous reading and get_reading #3

Open guestisp opened 1 year ago

guestisp commented 1 year ago

Simple question: when using a continuous reading every seconds, to get the latest ph i just have to do get_reading() ?

Simple code:


EspSoftwareSerial::UART SoftwareSerial1;
Ezo_uart EzoPH(SoftwareSerial1, "PH");

void setup(void)
{
   EzoPH.send_cmd_no_resp("C,1");
}

void loop() {
   current = EzoPH.get_reading();
   Serial.println("pH: " + String(current));
   delay(1000);
}

is this correct ?

Atlas-Scientific commented 1 year ago

No, that wouldn't work. If you want continuous mode readings you'd have to use receive_cmd. Generally we recommend not using continuous mode specifically because its hard to time reception when other code is happening. Actually I'd say most people should use I2C unless they have a good reason to use UART, because its more consistent, full featured, and lets you use multiple circuits more easily. That said, if you want to do this, it would look something like (off the top of my head, sorry for any errors)

EspSoftwareSerial::UART SoftwareSerial1;
Ezo_uart EzoPH(SoftwareSerial1, "PH");

const uint8_t bufferlen = 32;                       
char response_data[bufferlen]; 

void setup(void)
{
   EzoPH.send_cmd_no_resp("C,1");
}

void loop(){
  EzoPH.receive_cmd(response_data, bufferlen ); //this will wait for data
  Serial.println(response_data);
  delay(900); //you want the delay time to be less than the time it takes for readings so you don't skip any
}
guestisp commented 1 year ago

thank you. do you know if esp32 is able to use i2c on custom pins like with the softwareserial? because i'm already using i2c for a display and i would like to keep the pH board totally separated and not daisy chained to display

Atlas-Scientific commented 1 year ago

On the ESP32 you can actually, and the library can take an I2C object. This link should be a good explanation of how it works https://randomnerdtutorials.com/esp32-i2c-communication-arduino-ide/

Also there's nothing wrong with attaching multiple devices on the i2C bus, its designed for that

guestisp commented 1 year ago

do you have a very simple code, i2c is fine, to get the pH reading directlt as float value? continuos mode is not needed

Atlas-Scientific commented 1 year ago

You can modify this code from the I2C library, or you can use our sample code that isnt based on the library

guestisp commented 1 year ago

my biggest issue with i2c is to set the i2c mode automatically with and existing PCB. i saw is possible to set it via software, as the wiring (on esp32) is the same between uart and i2c (i can use any 2 pins for both protocols). any api to check if device is still in uarr mode so that i can change to i2c on each boot ? (in setup() method)

Atlas-Scientific commented 1 year ago

You shouldn't have to change it to I2C every time. You just set it once and the circuit will remember it on powerup

guestisp commented 1 year ago

Yes, that's fixed now but i'm having issues with the readings (totally unreliable), i've opened a support ticket.

guestisp commented 1 year ago

Now i'm using the i2c protocol , but reading are very very very inaccurate and unstable. Opened a ticket, but after a couple of responses, no more info. I would like to know what should I do with this sensor, having a +/- accuracy of 0.30 (ZERO DOT 30, not 0.003). Is so much fluctuating that even a calibration would be impossible.

Atlas-Scientific commented 1 year ago

That could be a number of different things, are you using isolation? If not I'd start there

guestisp commented 1 year ago

Yes, your insulated carrier board

Atlas-Scientific commented 1 year ago

Try it without isolation and see if that changes anything

guestisp commented 1 year ago

i don't have a bnc/SMA connector to use directly the Ezo board without the carrier

Atlas-Scientific commented 1 year ago

You can run jumper wires from the breadboard into the probe and probe ground inputs on the carrier board to use the bnc/sma connector

guestisp commented 1 year ago

tried without the isolator board. same unsable results. there is almost no difference between a more than 100euros Atlas ph and a 20 euros dfrobot gravity device, other than being 5 times more expensive

guestisp commented 1 year ago

if moves from 1.93 to 2.12... i have to measure an acid molarity, that's absolutely impossible with these variations, as i need something stable in the 0.01-0.02 range (10 times less than your acurracy but i'm getting 100 times worse).

guestisp commented 1 year ago

Probe tried was a milwaukee double junction and a Apera double junction

Atlas-Scientific commented 1 year ago

That is unusual, the pH circuitry has no inherent problems getting stable readings in the 0.01-0.02 range, and our customers get that accuracy when using good quality probes (ours or other manufacturers). But when noisy readings do occur the potential sources of noise are innumerable. Try clearing the calibration, rinsing the probe, and putting it into fresh calibration solution. Are the readings still noisy? Can you post a sample of the readings?

guestisp commented 1 year ago

i did a calibraton multiple times but that are useless if even the calibraton fluid is not stable

Atlas-Scientific commented 1 year ago

The calibration fluid should be stable, that's why I'm asking you to try it. You're gonna have to provide me with more details about your setup, I can't just keep making guesses about what you're doing. Did you try clearing the calibration? Can you post a picture of your setup?

guestisp commented 1 year ago

Which picture do you want ? It's a custom pcb with 4 pins connected to the isolator (GNC, VCC, SDA, SCL). I'm able to talk to the board properly, but readings are unstable, even when testing the ph7 or ph4 calibration solution (even after clearing the previous calibration)

Atlas-Scientific commented 1 year ago

Send a picture of the custom pcb with 4 pins connected to the isolator as well as the probe connected to the board and the calibration solution you're using. Basically everything that can be relevant to this issue.