Service Request handling

[try-except]

Hello all!
I'm working on a Low Power Data Logger and I need to communicate with various SDI-12 sensors without idling the processor. As far as I'm aware, this library cannot wait for a Service Request from a sensor and instead the recommended way is by setting a timer corresponding to the maximum time reported by the sensor or polling the line until a service request is heard. Since some sensors can take minutes to have measurements ready and this Data Logger will be running on a battery charged via solar panel, I can't really afford any of this options. This has lead me to decide to extend the rx ISR for this purpose.

I will be working on this feature the next months, so if anyone has any experience, ideas or information about how to implement this, please do contact me :) For now my idea is to set a awaitingServiceRequest flag and every time the rx ISR builds a character, check if the last 3 characters correspond to a<CR><LF> (a service request) and if so, tell the main loop that this sensor has its measurements ready. This should allow for easier integration of light and deep sleep in the main loop.

Has anyone tried to solve this before?

Please tell me your thoughts!
Simón

[neilh10]

Low Power is a great goal, however processors have different capabilities to achieve it. What is the processor you are intending to implement this on?
What is the calculation for the current power usage, and what would you hope to achieve with low power

For any open source software, the first stage is decoded the way the current code works. Can you describe it at the character level.?

The high level view starting point https://envirodiy.github.io/Arduino-SDI-12/index.html

The 2nd stage is to plan how you could test it, what would be the simplest sensor that could be a test reference platform.

[try-except]

I'm currently working with an ESP32, the idea is to migrate an older project from custom circuitry to Arduino, allowing us (I'm actually part of a bigger team) to integrate OTA, lower the manufacturing costs, etc.

I've already read through the source code actually, so yeah I can describe it at the character level. Honestly I'm a big fan of the ISR-based character reception, I wouldn't have come up with it myself.

Currently I'm using an ATMOS 22 anemometer as my test subject, but depending on the level of control needed during testing I might write an emulator for another ESP32 to act as a verbose SDI12 sensor.

[neilh10]

Oh very nice. I've worked through the current code for the mega1284 which is UART limited, and using port-bit bashing. I'm interfacing to an LT500 depth sensor, which also has the option of a RS485.
For me I found the SDI-12 port bashing implementation difficult to debug (high maintenance) and inherently unreliable design with the timing, lacking a CRC and sub-standard (https://sdi-12.org/specification) interface with +5V- that I stopped using the SDI-12 code, and swung to the RS485. I had bought the SDI-TRANS-SENSOR24 as a reference, as it states its fully compliant and would be very easy to test with. The current software failed miserably against it, so I switched to the RS485
However, SDI-12 has a lot of great characteristics.
If you have the UART interface there is tricky bit of hardware protocol to get around, and depends on the UART control features - the break I seem to remember -its inverted from the standard UART break. Only one silicon manufacture had implemented flexible enough controls to make it workable.
I haven't looked at the ESP32-? in depth. Each variant is getting more interesting. ESP32-S3? or C6?

I had thought of looking at the DMA - that is with a processor that has DMA capability, and setting up a stream of data from a port that has reliable timing and then can then be post processed. As its 1200baud, slow, and probably known packet timings - the low power DMA could be put to work, and the processor put to sleep. Just an idea.
Great to hear there might be some work on this.

[neilh10]

This might be of interest with a good discussion on tradeoffs https://jolonb.github.io/assets/pdf/final_report.pdf
based on the ESP32-WROOM UART with hw interface Fig 3.2 and protection circuitry including reverse protection LED - nice.

[try-except]

@neilh10 Thank you so much for your input. I'm working with an ESP-WROVER-B but we're still at a very early stage of prototyping, so it's likely that we move to another ESP on the way. I thought of putting the Ultra Low Power (ULP) Coprocessor to work while the main processor sleeps and wake it up when the service request had been received, but since the project requires that we stick to the Arduino framework and PlatformIO, working with the ULP proved to be a burden rather than a viable option and that's why I resorted to extending the SDI-12 library. For now I'm hoping that since the baudrate is so slow, the first start bit in the sequence could be used as a wake-up interruption and that the ESP will wake up fully before the next bit. Not sure if that will work out but we'll see :) Thanks also for the pdf, I'll take a look.

[neilh10]

Oh interesting you considered the ULP. I've been wondering about the ULPs. Seems like it is ideal for this type of protocol. I sometimes mentor EE final year students as an industry advisor, and one project they used the S3 and could have used the ULP for a hardware interface, but they stayed away from it as they couldn't see the benefit to the software architecture, and they where only implementing a hardware interface in software.
From an architecture design, the ULP becomes valuable when it decouples the processes, and the mW power saving in the overall power budget is worth the extra work.
Arduino code isn't good for reliability or even low power with its i/o stream model. For real-time low power, a buffer pool instead of streams is more reliable (I like Real-Time Design Patters by Bruce Powell Douglass)
Arduino code typically keeps complexity down by serializing the architectural functions. If concurrency is needed then it needs an architectural design. If the SDI12 processing function is serialized you are OK. If it is concurrent with other activity and specifically upstream communications activity then the ULP (and S3) would be worth considering upfront - and make later system level debugging easier.
Do look at the Wellington Uni analysis pdf - assuming you are putting in the full ESD protection, and going to drive the signal to +5V, there are some implementation tradeoffs.
Hope you will be able to put the changes in a open source fork :)