10 October 2019

PROJECT: Solar Weather Station, Update #4 - RTC & FRAM

LINK TO PROJECT PACK

Turns out you can't just turn on the SGP30 (air quality sensor), wait a few seconds for it to warm up, and then take a reading. Instead you must burn-in the sensor for 12hrs after which you can obtain a baseline value. From this point on you need to:
  1. Fire up the sensor every hour or so and store the current baseline (as well as actually read the current air quality)
  2. Check that the stored baseline is not older than 1week, if it is then you must do the 12hour burn-in stage again
A scenario where #2 could happen is when the sunshine has not been so great and so the weather station has been without power for more than 1week. 

What all this means is that I need to check how much time has passes since a baseline has been measured/stored. To achieve this the easiest way would be to use an RTC (PCF2129) to log the time and FRAM (FM24CL64B-G) to record any values I need to store (like old baseline value and the time it was recorded).

RTC (PCF2129 vs DS3231)

After doing a bit of digging it turned out that most people tend to use the DS3231 a tried and true RTC whose behaviour is well understood in all sorts of implementations. Then you also have the PCF2129 which is a newer RTC that offers lower power consumption and is surprisingly cheaper (2.38AUD/1000pcs for PCF2129 vs 6.33AUD/1000pcs for DS3231).
NOTE 1: Dan has a good blog post comparing the two in terms of accuracy. The DS3231 is the winner here as is you can expect it to be fast by ~1sec/year, whereas the PCF2129 is expected to be slow by ~1sec/month. This was not a worry for me as I was expecting to sync up the RTC every once in a while.

On paper (or datasheet) it looked like the PCF2129 is a clear winner for me as it's typical 3.3V draw is 2.5uA (from both Vcc & Vbat), whereas DS3231 is a whopping 70uA from Vcc and 3.0uA from Vbat. But I wanted to see just how true this is so I tested both of them with my trusty 121GW:

What I found really put things in perspective. Here is the power consumption plot where both y-axis are to same scale:
And here is one where y-axis are properly scaled:
As you can see you can expect a power saving of x40 when using the PCF2129 (vs DS3231).
NOTE 2: Here is the Arduino driver I used for the RTC's, and here are the steps I used to test the power consumption (I was logging in ~0.2ms intervals, 121GW limit):
  • 0sec:     Log start (all OFF)
  • 20sec:   Vbat ON
  • 60sec:   Vcc ON
  • 260sec: Vcc OFF
  • 300sec: Vcc ON
  • 340sec: Vcc OFF
  • 380sec: Vbat OFF
  • 400sec: Log end (all OFF)

FRAM (FM24CL64B-G)

The next problem was where to store the baseline & timestamp value. I could have easily written the values in the non-volatile memory of nRF52 but this is limited to 10000 write/erase cycles (or 1.8x10⁹ with wear levelling). Whereas if I use FRAM then I can expect a write/erase cycle count of 1x10¹⁴. 
NOTE 3: This is not accounting for memory retention which is 10years for nRF52 (at 40°C) and 151years for FRAM (at 65°C for FM24CL64B-G).

To put things into perspective if I was to write values 8760times/year (once every hour) then each memory would last:
  • nRF52 (no wear levelling):    ~1year
  • nRF52 (with wear levelling): ~200000years
  • FRAM (FM24CL64B-G):          ~10000000000years

Interestingly enough when I was picking out the FRAM I finally managed to get a counterfeit module. Initailly I ordered the Fujitsu MB85RC64TA & Cypress FM24CL64B-G as both were identical in memory structure (8bits wide & 65311 addresses) and had pretty much the same I²C command format. 

What I quickly found out was that with the MB85RC64TA I could not successfully write/read values even though I was sending the correct address/data structure and received the expected acknowledge bit. I tried the same script with the FM24CL64B-G and it worked without any issues.
NOTE 4: The MB85RC64TA has a high speed mode (3.4MHz) which can mess things up if the master does not support it, but all my tests used the standard 100kHz speed. 

Getting out the logic analyser proved what I was seeing:
Finally having a closer look at the suspected counterfeit IC (MB85RC64TA) did raise a few questions:
  1. Why was the top & bottom surface (of same package) different?
  2. Why was the pin1 indent looking so shallow?
  3. Why does it look like the top surface has been polished and engraved with a laser?
NOTE 5: CTISMT have a couple of really good presentations on how to spot counterfeit components. 

No comments:

Post a Comment