Welcome to the Pycom forum Forum
    • \[\[global:header.categories\]\]
    • \[\[global:header.recent\]\]
    • \[\[global:header.tags\]\]
    • \[\[global:header.popular\]\]
    • Login

    Explore Pybytes | Official Documentation | Report a Firmware Bug/Issue | GitHub

    rtc.ntp_sync

    Scheduled Pinned Locked Moved GPy
    rtcgpy
    5 Posts 2 Posters 455 Views 2 Watching
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • K Offline
      kjm
      last edited by

      I've got this weird effect on the gpy whereby rtc.ntp_sync('time.google.com') is rock solid on 4G but ratty over wifi with 5-10min chunks of time where it just won't work. I haven't had much experience with rtc syncing, anything that connects to a server without a socket is black magic to me. Given that 4G via the sequans & wifi via my router are more or less equivalent connections reliability wise, can anyone offer a clue as to why the difference?

      J 1 Reply Last reply Reply Quote 0
      • J Offline
        jcaron @kjm
        last edited by

        @kjm Quite a few people seem to have intermittent WiFi connectivity issues, not sure if they are all related.

        Could you clarify you scenario? Is your GPy constantly awake or are you using deep sleep? What exactly do you do and how do you know when it's not working (sources + logs and/or graphs would be useful).

        Any logs are always appreciated, the more detailed the better.

        K 1 Reply Last reply Reply Quote 0
        • K Offline
          kjm @jcaron
          last edited by

          @jcaron The GPY sleeps for 10 mins then wakes up, trys to set the rtc, reads some sensors & uploads the results to the server over 4G. It all works nicely. But when testing I use wifi for connectivity rather than 4G mainly because I can get a wifi connection to my router quicker than the 4G attach/connect waltz. And, in doing this, I've noticed the rtc often comes up on the default 1970 time.

          If you REALLY think it would help I could write some code to graph the RTC failures.

          J 1 Reply Last reply Reply Quote 0
          • J Offline
            jcaron @kjm
            last edited by

            @kjm you get the wrong date, but still get your own request through all the time?

            You could check if the time is correct after the ntp_sync call and retry if it’s not the case.

            Are you using a local NTP server of a remote one?

            If you are sending the data to a server each time you wake up anyway, you possibly don’t even need the NTP sync: just have the server time stamp the data when it receives it (though I guess it depends on your exact application and the accuracy you need).

            K 1 Reply Last reply Reply Quote 0
            • K Offline
              kjm @jcaron
              last edited by

              @jcaron No the rtc.ntp_sync fails to connect to time.google.com a lot on wifi & the default 1970 timestamp is what the rtc defaults to when it's not synced. I have to resync the rtc after each wakeup on the gpy because it doesn't keep time during deepsleep.

              1 Reply Last reply Reply Quote 0

              Hello! It looks like you're interested in this conversation, but you don't have an account yet.

              Getting fed up of having to scroll through the same posts each visit? When you register for an account, you'll always come back to exactly where you were before, and choose to be notified of new replies (either via email, or push notification). You'll also be able to save bookmarks and upvote posts to show your appreciation to other community members.

              With your input, this post could be even better 💗

              Register Login
              • 1 / 1
              • First post
                Last post

              Pycom on Twitter

              Pycom