Sorry that I'm late to the party here. In order to calculate the
elapsed time you can just subtract the lower 4 bytes.
So if Start% is the lower four bytes of the start time & Finish% is
the lower four bytes of the finish time:
TimeTaken% = Finish% - Start%
This "Just works" and will always produce the correct result even
with rollovers.
If TimeTaken% < 0 then the finish was before the start.
On 22 Apr in article
<69d8792f-18c1-4a2c-8e14-0a7e0fd698c7@googlegroups.com>,
<jeffrey.a.doggett@gmail.com> wrote:
Sorry that I'm late to the party here. In order to calculate the
elapsed time you can just subtract the lower 4 bytes.
So if Start% is the lower four bytes of the start time & Finish% is
the lower four bytes of the finish time:
TimeTaken% = Finish% - Start%
This "Just works" and will always produce the correct result even
with rollovers.
If TimeTaken% < 0 then the finish was before the start.
I don't think this works if the time difference is over 35 weeks....
--
Martin Avison
Note that unfortunately this email address will become invalid
without notice if (when) any spam is received.
Indeed. But what happens when the 5-byte hex times are...
start time = 58 00 00 04 00
end time = 57 00 00 05 00
gives x100 ... when it should be flagged as negative and duff!
On Thursday, 23 April 2020 00:09:59 UTC+1, Martin wrote:
On 22 Apr in article <69d8792f-18c1-4a2c-8e14-0a7e0fd698c7@googlegroups.com>,
<jeffrey.a.doggett@gmail.com> wrote:
Sorry that I'm late to the party here. In order to calculate the
elapsed time you can just subtract the lower 4 bytes.
So if Start% is the lower four bytes of the start time &
Finish% is the lower four bytes of the finish time:
TimeTaken% = Finish% - Start%
This "Just works" and will always produce the correct result
even with rollovers.
If TimeTaken% < 0 then the finish was before the start.
I don't think this works if the time difference is over 35
weeks....
No, but Alan is timing a canoeist down a slalom course. If it
takes 35 weeks then there's something amiss.
Indeed. But what happens when the 5-byte hex times are...
start time = 58 00 00 04 00
end time = 57 00 00 05 00
gives x100 ... when it should be flagged as negative and duff!
On 23 Apr in article
<dccbb754-a167-43b8-ad2f-f6d82fbbd68b@googlegroups.com>,
<jeffrey.a.doggett@gmail.com> wrote:
On Thursday, 23 April 2020 00:09:59 UTC+1, Martin wrote:
On 22 Apr in article <69d8792f-18c1-4a2c-8e14-0a7e0fd698c7@googlegroups.com>,
<jeffrey.a.doggett@gmail.com> wrote:
Sorry that I'm late to the party here. In order to calculate the elapsed time you can just subtract the lower 4 bytes.
So if Start% is the lower four bytes of the start time & Finish% is
the lower four bytes of the finish time:
TimeTaken% = Finish% - Start%
This "Just works" and will always produce the correct result even
with rollovers.
If TimeTaken% < 0 then the finish was before the start.
I don't think this works if the time difference is over 35 weeks....
No, but Alan is timing a canoeist down a slalom course. If it takes 35 weeks then there's something amiss.
Indeed. But what happens when the 5-byte hex times are...
start time = 58 00 00 04 00
end time = 57 00 00 05 00 gives x100 ... when it should be flagged as negative and duff!
Indeed. But what happens when the 5-byte hex times are...
start time = 58 00 00 04 00
end time = 57 00 00 05 00
gives x100 ... when it should be flagged as negative and duff!
That would require the judge on the finish line to press his button
35 weeks before the starter presses his button. Cannot happen.
I need to reliably detect negative results, which can occur if a
spurious finish time pulse arrives before a start time.
On 23 Apr in article
<6667d647-6873-488d-8a39-ed15086e185a@googlegroups.com>,
<jeffrey.a.doggett@gmail.com> wrote:
Indeed. But what happens when the 5-byte hex times are...
start time = 58 00 00 04 00
end time = 57 00 00 05 00 gives x100 ... when it should be
flagged as negative and duff!
That would require the judge on the finish line to press his button 35 weeks before the starter presses his button. Cannot happen.
Unfortunately the OP in his first post said...
I need to reliably detect negative results, which can occur if a spurious finish time pulse arrives before a start time.
Sysop: | Keyop |
---|---|
Location: | Huddersfield, West Yorkshire, UK |
Users: | 112 |
Nodes: | 8 (1 / 7) |
Uptime: | 210:15:07 |
Calls: | 2,465 |
Files: | 8,608 |
Messages: | 1,879,528 |