Incorrect Speed Prediction

[raser1]

Hi Fred,

I have been hunting down a bug when playing scripts with the Launch. The problem occurs when you have a fast movement followed by a slower one. The slow movement will instead play at the same speed as the action before it. I have attached a script which clearly shows the problem:

ScriptPlayer_speed_bug.zip

I have tracked it down to it probably being a bug in the Launch firmware. It will only do this when you send a new action to it when the previous one has not finished yet.

It seems that ScriptPlayer is returning speed predictions which are too low. (at least on my device) I solved it by changing the PredictSpeed method in the SpeedPredictor.cs class. When I do a quick and dirty check by multiplying the speed by 1.3x, then it works fine again:

byte actualSpeed = ClampValue(requiredSpeed * 99.0 * 1.3);

[FredTungsten]

Hi Raser,

I can confirm that this is a firmware bug, and it's been bugging me since the Launch was released. I've been waiting for a fix with every update but by now I think that will never happen. Unfortunately there is nothing that can be done in software that works in all cases, which is why I've added the beat conversion mode "Up / Down (fast)" a while ago. It emulates this specific bug by always using the higher speed of two adjacent commands to make sure this happens every time. Not a perfect solution but at least it's consistent. This of course only works for beat based scripts and not funscripts.

Multiplying the speed by 1.3 would certainly work for some cases, but only if it's still slow enough (< 80). For really fast movement (99 native) there is no way to prevent that without reducing the range.

[raser1]

Thanks for your quick response. It's a shame that they left such a big flaw in their device.

I did some further investigation and so far it works fine as long as the next command comes right after the last one has finished. It also seems that the speed isn't linear. Considering that, I think the reason it fails at higher speeds is because the script doesn't give it enough time to finish the move completely. In the current speed prediction a value of 75+ maybe should have been 99 instead.

I've tried to create a non-linear equation and have some good results so far. I think a LUT could work well in this case too. I'll create a test setup to measure how long it takes for a stroke to finish for different speeds. Hopefully plotting a graph of this data will show what's going on.

[FredTungsten]

So .... about that LUT.
Is that available somewhere? 😄