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

    time.sleep() not accurate

    Scheduled Pinned Locked Moved Issues & Bugs
    timetime of arrivalloralopyutime
    6 Posts 3 Posters 543 Views 3 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.
    • S Offline
      snehasg96
      last edited by

      hello,
      I am transmitting around 24 packets in an interval of 5 seconds. For about first 15-20 packets this pattern looks right to me. However at the 20th packet it looks like it takes much longer than 5 seconds (time.sleep(5)).

      What could be the issue? Any idea as to how to fix this ?

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

        @snehasg96 how much longer is “much longer”? How are you sending the packets? What are your settings? Have you measured the time.sleep itself?

        S 1 Reply Last reply Reply Quote 1
        • S Offline
          snehasg96 @jcaron
          last edited by snehasg96

          @jcaron I followed the example in the documentation which initializes the mode and the raw socket. Then within a while loop from the transmitter side, i send ```
          Insert Code Here

           s.setblocking(True)
              if utime.time() > timeout:
                  break
              else:
                  pass
              s.send(uos.urandom(5))
               time.sleep(5)
          
          
          

          This is my receiver code.

          while True:
              if utime.time() > timeout:
                  break
              else:
                  pass
              s.setblocking(True)
              data = s.recv(5)
              time.sleep(5)
          
          
          my timeout = utime.time() + 2 minutes. I think it is important for both the lopy boards' codes to have the time mentioned so i have included in both my codes. However when i click reset the code works fine to transmit 24 packets within 2 minutes. But while in real time, it takes more than 2 minutes.
          C 1 Reply Last reply Reply Quote 0
          • C Offline
            crumble @snehasg96
            last edited by

            @snehasg96

            don't use sleep in the receiver.

            Both clocks do not run synchronized and the code in sender and receiver has not the same timing. After a few iterations you will send a message while your receiver sleeps.

            S 1 Reply Last reply Reply Quote 0
            • S Offline
              snehasg96 @crumble
              last edited by

              @crumble thank you so much ? I will try this and let you know. But like you said this should have caused the weird pattern.

              1 Reply Last reply Reply Quote 0
              • S Offline
                snehasg96
                last edited by

                @crumble also, is it fine to use the utime.time() in the receiver as well or just use it in the sender? Also i tried running the code after removing time.sleep() in the receiver but for some reason i still experience the same issue.

                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