Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Can not read measurements #89

Open
ErezFeuer opened this issue May 22, 2022 · 8 comments
Open

Can not read measurements #89

ErezFeuer opened this issue May 22, 2022 · 8 comments

Comments

@ErezFeuer
Copy link

ErezFeuer commented May 22, 2022

Hi

I am trying to use this library to interface Acclima soil sensors (TDT and with TDR315H) with Arduino/ESP32. When connecting the sensors and using the d_simple_logger.ino example sketch (after changing the DATA_PIN to fit my connections) I get communication with the sensors as their addresses and information show up. It seems that they immediately respond to the M! command with the time and number of measurements, but no measurements are retrieved after D0!. I have tried a few other examples with no success. I used different boards as well - ESP32 (pin 32), Arduino nano (pin 7) and Arduino Mega 2560 (pin 11), with all I get the same behavior.

They are all powered with 12v from a bench power supply, the data wires are all connect to the same pin on the microcontroller and the grounds are all connected.

In the image below, you can see the serial print that I get (using Arduino Mega 2560):
image
Thanks
Erez

@SRGDamia1
Copy link
Contributor

That's strange. The sensors are giving clear responses to the information requests, so the library is working. I have no idea why it would fail for the data commands.

Have you tried adjusting the "extra wake time" parameter when you send the commands? Per specifications, sensors are allowed to have up to 100ms "extra" time after a break before they have to be ready to receive a command. I doubt it would help you in this case, since the sensors are responding to non-data commands, but you might try it.

Are the results the same for the concurrent measurement requests?

@ErezFeuer
Copy link
Author

Thanks for the suggestions.
I have tried now:

  • sendCommand(command,100) for both M! and/or D0!
  • k_concurrent_logger.ino example with and without the extra time after a break

Still same results...

@SRGDamia1
Copy link
Contributor

Have you tested it with a non-Arduino logger? Does it work with that?

@duojianghuji
Copy link

That's strange. The sensors are giving clear responses to the information requests, so the library is working. I have no idea why it would fail for the data commands.

Have you tried adjusting the "extra wake time" parameter when you send the commands? Per specifications, sensors are allowed to have up to 100ms "extra" time after a break before they have to be ready to receive a command. I doubt it would help you in this case, since the sensors are responding to non-data commands, but you might try it.

Are the results the same for the concurrent measurement requests?

That's strange. The sensors are giving clear responses to the information requests, so the library is working. I have no idea why it would fail for the data commands.

Have you tried adjusting the "extra wake time" parameter when you send the commands? Per specifications, sensors are allowed to have up to 100ms "extra" time after a break before they have to be ready to receive a command. I doubt it would help you in this case, since the sensors are responding to non-data commands, but you might try it.

Are the results the same for the concurrent measurement requests?

Hi,

I have encountered the similar issue. Three Acclima sensors of different models (TDR 315H, TDR315L and TDT) were tested with both Arduino Uno and ESP32. All of them seems responded to the command but the it was unable to retrieve sensor response of TDR 315L. while the other two were working well. I tried both adjusting the extra wake time to 100ms, but no luck for both Uno and ESP32. I tested them with Apogee USB-SDI12 adapter, and the TDR 315L was working well. Any clues?
Screenshot 2022-10-08 192834
Screenshot 2022-10-08 194610

@andrewbierer
Copy link

andrewbierer commented Dec 20, 2022

I want to add to the discussion that I have Acclima 310-H sensors that behave similarly to OP. A single sensor at any address behaves as expected. When I connect another sensor to the same bus, a complete data "set" of the 5 elements will not be returned from the sensors. Has anyone come across a potential solution here?

Edit: Forgot to mention I am also using an Arduino Mega 2560

@Camilochiang
Copy link

Camilochiang commented May 16, 2023

I want to add to the discussion that I have Acclima 310-H sensors that behave similarly to OP. A single sensor at any address behaves as expected. When I connect another sensor to the same bus, a complete data "set" of the 5 elements will not be returned from the sensors. Has anyone come across a potential solution here?

Edit: Forgot to mention I am also using an Arduino Mega 2560

Im using a board with 4 sensors ports on it and I have the same issue. The SDi-12 command arrive to the board (There is a LED to confirm that), but none of the commands is actually aknoledge by the board (I cannot even change the address of the board nor read the different sensors)

@physikant
Copy link

I have been experiencing the same when using example D (and I think a few of the other examples) shipped with the library, and Decagon 5TM sensors.
Here, I had to use the 0R0! command instead of 0D0! to actually read the data of a sensor with address 0 (which is actually strange).

Nevertheless, the actual problem apparantly is the timing between sending the measure command (0M!) and the get data (0D0!) command. E.g., in the takeMeasurement() function of example D, after sending the measure command and getting the corresponding reply from the sensor, by default 30 ms is waited before clearing the buffer and calling the getResults() function. Within the getResults() function, the first thing done is sending the get data request. If I increase the delay in line 184 from 30 ms to 50 ms, the 0D0! command yields the expected results.
Apparently the sensor needs some time between different commands to be able to handle them properly.

@ErezFeuer
Copy link
Author

ErezFeuer commented Jun 10, 2024 via email

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants