Steve
Senior Member
- Location
- London and Manila
and Bill S to 9th, good going!Wow, just went from 162 to 21 overall. What the <beep> happened? :-)
Last edited:
and Bill S to 9th, good going!Wow, just went from 162 to 21 overall. What the <beep> happened? :-)
Just a little general Bkool info:
Apparently the danish Nation Cup team manager has some insider knowledge. He explains that the event will be live-streamed because the Bkool system begins to struggle at arround 60 participants, and that spectators use up the same amount of resources as a rider.
I'm on Win 7 32bit (max 4 GB RAM), so I'll probably stick to the less crowded chaingang league (Cyclechaters) until I decide to build myself a new PC.That's NOT insider knowledge but common knowledge for all of us riding the weekly Danish Bkool Usergroup Facebook races. We HAVE to divide the race into 2 separate sessions, as we usually are more than 100 riders. 50 riders in one session is usually OK with only a small amount of stuttering here and there. But past 60, things start to go bonkers.
Before we split up the races, having 100 riders in one session, it was almost unplayable. That amount of riders taxes both the internet connection, the Bkool servers and last but not least riders (underpowered) computers.
At least 8GB of RAM is recommended, and the people trying to get by with only 4 GB, WILL suffer at some point!
I'm on Win 7 32bit (max 4 GB RAM), so I'll probably stick to the less crowded chaingang league (Cyclechaters) until I decide to build myself a new PC.
Have you tried a combination of map view and 3D? It seems to me that in map view the ammount of ressources needed to draw dots should be limited.
As the race progresses one could switch to 3D when only a limited number of riders are nearby.
Of course, this would only work if Bkool is smart enough to only draw riders nearby.
32-bit actually gives you only about 3.5 GB usable memory. If using integrated graphics, you may have less.
Riding a race in map view only is way too boring. 99.99% of the time I use the 3D view in these races, as it is nice to visually see your opponents. The dots in map/2D view only, and the symbols in video view is not that usable, and doesn't give (me) the same feeling of being part of a real race.
Of course the 3D view only draws riders nearby, I think the Unity 3D engine takes care of that. But to draw the dots at the bottom, and the ranking on the left, your computer has to know other riders position more or less all the time.
Brusgaard when we're not blaming our own failing bodies or long work days for our poor performances, we like to blame bkool's numerous little problems. Do you spend much time in the Danish league talking about the 'dead-stop' issue and other bkool problems?
I'm not sure, this is what you mean by 'dead-stop', but what happens with many riders (at least in 3D mode) is that the simulator stops for 5-10 seconds, and you are stuck at whatever climb percentage you were on at the time.
Take a look at this video about 20 seconds in.
https://www.dropbox.com/s/w6sz68u9kz3g856/Bkool Indoor 16_02_17 19_11_19.mp4?dl=0
It seems to affect all cyclechaters, and can result in a huge disadvantage. E.g. I watch EDU in that video, in a matter of a few seconds, go from behind Bill to being 30 seconds ahead on one of those deadstops.
And new shifters, rear mech and chain to work it.Hmmm... 11-34..![]()
OK, that is not entirely the same thing, I think. In our case the simulator literally stops, as in no update of graphics, speed, heartrate etc. Your problem seems related to the signal going to the trainer being a bit too late compared to the route changes, and it responds with an abrupt change in resistance instead of a subtle one. I guess the same thing happens when going from a steep climb to downhill?
Just a few quick comments regarding power from a bkool trainer.
SInce the bkool pro transmits a power figure over ANT+ FE-C regardless of any software running externally but does not have a power meter this transmitted power figure must be being worked out in the firmware alone.
If the trainer is unplugged, I don't see how it can transmit anything, as I don't believe it has any kind of alternator/generator to generate electricity from the roller movement. Any lingering power/speed figure most likely comes from the external software and any external sensors in use. The bkool software will produce power and speed figures even if you have no trainer and no sensors paired!
(Rotating) Power calculations only need torque and rpm, so input variables to the required resistance are not needed, just the resistance/torque. The input variables (e.g. weight, drag, etc.) are only needed by the external software to then request a desired level of resistance from the trainer, to simulate a course.
The bkool pro has no means of measuring this resistance so it can only be estimated, therefore the power calculation is not really a calculation, just an estimate multiplied by rpm.
As is obvious from observation and experience, this estimate is not very accurate at all, varying from reasonable to wildly out.
As AAAC states, all that really matters is average speed! However, if one rider experiences different resistance to another, all input variables being the same, they are not really riding the same course and comparisons of speed are therefore difficult. The unknown and unknowable variations in actual resistance from presumed resistance mean all other calculations and possible adjustments have limited accuracy.
One way to calibrate resistance, and therefore make the resistance applied closer to the actual required resistance, is to use a calibrated power meter, which tends to be accurate to within just a percent or two. As someone stated a few posts ago, if the estimated power (torque/rpm) doesn't match the metered power the software can request more or less resistance (torque) until it does match. Done smoothly enough, this would ensure that the applied resistance is always close to that required to match the simulated conditions. Of course, some power meters work at the pedal, some at the crank, some at the hub, so small differences would still exist, but limited to perhaps around 3%-5%.
Even if the bkool software allowed an external power meter to be used to correct the power figure, it would also have to use it to adjust the resistance of the trainer to ensure the simulation was accurate and the speed matched. Just displaying the correct power would be of limited benefit. Just using the measured power to calculate the speed, ignoring the tyre/roller speed would be an improvement, but would still leave the resistance incorrect.
If this adjustment of resistance to match external measured power was made, it would only level the playing field for the minority that had external or built in power meters. The vast majority of bkool users on bkool trainers without a power meter would still have estimated resistance, and therefore be riding under different conditions.
In reality, any trainer where actual resistance can vary widely from requested resistance, and where this is not measured and adjusted, can only roughly simulate conditions (limited to it's maximum actual resistance). Applied resistance curves can help only if tolerances are tight and individual trainers do not vary much from the curve for that model.
The simulation is generally good enough to train on and to measure improvements from baselines, and when riding with others, for "fun" where there is informal competition to improve motivation. However, for serious competition, to match closely real world ability, calibrated trainers and software would be needed to give any kind of validity to the competition. So best to treat it as a bit of fun and motivation to train, and enter real world competitions if you want accuracy!
When it comes to the software calculating the required resistance to correctly simulate the course, conditions and performance of the rider, this is MUCH more complicated than the power estimates, has multiple input variables beyond just the weight of the rider, gradient, resistance and drag, as momentum has to be taken into account. It would not be realistic if acceleration at the start of a gradient was instantaneous, and this is where bkool seem to have the most problems.
However complicated this algorithm may be, it should be possible to produce a reasonable simulation of reality and refine it over time to iron out problems. Unlike the resistance issues above, this algorithm can be "realistic" and "fair" between riders and trainers without being entirely accurate to real life. The problems that really stand out are the sudden changes in speed, and the variation in these changes between trainer models and between trainers of the same model, perhaps with different firmware or less accurate resistance.
Where unrealistic results are produced, perhaps due to communication problems or trainer faults (loose magnets, sticky motors, etc.) then it should be possible to identify these from the power/speed curves and remove them from stats/classifications. This is why Zwift and Strava, etc. have a system of flagging rides. One of bkool's biggest faults is their continued inability to flag and delete rides.
Zwift do make life easy for themselves by having VERY limited numbers of courses, and this is one of Bkool's biggest strengths, the variety of courses available to ride. In fact, I think most of us would be happier if they removed huge numbers of duplicate and unpopular courses, or just provided a number of "validated" courses which have been checked for glitches, sudden changes in gradient or errors. A couple of hundred courses would provide variety, tens of thousands are just confusing and lower the overall quality.
However, it is a great feature to have "private" courses, rides that we know, and personally I would not like to lose this facility.
Geoff