search

bablokb / pcb-pi-batman

A simple hat for battery based Pi projects
Creative Commons Attribution Share Alike 4.0 International
3 stars 1 forks source link

Schematic question #1

Open seamusdemora opened 3 years ago

seamusdemora commented 3 years ago

Note: It was confusing me trying to keep the pi-wake-on-rtc questions separated from the references to this repo - I'll try to keep my questions organized under the proper repo going forward.

  1. In the schematic area showing the DS3231, there is no pullup resistor shown on the 1PRE line (pin 3, DS3231).
  2. The 1PRE signal leaves this bounding box on J8, Conn_Active_Low.
  3. The 1PRE signal seems to reappear in the bounding box for the 74HC05 inverter on J3, Conn_Active_High, emerging from the inverter output with the same name & notation ON: High-> Low

Is this all as you intended? The data sheet says a pullup is required on the INT/SQW output, and seems to me the transition on pin 2 of the inverter should be Low -> High.

Finally, I could find no description of the battery... did I miss that? I ask because the DC-DC converter * U5 suggest a 3.3 volt battery is powering the RPi - is that correct?

bablokb commented 3 years ago

Hi,

  1. the pullup is in the upper right box, R1
  2. J8 is for external inputs that trigger on High-Low. This is optional, e.g. to add an external button.
  3. J3 is also for external inputs, that trigger on Low->High. I use this for touch-sensor buttons.

The diagram (Kicad) uses the names to connect all components together, i.e. nothing "leaves" a box and reappears, it is just to prevent clutter. All /1PRE are connected together, you could draw lines instead. So /1PRE off the flip-flop has four inputs: the push-button SW1, the DS3231, the external input from J8 and the (inverted) external input from J3 (via the inverter).

Regarding the battery: I use 3.7V LiPos. For the "minimal" PCB, I successfully used Adafruit's PowerBoost modules. For the hat-pcb I just attach a standard 18650 industry-lipo because the TPS61023 converter is on the hat. In both cases, the Pi is powered by 5V after DC-DC conversion.

I hope this helps.

seamusdemora commented 3 years ago

Another question:

Can you provide a brief explanation of what the 85-hwclock.rules file does?

bablokb commented 3 years ago

This is a rule for the udev-daemon. As soon as the kernel loads the rtc module and the rtc0 device pops up, the daemon executes the given command. You should read man hwclock for details, but the short story is: the commands sets the system-time from the time within the rtc (assuming the rtc keeps the time while the system is down).

I have read that this rule is no longer necessary but I noticed in my environments that this not valid.

seamusdemora commented 3 years ago

I have read that this rule is no longer necessary but I noticed in my environments that this not valid.

That's interesting... Like you, I have read that the RTC should typically "just work" wrt keeping system clock up-to-date. man hwclock sheds more light on the inter-relationships between the RTC, timesyncd and the "system time". I read it some time ago, but I was looking for something different. I'll re-read it.

I'm using an RPi 3B+ for my RTC developments. Currently it is also connected to my WiFi network, but when deployed, it must work with or without WiFi. I have largely assumed this will "just work", but now your experience makes me wonder. Furthering my confusion: it's not yet clear to me how the system arbitrates which of these two time sources is used, and I have learned that the DS3231 chip used in my RTC module is a counterfeit - so its' accuracy is in question.

Given this new uncertainty, I'm strongly motivated to test this. I'd appreciate your input on a test procedure: I'm thinking the best way to test this is as follows: turn off the timesyncd service: 

$ sudo systemctl stop systemd-timesyncd.service

And then monitor the system time "by observation" against a known-accurate clock. Any better ideas would be much appreciated.

bablokb commented 3 years ago

Usually a system will only update the system-clock once at boot time from the rtc and then at regular intervals from ntp time-sources. So for normal systems the (early) rtc-update is only useful for good timestamps in the boot logs. The system also detects if it's own system-clock is not exact and tries to take this into account during times without ntp-access.

I would not worry too much about a counterfeit model if you don't get near the specification-limits (e.g. low temperature or supply voltage). For a test, you should define the error you can live with (e.g. 1s per day) and then use your test-procedure and wait a few days (to keep your "sample" error low). And if you really have a long running system without internet access, you could also correct the time yourself once you know how far it is off.

If you really want to automate this, you could use something like http://worldtimeapi.org/api/timezone/ which will return the time without updating your clock, but of course you have the runtime of the request as well so this depends on the latency of your connection and of this service and how far your clock is off.