Closed GoogleCodeExporter closed 9 years ago
Original comment by sandordo...@google.com
on 23 Jul 2011 at 8:56
I got bitten by the same issue. I wanted to replace my half-broken Garmin Edge
705 with a SE Xperia active. Heart rate sensor data is properly written to TCX
file, but the GSC-10 is simply ignored.
While browsing the source code, I noticed that the driver of the ANT+ SRM PC7
bridge supports cadence readings, but ignores speed readings. The speed and
odometer readings from a rear wheel sensor should be much more accurate than
from the GPS. A related feature would be auto-calibration of the wheel
circumference (when riding straight long enough).
Original comment by msmak...@gmail.com
on 2 Dec 2011 at 9:46
Just like to +1 this. Is a fix likely to be forthcoming?
Original comment by stephen....@googlemail.com
on 12 Mar 2012 at 12:48
I've implemented ANT+ speed sensor support in a private branch. It works, but
there is one problem. I can not do anything *sensible* with the collected speed
data, as all the web based visualization tools I've tried use the GPS location
data to calculate the speed. I can not even export the data as speed. So now
I'm exporting the speed data as "power", this way I can at least see how the
real speed is related to the GPS based speed...
Original comment by ezerot...@gmail.com
on 12 Mar 2012 at 1:44
You could export speed or distance data in CSV format. In TCX format distance
can be included in a track point as described at
http://developer.garmin.com/schemas/tcx/v2/xmlspy/index.html#element_Trackpoint_
Link05E0A1B0 In GPX you could define an extension. Also see Issue 756
http://code.google.com/p/mytracks/issues/detail?id=756
Original comment by kenep...@gmail.com
on 13 Mar 2012 at 3:11
I've found another extension in TCX for speed data. However that extension is
not understood by the service (strava.com) I'm currently using so it's not that
useful for me. So I need another extension or another service :-)
Original comment by ezerot...@gmail.com
on 13 Mar 2012 at 8:02
MyTourbook.sourceforge.net does visualize the speed data nicely on a map.
By the way, is the speed data from the GSC-10 ANT+Sport sensor now being saved,
or is it thrown away? In the version that I tried, the data fields show the GPS
speed instead of the wheel speed.
It also seems that the cadence data is being subjected to some averaging, which
I feel is wrong. If I rotate the crank at 70rpm and promptly stop so that the
magnet will no longer pass the sensor, the cadence display will slowly go to
40rpm and less. This averaging should be removed, for any ANT+Sport data (heart
sensor and wheel speed too). The averaging probably does make sense for GPS.
One more related thing is the wheel circumference calibration. Maybe it would
make sense to store the raw wheel rotation pulses and do the calibration later.
Garmin devices auto-calibrate the wheel size when riding on a long straight
line.
Other data that could be saved and post-processed later includes the compass
heading and barometer, thermometer and accelerometer data (when available). For
example, in areas of bad GPS signal, the compass and the wheel rotation data
could be used for extrapolating the position. Maybe the accelerometer could
come into play too. The air pressure and temperature data could be used for
computing the elevation more precisely in a post-processing step (maybe even on
overlapping tracks collected over months or years).
Original comment by msmak...@gmail.com
on 14 Mar 2012 at 7:46
The speed data is not collected at all in the official upstream MyTracks. In my
patched version I save the speed data as "power". That's okay for me, because I
do not have a power sensor anyway. Adding proper bike speed handling would have
been a bigger work, with no real benefit to me.
I do not think you really want to remove the averaging from the sensors. It's
there for a reason. Just think about it. ANT+ cadence/speed sensors sends
messages containing the following data:
[timestamp_of_the_last_counter_change_event, last_counter_value]
This data is sent ~4 times a second. So if the wheel revolves at 60rpm, then
depending on the timing you'll see 3 or 4 identical messages. Now if you
decrease the cadence somewhat, then you'll see some more identical messages.
The wheel is still not stopped, but there is no way you could know that. That's
why there must be some averaging, otherwise you would see tons of "0" cadence
values mixed into a series of "normal" values. I've tried that and it's ugly.
Currently the averaging code uses a 5 second long history, as this gives
similar values as my cycling computer. But that value could be made user
changeable.
Auto calibration sounds very interesting, but I think the GPS sampling interval
and sampling error is just too large to make this work in real life (how would
Mytracks know if you do some fast "S" turns instead of straight line to avoid
some pot holes?).
Original comment by ezerot...@gmail.com
on 14 Mar 2012 at 11:21
True, the wheel cannot stop suddenly, but the cranks very much can (unless your
rear hub lacks a freewheel).
I have not investigated what sort of averaging my Garmin Edge 705 is using on
the wheel sensor, but my old wired Sigma BC1606L seems to have a 2-second
timeout. If it does not see another pulse from the wheel sensor in 2 seconds,
it will show 0 km/h and stop the clock (which auto-starts based on the wheel
sensor). The crank sensor uses a bit different logic. The BC1606L would display
the last RPM value for a few seconds after the cranks have stopped. In the TCX
files from Edge 705, the RPM will go to 0 virtually instantaneously.
Is your custom code available somewhere? I have been thinking of adding
ANT+Sport sensor support to OsmAnd.
Original comment by msmak...@gmail.com
on 15 Mar 2012 at 8:32
Let me try making it more clear. The real problem with not using averaging is
not when the wheel/cranks stops, but when it starts slowing down. Signals come
from the sensor less and less frequently, and you just can't be sure when the
revolution is really stopped. Let's say the crank is at 60 rpm, and then
suddenly it decreases to 20. This means no new signals for 3 seconds. If our
timeout is shorter than that, then the there will be a "60, 60, 60, ..., 60, 0,
20" sequence in the TCX file. Or there could be more 0 values. IMHO this is not
good.
I've attached my speed sensor support patch. Limitations: saves speed values as
power data, and it has a hardcoded wheel size.
Original comment by ezerot...@gmail.com
on 15 Mar 2012 at 9:56
Attachments:
I see your point now. Thanks for the patch too!
20rpm would be a very slow cadence value. In my opinion, it would be acceptable
to say that 30rpm (1 crank revolution in 2 seconds) is the lowest supported rpm.
Likewise for the speed sensor. Assuming a wheel circumference of 2000mm, 30rpm
on the wheel would be about 1m/s or 3.6km/h, less than normal walking pace. My
wired Sigma BC1606L tacho does displays anything less than 4km/h as 0. On my
kids’ bikes, the 20-inch wheels have a smaller diameter, and the display goes
down to some 2km/h. These speeds require good balance.
If you wanted to have more accuracy for the speed (say, for mountain biking),
that could be achieved by adding spoke magnets and offering the number of
magnets as a configuration parameter. For cranks, it cannot be done that
easily, but I hope that nobody really wants to pedal slower than 30rpm.
In any case, I think that it could be useful to save the raw data in some way
for postprocessing, and to write some software for recomputing the rpm and km/h
values from the raw data.
Original comment by msmak...@gmail.com
on 19 Mar 2012 at 9:43
I'll decrease the history length to 2 seconds and go for some test rides to see
what happens.
Saving ALL the raw data is not too easy unfortunately, because Mytracks seems
to store only one value in a second for every type of attribute. At least this
is what I see in the TCX output.
Original comment by ezerot...@gmail.com
on 19 Mar 2012 at 12:11
Right, saving all raw data would probably be easier in a separate application.
I am planning to look at GPX extensions at some point. I would tend to believe
that like TCX, GPX is probably going to be 1 second per set of samples. The
ANT+Sport raw data would have to carry some sub-second time stamp information,
I guess.
Somehow, I am incompatible with the Eclipse environment. I think I have
installed all prequisites, but it just does not work. :( Other projects that
use plain ant build.xml are easier to get started with.
Original comment by msmak...@gmail.com
on 19 Mar 2012 at 8:11
I'm not sure but looking at your speed algorithm I don't think integrating the
speed value will get back an accurate distance travelled. This would not be
ideal.
Original comment by kenep...@gmail.com
on 22 Mar 2012 at 10:41
Re: Comment 13 by msmak
The 2 seconds history length seems to be not working too well for me, as I'm
seeing too many spikes in the graph. 3 seconds is much better. But this value
should be a user preference setting in the future.
FYI, the "basic" ANT+Sport sensors has 1/1024 seconds resolution.
Eclipse was a PITA to setup, and it's a PITA to work with for me. Such is life
:-/
Re: Comment 14 by kenep
I agree. But if the raw sensor timestamps were used, integration could be more
accurate.
Original comment by ezerot...@gmail.com
on 22 Mar 2012 at 11:18
It would be good to be able to integrate speed to get back the odometry data
from which speed was calculated. Then speed and distance are interchangeable.
Original comment by kenep...@gmail.com
on 25 Mar 2012 at 11:27
How about an algorithm like this?
Until the next pulse arrives or the timeout expires, show the last cadence (or
speed) value. When the pulse arrives, calculate the value. In this way, the
reading would remain stationary when nothing is happening. I think that is
better to show 60,60,60,0 instead of 60,40,20,0 when the cranks suddenly stop
from 60rpm.
The GPX 1.1 format does allow custom extensions, which should allow us to store
and record the ANT+Sport time stamps and data in raw format. I filed Issue#867
for this and am willing to work on that, if I succeed in compiling the code.
Some work would be needed on Issue #24 too. There could be multiple attributes
derived from the same data, such as ‘cadence with 3-second timeout, updating
between pulses’ and ‘cadence with 2-second timeout, updating on arrival of
pulse’.
Original comment by msmak...@gmail.com
on 25 Mar 2012 at 9:07
I like the idea that mytracks should save the raw ANT+ data and provide
multiple computed attributes from it. I've seen requests about raw heart rate
data too - the current version displays the values the HRM sensor computes, and
ignores the raw timestamps.
I've starred #867, maybe I could help you with that.
Original comment by ezerot...@gmail.com
on 26 Mar 2012 at 11:56
Ant+ bike cadence and speed distance are checked in.
Original comment by jshih@google.com
on 11 Sep 2012 at 12:49
Original issue reported on code.google.com by
jte...@gmail.com
on 23 Jul 2011 at 4:52