Troubles with creating an accurate Stopwatch

Hi all,

Appreciate any advice on resolving my issue detailed below. I am working on moving a tkinter based python GUI into anvil. The application is essentially a stopwatch that increments every 0.1 seconds (I am currently using the Timer component in anvil to do this). Also within each tick increment, temperature and pressure readings are pulled from a Raspberry Pi set up as a server through uplink.

In order to maintain accurate time in tkinter, my approach was to wait each tick of the stopwatch based on the desired interval less the processing time, which resulted in a mostly accurate stopwatch (i.e. for a stopwatch incrementing every 0.1 second the wait time before incrementing was 0.1 - processing time). As I mentioned earlier, I am using the Timer ability in Anvil to manage the tick rate of the stopwatch in the function below:

Where counter is the value of the stopwatch and counterInterval is 0.1,

def timerCounter_Tick(self, **event_args):
global counter, counterInterval

counter = float("{:.1f}".format(counter + counterInterval))
self.labelCounter.text = "{:.1f}".format(counter)

Now that the stopwatch is mostly accurate, I added a server call to return the value of Temperature and Pressure as measured on the Raspberry Pi. The new timer function is below:

Where the getValues() function returns an array [Value of Temperature, Value of Pressure],

def timerCounter_Tick(self, **event_args):
global counter, counterInterval

counter = float("{:.1f}".format(counter + counterInterval))
self.labelCounter.text = "{:.1f}".format(counter)
  
sValueLst = anvil.server.call_s('getValues')
self.valueTemperature.text = sValueLst[0]
self.valuePressure.text = sValueLst[1]

Now this is where I ran into issues running the app… The stopwatch, given the additional tasks and server calls, now increments much slower than every 0.1 seconds, losing accuracy. I am curious how I can account for both processing time and network response time within each tick of the Timer component to maintain an accurate 0.1 second increment? Has anyone built an accurate stopwatch in anvil? If I ping www.anvil.app I get a response time of about 95 ms… Does this mean an accurate 0.1 stopwatch would be almost entirely infeasible?

The timing of the stopwatch does not need to be exact. I would accept if the stopwatch lost no more than a second over a 30 second period of time.

I am very new to this and am curious if my issue is my approach or if the application is just unrealistic.

If you are curious to look at the whole app, here it is:
https://anvil.works/build#clone:TY2ZDLBENJQJKDQ5=DL7L2CEA6XJGRIRNSHGX6Y4F

To reproduce the error, hit Run then select the green Play button to begin the stopwatch (not sure though if because I am using an uplink server if the app will run for other users).

Welcome to the Anvil Forum, @tome18.

Perhaps there’s a simple way to sidestep the issue. Can the Pi timestamp its readings?

Hi @p.colbert,

Yeah this occurred to me yesterday as well where the raspberry pi could record the temperature every 0.1 seconds but the webpage would only request the readings every 1 second. Let me know if you had a different approach in mind though…

The reason for reporting at a higher rate is so that the user can make changes to the system. I will add this context into the original post but this app reports temps and pressure from an espresso machine. So ideally while brewing, the app would provide feedback quickly to the user so he could vary the pressure and see the resulting pressure value in real time in the app.

Hi, @tome18.

I had two reasons for having the timestamps come from the Pi instead of the client.

  1. You could still collect measurements at 10Hz. Even if you had to poll every 0.2 or even 0.5 seconds, you could still get (and plot?) the data according to its “natural” rate.
  2. The timestamp would be guaranteed to accurately reflect the time that the measure was taken. Not affected by network transmission variables. So the reporting would be more accurate.

Human perception + reaction time is roughly 1 second. Internet and processing lag adds to that, by a not-always-consistent amount. Reporting at a higher rate won’t improve those figures. But it may help the user spot patterns of rapid changes.

Hi @tome18,

I got the same issue a few weeks ago. In my case, it seems that client UI stop updating, or any code below server call don’t run until server call is completed. It takes about 0.3s even the there is no code in the server.

Hi all, happy holidays and thank you for the replies! @p.colbert I see what you are saying, will play around with that idea.
@Tony.Nguyen I think I ran into that briefly as well.
I think for my intentions this may not be the best format, although I am glad to have dived in. Many more considerations in a web interface than I originally anticipated. Also, practically there isn’t much need for someone to be able to brew their espresso over wifi haha