Hi, I would like to ask for advice about the implementation of code for my application.
I have an ESP32 mcu with Arduino, a Notecarrier and Notecard and a ultrasonic level sensor (A02YYUW Waterproof Ultrasonic Distance Sensor (3~450cm, UART, IP67) - DFRobot). I need the ESP32 and sensor to be in powered down and only power it once a day at 04:00h in the morning to make a water level measurement, transmit data and power down again.
Can you give me advice about the implementation/Arduino sketch for this?
This shows how the code is structured when booting the host MCU based on Notecard ATTN pin state. It also shows how to power down the host MCU via the call to the Notecard to change the state of the ATTN pin.
This may be a bit more sophisticated than what you’re looking for, but it has a lot of the components you’d look for in this type of application.
Notecarrier F Switch
Be sure to flip the ATTN pin switch to enable the Notecard to control the power to the host MCU.
Sensor Power
You may also want to cut the power supply to the sensor when the host MCU is off. According to the link you provided, the sensor supports 3.3V as a supply.
Looking at the schematic for the Notecarrier F
The ATTN pin control F_BAT voltage which broken out to the Notecarrier F headers. I didn’t check the current draw of the sensor, but if it’s too much, you may need a secondary converter wired to the battery that’s enabled by the ATTN pin. The ATTN pin is also broken out on the Notecarrier F headers.
Scheduling 4 AM measurements
The Notecard doesn’t have a way to wake up the host at a specific time, though that seems like a good feature request.
Prior to putting the host to sleep, use the card.time request to get the current time, and compute the number of seconds until the next 4AM, and use this as the input number of seconds the host MCU should sleep for. This may actually be the trickiest part of the whole application.
Remember the card.time request won’t return the time if it doesn’t have the Unix Epoch available yet, so you’ll need a strategy for resets of the device, and decide if you want the application to measure on device reset, or only at the selected interval.
Also card.time is in UTC. It does return an offset in minutes to compute the local time if you want to use 4AM local time. The local time offset is estimated from Notecard location. This will generally be based on cell tower location estimate (there are rare cases where the cell tower location will be wrong just because the information returned by the database lookup is wrong, so you may want an override mechanism in the Notecard environment variables to set the time zone offset manually if it’s way off)
Diagnostics
I recommend either using the hub.log request, or create your own Notefile to send some host MCU application diagnostics to the Notehub. That way when you’re device is behaving weird, you have some info about the behavior without needing to physically retrieve the device.
Host Firmware Updates
I recommend investing in enabling this feature prior to deploying the hardware. If you discover you need to change the host MCU firmware, and it’s not readily accessible, this will slow progress substantially. We’ve had other users in this situation before
It looks like you have an older Notecarrier F, but it does have the outboard DFU capabilities!
Use the switch labelled DFU, and make sure it’s pushed to “ON” side.
IMPORTANT
It is still possible to perform host firmware updates without these connections. But it requires the host MCU to manage it’s own update process. It can grab the bytes from the Notecard over it’s communication connection with the Notecard and install them manually.
So you don’t have to use this wiring to enable firmware updates, but it does make it easier from the point of view of developing the host MCU application.