A "pile" for me would be 1-2 updates per second. I learned very quickly that ANT+ devices don't like it when you send requests (calibration requests, erg adjustments, sim-mode adjustments) before they've acknowledged the previous one. The kickr (not to pick on it, it's the only sim-mode device I've got) would frequently stick to a single sim-mode slope setting in my first implementation because I was just hammering it at 4-5hz without waiting for acknowledgement packets.
Writing custom ANT+ code is an big pain. It seems like it shouldn't have to be (it's little 8 byte packets getting sent and received), but their API is just kinda weird. That said, it is possible that ANT+'s SDK has improved since TdG was under heavy development. As a part-time dev, I never had the time to write a nice wrapper I was happy with.
I wonder if Wahoo's phone driver just sticks your calls in a FIFO queue and unloads it at whatever the update rate is. It'd be fun to queue up 1000 calls that set up a sine wave (peak every 100 calls) in erg mode or something and see how long it takes in the real world for the device's resistance to go from peak to peak.
STAC Zero Trainer - Zero noise, zero tire contact, zero moving parts. Suffer in Silence starting fall 2016
Writing custom ANT+ code is an big pain. It seems like it shouldn't have to be (it's little 8 byte packets getting sent and received), but their API is just kinda weird. That said, it is possible that ANT+'s SDK has improved since TdG was under heavy development. As a part-time dev, I never had the time to write a nice wrapper I was happy with.
I wonder if Wahoo's phone driver just sticks your calls in a FIFO queue and unloads it at whatever the update rate is. It'd be fun to queue up 1000 calls that set up a sine wave (peak every 100 calls) in erg mode or something and see how long it takes in the real world for the device's resistance to go from peak to peak.
STAC Zero Trainer - Zero noise, zero tire contact, zero moving parts. Suffer in Silence starting fall 2016