Slower Previous Performance is Faster!

[Mighty Malc]

I love the feature where I can race a previous performance on a course, and see the position of the previous go displayed relative to me.
It makes for great training as I strive to beat the previous go. Wonderful, thank you.

However, on several occasions my previous performance producing less average power has beaten me.
I was a bit suspicious, and frustrated, but decided higher average power does not necessarily mean faster overall.
I could not actually prove the software was wrong so I just accepted it.
But after it happened a few times I started to wonder.

However today I proved that indeed there is something wrong. A slower performance (both in Watts and more importantly, finishing time) beat me!!!!!!
I rode the Col de Rates stopping as quickly as possible and exiting at the end of the blue segment = 22.63miles at average of 197W taking 1:33:59.
I raced against a previous performance that stopped at 'the same point' (22.62 miles recorded) at average of 190W taking 1:34:30.

Despite my previous performance producing less average power and supposedly finishing about 31 seconds behind me, I was still chasing it at the end and it finished over a minute before me. Can't be right.
The blue triangle for the previous performance was in front, just off the local segment display (200m granularity, so at least 1 km in front) when it disappeared meaning the previous performance had completed the blue segment.
[With the final downhill stretch being done at roughly 30 mph (from the graph) then finishing over 1km in front calculates to finishing at least 1 min 15 seconds before me - my subjective estimate of finishing over a minute before me is correct.]

Looking at the graphs for the rides I see the end times for both rides were both roughly 12 seconds after stopping pedalling at the end of the blue segment.
So they finished nearly identically. Nothing to explain the anomaly there.

Looking at the graphs for the rides I see they both got to the start of the blue segment (100m after course start) within 1 second of each other.
So they started nearly identically. Nothing to explain the anomaly there.

Please can you investigate why this happens, something is wrong.

Since the general feel of the display of a past performance is correct, hopefully there can't be many things to look at that would explain this erroneous behaviour.
A couple of suggestions:
1. Can you check you are updating the display of a past performance position using distance and not based on some assumed speed.(Errors build up if you estimate position from speed, rather than using known position from a file).
2. Since the display is for a segment, can you check all segment positions are correctly measured relative to the start of the segment and not as absolute positions on the course. Both when archiving segment performance and when using them on the display.

Hope this is not too hard to track down.

[admin]

1) I am updating display based on position, not on speed. However as position is taken at some fixed time intervals (1 sec i think but will have do double check) speed is temporarily used to fill in positions in between. It is even bit more complex but you get the idea.
2) Positional calculations are correct (relative to segment)
3) I just ran 3 times live simulation over first red segment (10 km) of 0025_Lago-dIseo video feeding software with precisely the same and steady 316 watt signal each time. Below you can see screenshot (at the scale of left profile set to 100 m). While there are some tiny imperfections the end result is less then 1sec difference (btw there are 2 squares representing previous performances, they're just too close).



I am not sure what causes such discrepancy in your case. Big enough amounts of lost ANT packets (I assume you are using ANT+ trainer) however can do things like that. I will improve code a bit in this area but it can not be made absolutely perfect.

In order to see if that is thew reason you can run simulation yourself. First move your existing segment performances to some safe place (performances are located under ...\data\users\your vride id\segperf folder and use "test mode" button to run simulation over whatever ride you want. Then reset the ride and do the same again. This time you can watch how your performance behaves. Let me know how it goes.

For what it worth I use Lynx trainer (it is wired, no signal loss) and I do not experience situations like yours.

[Mighty Malc]

I should have said, I am using a wired computrainer so Ant+ has no bearing on the problem.

Today was the 1st time I had clear evidence to prove there was a problem. The previous performance finished at least 1 min before me rather than 31 sec after giving a total error of at least 1 min 31 which is significant.
But I already suspected previous slower goes were playing back a little too fast. But over my 10 km flat segments taking say 20 min it was less noticeable than over a 1 hour 33 minute segment.
So I don't think my case today is just an isolated incident, and I suspect a general problem which it would be great to sort.

Iago Diseo is pretty flat (Col de Rates is not), 10 km is quite short and 316W is a lot more than my 197W.
It might be worth repeating using Col de Rates at 190W, and over the whole blue segment.

Even better, is it any use me giving you my original Col de Rates performance file, and segment data, for you to use those against say a fixed 197W simulation and see if my previous performance from segment data is replayed to finish so that it matches the performance file finish time?

[admin]

I will do the following. I have ANT FE-C bridge that among the other things can simulate cyclist pedaling at such and such power. So the software would be working under completely normal conditions as if it had real ANT+ trainer sending power, only steady one. And I will run exactly the same course with the same/close enough power. We will see what happens. This will obviously take some time so be patient. I am placing Transmitting and Receiving sticks right next to each other so would not worry about signal loss.

I do not think I want to look at your data at this point but do save your tcx files and corresponding segment performance files somewhere safe just in case.

[admin]

Ok I did the test. Basically run software from the real ANT stick transmitting at steady 198 watts

you can get the original data tcx and segment performances from here:
http://veloreality.com/exs_v_dump/forum/0061_segper.zip

At the end of the post are few screenshots illustrating the end results (basically the difference between positions is well within 10 meters. I also did extra test (placing ANT stick far away). There was some signal loss and as a result the ride became a bit slower (however due to it being obvious I did not run it to the end and did not create screenshots)

So basically all works as expected on my end. If you really want to investigate the matter you have to run some tests on your end. Computrainer is wired but some data could still get lost on that interface or maybe you have some genie living in your PC/laptop.

1-st ride obviously no pics
2-nd ride somewhere in the middle area of the ride

2-nd ride close to the end of the ride

3-rd ride somewhere in the middle area of the ride

3-rd ride close to the end of the ride

[Mighty Malc]

Thanks for the investigation - your talk of losing data gave me an idea...

I had front chain ring gear change problems over several weeks with the chain coming off when I changed too aggressively.

I looked at the graph of the performance file (.tcx) for the previous ride that completed the blue segment too quickly when raced against.
The performance file graph actually has 2 regions where it looks like the chain came off - costing an estimated 20 seconds or so each time to get off and replace the chain.
I imagine the software deemed me to have paused (like when you stop as you finish a ride).

The .tcx file records the pause - hence it shows up on the graphs and counts towards the total time to complete the ride = the time I am expecting to see when racing against this previous performance over the segment.
However, I am wondering if the segment performance file does not record the paused time but only the moving time? [Or playing it back somehow skips the pause.]
This could happen if e.g. position is recorded every second but only while moving (not deemed paused).
Then when racing against the previous performance, the paused time is skipped meaning the played back (moving) time for the segment used is shorter than the elapsed time I am expecting to see.

If the above hypothesis is correct it helps to explain the issue I saw. Still not exactly right because 2 x about 20 seconds does not account for a 90 second discrepancy, but who knows how long the software deems the bike to be paused.
Although there is also a case for saying if you pause on a segment, then like in the .tcx file, it should be recorded in the segment performance file; because it is a limiting case of going very very slowly which is recorded.

Are you able to confirm my hypothesis that pausing during a segment is ignored in segment performance recording/playback?
Thanks.

If that is the case I am moderately happy - the conclusion is not to get hung up over odd behaviour racing against segments where you paused or let the chain come off.

[admin]

Dead time (when you stopped) is skipped and is not included in segment performances.

[Mighty Malc]

That's great to know.

I consider the issue I raised to be understandable now.
Maybe the discrepancy is a bit more than I would expect, but there is no future in pursuing it with the case I raised.

So I consider the issue closed and am very appreciative of all the work you put in that helped to narrow the problem down.
Thank you again.

[polar_ninja]

How can I switch off the previous performances on the screen?

[admin]

How can I switch off the previous performances on the screen?

Section 9 of the User's guide: http://www.veloreality.com/exs_v_ride/v ... l_v1.0.pdf explains how to control live ride data display including turning on/off display of previous performances. Specifically numerical key - "3" toggles this particular display.