time.sleep() not accurate
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.
crumble last edited by
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.
snehasg96 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.
jcaron last edited by
@snehasg96 how much longer is “much longer”? How are you sending the packets? What are your settings? Have you measured the