You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Sep 7, 2023. It is now read-only.
Currently, i++ relies on having the readers and processors having their clock set the same (more or less, within one second or so is good enough). This is not always very robust, especially when working
with Raspberry Pis, which do not have a clock battery.
We should come up with some sort of system that makes i++ work regardless of these time differences. Note that this is a very delicate matter. It could complicate the implementation of the reader, and make it harder to implement alternative reader implementations. Also, what if the date changes on the reader?
The RFID readers have their own clock, which is battery-backed, but maybe it's not a good idea to have the system rely on this, especially if we want to introduce other reader technologies, such as BLE.
The text was updated successfully, but these errors were encountered:
Currently, i++ relies on having the readers and processors having their clock set the same (more or less, within one second or so is good enough). This is not always very robust, especially when working
with Raspberry Pis, which do not have a clock battery.
We should come up with some sort of system that makes i++ work regardless of these time differences. Note that this is a very delicate matter. It could complicate the implementation of the reader, and make it harder to implement alternative reader implementations. Also, what if the date changes on the reader?
The RFID readers have their own clock, which is battery-backed, but maybe it's not a good idea to have the system rely on this, especially if we want to introduce other reader technologies, such as BLE.
The text was updated successfully, but these errors were encountered: