Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Jul 01 16:35
    Makuna updated the wiki
    Home
  • Jul 01 16:29
    Makuna closed #125
  • Jul 01 16:29
    Makuna labeled #125
  • Jul 01 10:47
    pilnikov edited #125
  • Jul 01 10:47
    pilnikov edited #125
  • Jul 01 10:43
    pilnikov edited #125
  • Jul 01 10:26
    pilnikov opened #125
  • May 28 02:30
    brewmanz edited #124
  • May 28 02:29
    brewmanz opened #124
  • Apr 06 22:03
    seamusdemora opened #123
  • Jan 20 22:57
    hofben updated the wiki
    RtcDateTime-object
  • Jan 05 18:24
    Makuna closed #122
  • Jan 05 13:22
    coreydaley opened #122
  • Sep 29 2020 21:20
    Makuna unlabeled #110
  • Sep 29 2020 21:20
    Makuna closed #110
  • Sep 29 2020 21:15

    Makuna on master

    enable travis build using platf… (compare)

  • Sep 29 2020 21:15
    Makuna closed #116
  • Sep 23 2020 20:22
    Makuna closed #120
  • Sep 23 2020 20:22
    Makuna updated the wiki
    FAQ-#5
  • Sep 23 2020 20:13
    Makuna updated the wiki
    FAQ
CTS
@connessionetech
Thank you. I will get new battery and check and report back. I really appreciate your response 💪 in helping out.
CTS
@connessionetech
Battery it was 😇
Albertox0404
@Albertox0404
hi
I have an ESP32 and a DS3231, the library works very well but I have another device connected to pin 22 (SCL) and because of this randomly both devices stop working until the microcontroller is completely reset.
How can I change the ESP32 pins to use a pin that is not busy? I have tried the example of "DS3231_Simple" the part of "Wire.begin (16, 17);" which is supposed to work on an ESP-01 but on ESP32 it does not work for me. This information always shows that it is not communicating correctly (If I put pins 21 and 22 then everything works perfectly for a while (due to the other device))
RTC lost confidence in the DateTime!
85/165/2009 37: 165:
-0.25C
Thank you
Michael Miller
@Makuna
@Albertox0404 Review Makuna/Rtc#37 and specifically This Reply
Michael Miller
@Makuna
And for Esp32, they think the issue is fixed espressif/arduino-esp32#349
Michael Miller
@Makuna
And espressif/arduino-esp32#2261 Has lots of great suggestions for tracking down the culprit.
Michael Miller
@Makuna
And it looks like others are seeing it with (open issues)[espressif/arduino-esp32#1998]
I would suggest bringing this up to the Esp32 guys.
Michael Miller
@Makuna
BTW, I just added a method to check for an error code and updated the samples to show how to use it.
Florian Laforest
@NatsuOnFire
Hi, why "RtcDateTime now = Rtc.GetDateTime();" return : "15/31/2099 00:10:32" and not the real now ?
Michael Miller
@Makuna
@NatsuOnFire What sketch are you using? There can be many reasons without having a context of what you are doing. Like, has the time ever been set on the RTC? Did the check for IsDateTimeValid() return false? What does Rtc.LastError() return?
Florian Laforest
@NatsuOnFire
@Makuna I run "DS1302 Simple", first initialization when the condition "if(now > compiled)" => nothing
I change the code, "if(now > compiled)" => Rtc.setDateTime(compiled) and it's perfect
I remove it after and now it's the real dateTime and not "15/31/2099 ..."
Michael Miller
@Makuna
@NatsuOnFire I guess the samples should check if the delta in time is greater than specified amount rather than just less than or greater than.
victorh800
@victorh800
hi. regarding the RtcDS3231 class, why is the temperature returned as a RtcTemperature object instead of an int or a float? I do understand that the library has to do some math manipulations with a pair of 8-bit registers from the chip in order to reconstruct the actual value. but I don't understand why such math was abstracted away from RtcTemperature::GetTemperature() method into a wholly new class. maybe I'm failing to understand the rationale for this. library version: 2.3.2
Michael Miller
@Makuna
@victorh800 There two main reasons for this design decision.
1) Any object that can multiple representations (C or F) will need conversion helper routines, so standard OOP is to provide to an object that you can access association methods.
2) In the case of Arduino, not all platforms support float natively; so the use of float at all can be expensive for program memory (all the routines to support it) and program memory to contain it (32 bits) Arduino Float. My representation is only 16 bits and leaves the decision to use it as floats to the sketch owner.
An example of a very restricted Arduino is the ATTiny platforms; where the most common have only 512 bytes of ram, and the less common have less.
victorh800
@victorh800
indeed, I just noted that when I switched from AsCentiDegC() to AsFloatDegC()the program storage space from a test sketch jumped up + 8kiB! I agree with that design decision.
however I'm still curious why this code
int16_t scaledDegC = ((highByteDegreesC << 8) | (lowByteDegreesC & 0xC0)) >> 6; _centiDegC = scaledDegC * 100 / 4;
resides in the RtcTemperature constructor and not in the RtcDS3231::GetTemperature() method, which is conceptually closer to the hardware from it gets the data.
Michael Miller
@Makuna
This came down how long you store the value and then how often you convert it. If you only store and use (like print it) once for the lifetime of the RtcTemperature, there is no real difference of it being in either location. If you keep the RtcTemperature around and print it (use it) more than once, then you would run that convertion each time you print it; thus less optimal.
Also, on the theory side of this, that calc is about how the hardware stores and sends the data, so it converted at construction to a standard. When used, it is converted to the sketch needs at that point.
victorh800
@victorh800

interesting. having myself worked in the past on very restricted environments (e.g. a PIC with 256 bytes of RAM), I always paid attention to whose details. but more recently I've been working on a bigger hardware (Arduino MKR) and suddenly I forgot to consider such nuances and optimizations.

thank you very much for your promptly input!

koosiekloek
@koosiekloek
hi Everyone
koosiekloek
@koosiekloek
i am fairly new to Arduino so sorry if i ask stupid questions. i am using a Arduino pro mini with DS1302 RTC my code is the ds1302 simple example with only the connection pins and time delay changed. the problem is every second loop that displays time gives 00/00/2000 00:00:00 and the very next loop gives correct time. what is the problem here and how can i fix it please, thanks for any help!
Serial log
09:50:54.530 -> 04/18/2019 09:50:43
09:50:59.551 -> 00/00/2000 00:00:00
09:50:59.551 -> RTC lost confidence in the DateTime!
09:51:04.527 -> 04/18/2019 09:50:53
09:51:09.515 -> 00/00/2000 00:00:00
09:51:09.561 -> RTC lost confidence in the DateTime!
09:51:14.547 -> 04/18/2019 09:51:03
09:51:19.525 -> 00/00/2000 00:00:00
09:51:19.572 -> RTC lost confidence in the DateTime!
09:51:24.561 -> 04/18/2019 09:51:13
09:51:29.526 -> 00/00/2000 00:00:00
09:51:29.580 -> RTC lost confidence in the DateTime!
09:51:34.531 -> 04/18/2019 09:51:23
09:51:39.557 -> 00/00/2000 00:00:00
09:51:39.557 -> RTC lost confidence in the DateTime!
09:51:44.527 -> 04/18/2019 09:51:33
09:51:49.532 -> 00/00/2000 00:00:00
09:51:49.579 -> RTC lost confidence in the DateTime!
09:51:54.566 -> 04/18/2019 09:51:43
09:51:59.537 -> 00/00/2000 00:00:00
09:51:59.537 -> RTC lost confidence in the DateTime!
09:52:04.560 -> 04/18/2019 09:51:53
09:52:09.547 -> 00/00/2000 00:00:00
09:52:09.547 -> RTC lost confidence in the DateTime!
09:52:14.525 -> 04/18/2019 09:52:03
Michael Miller
@Makuna
@koosiekloek What did you change the delay to? The sample uses 10 seconds. Does it work correctly with 10 seconds? If it does, try slowly decreasing the delay until it doesn't work anymore. I suspect there is a required delay time between transactions that is not correctly accounted for in the ThreeWire.h.
Michael Miller
@Makuna
Also, make sure the pins you are using are not used for something else.
koosiekloek
@koosiekloek

i changed Delay now as below seems 10sec is working fine but i need a bit shorter time per loop as i will have button input for logging as well. always every second display is wrong down to 1sec delay at 0.5 sec delay two displays are right then two displays are wrong? seems like only uneven number of seconds can be displayed? see last log of 0.7sec Delay only uneven seconds are displayed?
10 Sec Delay
10:17:46.085 -> compiled: Apr 18 201910:17:35
10:17:46.138 -> 04/18/2019 10:17:35
10:17:46.138 -> RTC lost confidence in the DateTime!
10:17:46.185 -> RTC is the same as compile time! (not expected but all is fine)
10:17:46.285 -> 04/18/2019 10:17:35
10:17:56.197 -> 04/18/2019 10:17:45
10:18:06.201 -> 04/18/2019 10:17:55
10:18:16.201 -> 04/18/2019 10:18:05

7 Sec Delay
10:20:56.795 -> compiled: Apr 18 201910:20:45
10:20:56.795 -> 04/18/2019 10:20:45
10:20:56.842 -> RTC is the same as compile time! (not expected but all is fine)
10:20:56.896 -> 04/18/2019 10:20:45
10:21:03.833 -> 00/00/2000 00:00:00
10:21:03.880 -> RTC lost confidence in the DateTime!
10:21:10.845 -> 04/18/2019 10:20:59
10:21:17.843 -> 00/00/2000 00:00:00
10:21:17.881 -> RTC lost confidence in the DateTime!
10:21:24.833 -> 04/18/2019 10:21:13

5 Sec Delay
10:23:07.322 -> compiled: Apr 18 201910:22:55
10:23:07.375 -> 04/18/2019 10:22:55
10:23:07.375 -> RTC lost confidence in the DateTime!
10:23:07.422 -> RTC is the same as compile time! (not expected but all is fine)
10:23:07.475 -> 04/18/2019 10:22:55
10:23:12.444 -> 00/00/2000 00:00:00
10:23:12.444 -> RTC lost confidence in the DateTime!
10:23:17.464 -> 04/18/2019 10:23:05
10:23:22.438 -> 00/00/2000 00:00:00
10:23:22.438 -> RTC lost confidence in the DateTime!
10:23:27.415 -> 04/18/2019 10:23:15

3 Sec Delay
10:24:48.776 -> compiled: Apr 18 201910:24:37
10:24:48.776 -> 04/18/2019 10:24:37
10:24:48.814 -> RTC lost confidence in the DateTime!
10:24:48.861 -> RTC is the same as compile time! (not expected but all is fine)
10:24:48.908 -> 04/18/2019 10:24:37
10:24:51.894 -> 00/00/2000 00:00:00
10:24:51.894 -> RTC lost confidence in the DateTime!
10:24:54.864 -> 04/18/2019 10:24:43
10:24:57.879 -> 00/00/2000 00:00:00
10:24:57.879 -> RTC lost confidence in the DateTime!
10:25:00.892 -> 04/18/2019 10:24:49

1 Sec Delay
10:26:01.916 -> compiled: Apr 18 201910:25:50
10:26:01.963 -> 04/18/2019 10:25:50
10:26:01.963 -> RTC lost confidence in the DateTime!
10:26:02.017 -> RTC is newer than compile time. (this is expected)
10:26:02.064 -> 00/00/2000 00:00:00
10:26:02.064 -> RTC lost confidence in the DateTime!
10:26:03.069 -> 04/18/2019 10:25:51
10:26:04.071 -> 00/00/2000 00:00:00
10:26:04.071 -> RTC lost confidence in the DateTime!
10:26:05.065 -> 04/18/2019 10:25:53
10:26:06.052 -> 00/00/2000 00:00:00
10:26:06.099 -> RTC lost confidence in the DateTime!
10:26:07.041 -> 04/18/2019 10:25:55

0.5 Sec Delay
10:27:01.559 -> compiled: Apr 18 201910:26:50
10:27:01.612 -> 04/18/2019 10:26:50
10:27:01.612 -> RTC is older than compile time! (Updating DateTime)
10:27:01.659 -> 00/00/2000 00:00:00
10:27:01.659 -> RTC lost confidence in the DateTime!
10:27:02.180 -> 00/00/2000 00:00:00
10:27:02.180 -> RTC lost confidence in the DateTime!
10:27:02.668 -> 04/18/2019 10:26:51
10:27:03.139 -> 04/18/2019 10:26:51
10:27:03.663 -> 00/00/2000 00:00:00
10:27:03.663 -> RTC lost confidence in the DateTime!
10:27:04.182 -> 00/00/2000 00:00:00
10:27:04.182 -> RTC lost confidence in the DateTime!
10:27:04.683 -> 04/18/2019 10:26:53
10:27:05.185 -> 04/18/2019 10:26:53

0.7 Sec Delay

10:35:32.521 -> compiled: Apr 18 201910:35:21
10:35:32.574 -> 04/18/2019 10:35:21
10:35:32.574 -> RTC lost confidence in the DateTime!
10:35:32.621 -> RTC is the same as compile time! (not expected but all is fine)
10:35:32.674 -> 04/18/2019 10:35:21
10:35:33.378 -> 04/18/2019 10:35:21
10:35:34.083 -> 00/00/2000 00:00:00
10:35:34.083 -> RTC lost confidence in the DateTime!
10:35:34.734 -> 04/18/2019 10:35:23
10:35:35.489 -> 04/18/2019 10:35:23
10:35:36.138 -> 00/00/2000 00:00:00
10:35:36.192 -> RTC lost confidence in the DateTime!
10:35:36.842 -> 04/18/2019 10:35:25
10:35:37.544 -> 04/18/2019 10:35:25
10:35:38.249 -> 00/00/2000 00:00:00
10:35:38.302 -> RTC lost confidence in the DateTime!
10:35:38.951 -> 04/18/2019 10:35:27
10:35:39.655 -> 00/00/2000 00:00:00
10:35:39.709 -> RTC lost confidence in the DateTime!
10:35:40.361 -> 00/00/2000 00:00:00
10:35:40.415 -> RTC lost confidence in the DateTime!
10:35:41.064 -> 04/18/2019 10:35:29
10:35:41.767 -> 00/00/2000 00:00:00
10:35:41.820 -> RTC lost confidence in the DateTime!
10:35:42.472 -> 00/00/2000 00:00:00
10:35:42.525 -> RTC lost confidence in the DateTime!
10:35:43.176 -> 04/18/2019 10:35:31
10:35:43.879 -> 00/00/2000 00:00:00
10:35:43.879 -> RTC lost confidence in the DateTime!
10:35:44.583 -> 04/18/2019 10:35:33
10:35:45.288 -> 04/18/2019 10:35:33
10:35:45.991 -> 00/00/2000 00:00:00
10:35:45.991 -> RTC lost confidence in the DateTime!
10:35:46.693 -> 04/18/2019 10:35:35
10:35:47.397 -> 04/18/2019 10:35:35
10:35:48.055 -> 00/00/2000 00:00:00
10:35:48.102 -> RTC lost confidence in the DateTime!
10:35:48.760 -> 04/18/2019 10:35:37
10:35:49.507 -> 04/18/2019 10:35:37
10:35:50.209 -> 00/00/2000 00:00:00
10:35:50.209 -> RTC lost confidence in the DateTime!
10:35:50.868 -> 04/18/2019 10:35:39
10:35:51.572 -> 00/00/2000 00:00:00
10:35:51.619 -> RTC lost confidence in the DateTime!
10:35:52.320 -> 00/00/2000 00:00:00
10:35:52.320 -> RTC lost confidence in the DateTime!
10:35:53.022 -> 04/18/2019 10:35:41
10:35:53.680 -> 00/00/2000 00:00:00
10:35:53.726 -> RTC lost confidence in the DateTime!
10:35:54.384 -> 00/00/2000 00:00:00
10:35:54.431 -> RTC lost confidence in the DateTime!
10:35:55.088 -> 04/18/2019 10:35:43
10:35:55.795 -> 00/00/2000 00:00:00
10:35:55.795 -> RTC lost confidence in the DateTime!
10:35:56.498 -> 00/00/2000 00:00:00
10:35:56.498 -> RTC lost confidence in the DateTime!
10:35:57.202 -> 04/18/2019 10:35:45
10:35:57.905 -> 00/00/2000 00:00:00
10:35:57.905 -> RTC lost confidence in the DateTime!
10:35:58.609 -> 04/18/2019 10:35:47
i am using A1, A2, A3 that is not used to my knowledge
koosiekloek
@koosiekloek
Delay on 0.1 Sec is very interesting. might there be some problem in the library math that dislikes even seconds?
00:00:00
10:40:42.145 -> RTC lost confidence in the DateTime!
10:40:54.829 -> compiled: Apr 18 201910:40:43
10:40:54.876 -> 04/18/2019 10:40:43
10:40:54.876 -> RTC is the same as compile time! (not expected but all is fine)
10:40:54.976 -> 04/18/2019 10:40:43
10:40:55.030 -> 04/18/2019 10:40:43
10:40:55.131 -> 04/18/2019 10:40:43
10:40:55.231 -> 04/18/2019 10:40:43
10:40:55.332 -> 04/18/2019 10:40:43
10:40:55.394 -> 04/18/2019 10:40:43
10:40:55.534 -> 04/18/2019 10:40:43
10:40:55.633 -> 00/00/2000 00:00:00
10:40:55.633 -> RTC lost confidence in the DateTime!
10:40:55.734 -> 00/00/2000 00:00:00
10:40:55.734 -> RTC lost confidence in the DateTime!
10:40:55.834 -> 00/00/2000 00:00:00
10:40:55.834 -> RTC lost confidence in the DateTime!
10:40:55.935 -> 00/00/2000 00:00:00
10:40:55.935 -> RTC lost confidence in the DateTime!
10:40:56.035 -> 00/00/2000 00:00:00
10:40:56.035 -> RTC lost confidence in the DateTime!
10:40:56.136 -> 00/00/2000 00:00:00
10:40:56.136 -> RTC lost confidence in the DateTime!
10:40:56.236 -> 00/00/2000 00:00:00
10:40:56.283 -> RTC lost confidence in the DateTime!
10:40:56.337 -> 00/00/2000 00:00:00
10:40:56.384 -> RTC lost confidence in the DateTime!
10:40:56.437 -> 00/00/2000 00:00:00
10:40:56.437 -> RTC lost confidence in the DateTime!
10:40:56.537 -> 00/00/2000 00:00:00
10:40:56.584 -> RTC lost confidence in the DateTime!
10:40:56.639 -> 04/18/2019 10:40:45
10:40:56.723 -> 04/18/2019 10:40:45
10:40:56.854 -> 04/18/2019 10:40:45
10:40:56.939 -> 04/18/2019 10:40:45
10:40:57.040 -> 04/18/2019 10:40:45
10:40:57.140 -> 04/18/2019 10:40:45
10:40:57.241 -> 04/18/2019 10:40:45
10:40:57.340 -> 04/18/2019 10:40:45
10:40:57.441 -> 04/18/2019 10:40:45
10:40:57.541 -> 04/18/2019 10:40:45
10:40:57.641 -> 00/00/2000 00:00:00
10:40:57.688 -> RTC lost confidence in the DateTime!
10:40:57.788 -> 00/00/2000 00:00:00
10:40:57.788 -> RTC lost confidence in the DateTime!
10:40:57.842 -> 00/00/2000 00:00:00
10:40:57.888 -> RTC lost confidence in the DateTime!
10:40:57.942 -> 00/00/2000 00:00:00
10:40:57.989 -> RTC lost confidence in the DateTime!
10:40:58.089 -> 00/00/2000 00:00:00
10:40:58.089 -> RTC lost confidence in the DateTime!
10:40:58.190 -> 00/00/2000 00:00:00
10:40:58.190 -> RTC lost confidence in the DateTime!
10:40:58.243 -> 00/00/2000 00:00:00
10:40:58.290 -> RTC lost confidence in the DateTime!
10:40:58.375 -> 00/00/2000 00:00:00
10:40:58.375 -> RTC lost confidence in the DateTime!
10:40:58.476 -> 00/00/2000 00:00:00
10:40:58.523 -> RTC lost confidence in the DateTime!
10:40:58.565 -> 04/18/2019 10:40:47
10:40:58.697 -> 04/18/2019 10:40:47
10:40:58.797 -> 04/18/2019 10:40:47
10:40:58.897 -> 04/18/2019 10:40:47
10:40:58.998 -> 04/18/2019 10:40:47
10:40:59.098 -> 04/18/2019 10:40:47
10:40:59.199 -> 04/18/2019 10:40:47
10:40:59.299 -> 04/18/2019 10:40:47
10:40:59.400 -> 04/18/2019 10:40:47
10:40:59.500 -> 04/18/2019 10:40:47
koosiekloek
@koosiekloek
have a look here might help you Lib
msparks/arduino-ds1302@5650f7d
Michael Miller
@Makuna
More than likely there is a communications problem of some sort.
I looked at their code, I have the delays already. I am following the specification of the part. The only weird thing they do is that the transition from write to read, they set the pin to input BEFORE the clock drops.
I am away from my hardware so I can't test this.
Try the ThreeWireCommFix branch and see if this fixes it for you.
koosiekloek
@koosiekloek
Thanks a mill, i am also not with my hardware now but will test in the morning and report back
koosiekloek
@koosiekloek
The changes you made fixed my problem thanks a million for the help and time spent! So much appreciated!
0.3Sec Delay
09:15:47.540 -> compiled: Apr 19 201909:15:35
09:15:47.573 -> 04/19/2019 09:15:35
09:15:47.573 -> RTC is the same as compile time! (not expected but all is fine)
09:15:47.640 -> 04/19/2019 09:15:35
09:15:47.908 -> 04/19/2019 09:15:35
09:15:48.212 -> 04/19/2019 09:15:36
09:15:48.517 -> 04/19/2019 09:15:36
09:15:48.822 -> 04/19/2019 09:15:36
09:15:49.129 -> 04/19/2019 09:15:37
09:15:49.437 -> 04/19/2019 09:15:37
09:15:49.742 -> 04/19/2019 09:15:37
09:15:50.017 -> 04/19/2019 09:15:38
09:15:50.325 -> 04/19/2019 09:15:38
09:15:50.634 -> 04/19/2019 09:15:38
09:15:50.942 -> 04/19/2019 09:15:38
09:15:51.219 -> 04/19/2019 09:15:39
09:15:51.528 -> 04/19/2019 09:15:39
09:15:51.831 -> 04/19/2019 09:15:39
09:15:52.136 -> 04/19/2019 09:15:40
Michael Miller
@Makuna
Great, I will merge that in and put out a new release
koosiekloek
@koosiekloek
:D
Leandro Boari
@leandrorepos
Hi!
Does the DS3231 alarm work when the clock is in backup mode?
Leandro Boari
@leandrorepos
I can't make the RTC send a pulse through the SQW:-(
Michael Miller
@Makuna
Did you set it, call myRtc.SetSquareWavePin(DS3231SquareWavePin_ModeClock) and myRtc.SetSquareWavePinClockFrequency(DS3231SquareWaveClock_1Hz) for once a second.
What do you mean by "backup mode"?
Leandro Boari
@leandrorepos
I'm sorry! "Backup mode": When I do not supply 3.3V on the VCC of the RTC, but it is supplied by the RTC battery. Will send pulses too?
Leandro Boari
@leandrorepos
What I would like to do, is the DS3231 give an pulse to a Flipflop Latch SR to switch the CHPD from the ESP8266 high to low. But the DS3231 is a pulse in low, right?
Michael Miller
@Makuna
To trigger the int/sqw pin when vcc is below backup power, you call myRtc.SetSquareWavePin(DS3231SquareWavePin_ModeBatteryBackup).
And yes, the docs state active low for the int pin.
I have no idea if the alarms still work when vcc is below backup power, but I would suspect so.
Leandro Boari
@leandrorepos
DS3231SquareWavePin_ModeBatteryBackup - the pin will trigger when the external power is lower than the battery power
I believe it is not possible. :-(
I'm making tests...
Michael Miller
@Makuna
The docs don't mention if the alarms work or shouldn't work if on backup battery power.
The docs do state that the int pin should have an external pullup resistor on it, with most Arduinos, just set the pin mode to pullup should work fine.
Leandro Boari
@leandrorepos
OK! I'll try and return news here.
Thank you very much, @Makuna. You are too kind!