RTC time is offset when internet time is not available

[Cogswatch]

Describe the bug
Loom uses a time generated by the preprocessor at the beginning of compilation to synchronize the RTC to real time. This results in the RTC time being offset from real time anywhere from a couple minutes (if the user is uploading on the spot) to a couple of weeks (if the Loom binary is being compiled elsewhere, and then sent over email or otherwise) .

Hardware in Use
Any RTC

To Reproduce
Steps to reproduce the behavior:

1. Assemble a feather with an RTC
2. Configure Loom to take timestamps off of the RTC
3. Compile the code
4. Check serial and compare against expected time

Expected behavior
Once the board has finished being flashed, the recording time should be relatively accurate (off by > 10 min.). This must be true for all use cases, including those in which Loom is compiled elsewhere.

Additional context
This bug does not exist in any case where WiFi is involved, I.E. an ethernet hub, as Loom will automatically retrieve time using NTP. With that in mind, this should not have a significant effect on serious deployments, but could serve to impede smaller projects or prototypes. Since Loom can be compiled and then distributed with an unknown timeframe, the preprocessor generated time will not fit the constraints above, as the offset could be up to several weeks. Possible replacements include:

• RTC handshake over serial immediately post compilation
• Add internet capabilities to your project

[prototypicalpro]

Edited for clarity.

[Cogswatch]

Possible solution would be adding a NTP sync like handshake into the LoomLoader CLI if/when it gets developed, until then this is a low grade enough issue to put on the back burner. If the offset is more than a minute or so, remove the RTC battery and replace it after a minute or so, then recompile, in most cases, this should correct massive time differences that can occur while rtc is in storage.

[prototypicalpro]

Will be fixed with #57.

[BGoto808]

Loom's long compile time will result in the RTC not reading accurate values. As a soft fix, uploading Adafruit's RTC example code, https://learn.adafruit.com/adafruit-ds3231-precision-rtc-breakout/arduino-usage, while a 3V battery is connected will set the RTC to read accurate values. Then, you would upload your regular Loom code and the RTC would still have the correct values from the first code that was uploaded.

Finishing the refactor for Loom would fix this issue but for now, this would be the soft fix for now.

[MrKangs]

As a temporary solution, you can have a customized time on the config for the RTC so that you can turn up the board power on that time that the user set as. This code will be updated soon with an example code. If you really need it, then you can find it out in the RTC branch in the Loom code.

[MrKangs]

In the current state of Loom, the compile-time is extremely long which causes the RTC is always off by about 5 to 10 minutes compared to the real-time clock. The best solution to this problem will be reducing the compile-time, but, sadly, it is impossible at this state: there need some serious debugging and potentially rewriting the whole code.

Instead of solving the main problem, it is best for finding a temporary solution which is the user can input their local time so that it will not rely on the compile-time as a default time. This code currently in the RTC branch, but soon it will be integrated into the master branch. As you see below the image, you can get the correct time up to the seconds. For how to enter the time, on top of the Serial Monitor, where it says COM20 in the image, there is a text box that you can enter and click send set each part of the time.

[MrKangs]

As a temporary solution, you can have a customized time on the config for the RTC so that you can turn up the board power on that time that the user set as. This code will be updated soon with an example code. If you really need it, then you can find it out in the RTC branch in the Loom code.

This is no longer available on the RTC branch, instead, we updated a better solution on the RTC branch.

[MrKangs]

This code is now in the master branch. I will close this issue until we found a better solution by reducing the compile time.