Designing rugged logger (analog)

Hardware
1

I’m looking to see if I can use the IMP002 to design a rugged logger. Rugged in this case means survive in real-world conditions and assumes it has a nonvolatile store for logging to when WiFi isn’t present.
Rugged loggers are core architecture of many remote wireless devices. A couple of issues come up that look to me to be hardware at their root - and I just want to check before I go any further.
Requirement: a remote wireless sensor array for 20mA interface with a 0.1% accuracy ~ on a low power budget using low cost solar array/rechargeable battery.
So going through the hw/sw design some basic questions come up
Qu1) are there analog grounds associated with the ADC inputs.?
Qu2) What accurate and survivable calendar (absolute or wall) time functions are there?
Discussion: There is a squirrel builtin time() [described in hardware objects hardware.millis()] and the processor STM32 has an RTC/32Khz (BCD)with backup capability.
a) For remote wireless logger operation in the real world - wireless access points/signals can disappear for 3 months and the logger still needs to work and have reasonably accurate wall time.
b) Typically if something goes wrong in software a warm boot (watchdog) happens – can the calendar time survive this with minimal loss of accuracy. (software algorithm probably implemented internally in EI code)
c) On cold boot (performed by actions from real person) a device needs to get wall-time before it can start logging – and networks may not be available for time - so it may need to carefully manage its power to prevent premature running the battery down. (this is a software algorithm at cold boot - could be implemented by application code)

Many thanks for any insights or suggestions where to look to answer these questions. ?
In previous equipment designs these have been valuable to solve upfront.
I’d be happy to post more of the design thinking if it is of interest.

2

q1: there are no analog grounds, no. This is a limitation of the CPU in the CSP package; there are no AVSS connections available at all. If you want more accuracy, an off-chip SPI ADC is likely the best solution.

q2: the internal RTC has a 30ppm xtal, but in temperature extremes this could be worse. The backup power pin is not pinned out on imp002, so you need to maintain the 3.3v supply (well, down to 1.8v) for the RTC to continue running.

The RTC is not affected by reboots.

The only way to set the RTC is via the server connection. In release 27 we have “squirrel from cold boot” which allows you to control the flow from boot time, including entering 6uA sleep mode where necessary.

3

Hello Hugo
Thanks for the fast response. Wow so thats how you get the small footprint with the CSP package. For analog - and the STM32’s 12bit - I guess it becomes characterization of the implementation. Whatever the gnd layout my assumption is that active software especially WiFi would have the largest noise contribution. I’m looking at an I2C AS1538-BTSU but it is how to keep it simple.
Thanks for the insight into the RTC - that you are using it - my main concern from past projects is managing a “reliable” calendar time - reliable in this case meaning no surprises. Drift is OK, however corrupt time is not.

4

If we lose RTC time, and run squirrel from cold, we come up at the epoch - I think this is 20000101 but can’t remember exactly.

I’ve no idea if it’s possible to have a partial brownout that causes RTC time loss in such a way that the RTC has not detected it, though…