time.sleep() not accurate
-
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 ?
-
@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.
-
@crumble thank you so much ? I will try this and let you know. But like you said this should have caused the weird pattern.
-
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.
-
@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 Heres.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.
-
@snehasg96 how much longer is “much longer”? How are you sending the packets? What are your settings? Have you measured the
time.sleep
itself?