Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Timing question #14

Open
ncaccamo opened this issue Aug 18, 2021 · 4 comments
Open

Timing question #14

ncaccamo opened this issue Aug 18, 2021 · 4 comments

Comments

@ncaccamo
Copy link

Looking at touche.h, line 65 (as of Jun 13th commit), the double touch time is set to 300ms. Above in the comments, it is explained that there is ~260ms of processing time when both tips are pressed. For clarification, does this mean that the system cannot meet the rules timing requirements to distinguish between a single touch or double touch due to processing/communication delays?

I am also wondering what are good methods to measure these timings across the whole system given the various factors?

@Yohannfra
Copy link
Owner

Yes, the rule says that a double hit must be made within 50ms but the minimum timing I got when pressing the two buttons at the exact same time was 260ms, so by setting 300ms I give a little more tolerance to this timing and it works better.
From what I tested the difference is almost not noticeable.

I don't have any 'good' method to test the timings, I just press the two buttons at the exact same time and read the millis() difference of the two when the server receive it

@Riposte63
Copy link

Riposte63 commented Sep 19, 2021

Hi, There is also the question of how long the tip is depressed before a hit will register (I think 17ms for foil?) - I found in the client where it appears to be hard-coded to 2ms - is that correct - maybe I'm looking in the wrong place?

@Yohannfra
Copy link
Owner

You can look at client/lib/Weapon/src/Weapon.cpp and client/src/main.cpp

If the tip is pressed the hit will register instantly. where did you find 2ms ?
Actually It should wait a few ms but it was causing some latency so I removed it for now until I find a solution.

@Riposte63
Copy link

It was me looking in the wrong place regarding the 2ms - sorry ;-)
In terms of a solution - just an idea - would it help if the server's only function was to manage the virtual ground for the piste and any other communication was directly between the clients and with LEDs clipped to inside of mask?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants