J-P-Hanafin / mytracks

Automatically exported from code.google.com/p/mytracks
0 stars 0 forks source link

Support ANT+ Speed/Cadence Sensors #523

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
What steps will reproduce the problem?
1.Attempt to detect, with MyTracks,Garmin GSC-10 on SE Xperia mini Pro 
2.Attempt to detect sensor on same platform with ANT+ Bike Display Demo
3.Adjust ANT+ bike display demo proximity search adjusted from default setting 
(3) to (7)

What is the expected output? What do you see instead?
MyTracks should detect and pair with the SC10 sensor

What version of MyTracks are you using? On what version of Android? On what
phone?
Version 1.1.7 on SE Xperia X10 mini pro

If possible please provide a log.  Either upload here or send to mytracks-
support@google.com.
Detailed instructions can be found here:
http://code.google.com/p/mytracks/wiki/HowToReportErrors

Please provide any additional information here:

Original issue reported on code.google.com by jte...@gmail.com on 23 Jul 2011 at 4:52

GoogleCodeExporter commented 9 years ago

Original comment by sandordo...@google.com on 23 Jul 2011 at 8:56

GoogleCodeExporter commented 9 years ago
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

GoogleCodeExporter commented 9 years ago
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

GoogleCodeExporter commented 9 years ago
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

GoogleCodeExporter commented 9 years ago
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

GoogleCodeExporter commented 9 years ago
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

GoogleCodeExporter commented 9 years ago
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

GoogleCodeExporter commented 9 years ago
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

GoogleCodeExporter commented 9 years ago
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

GoogleCodeExporter commented 9 years ago
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:

GoogleCodeExporter commented 9 years ago
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

GoogleCodeExporter commented 9 years ago
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

GoogleCodeExporter commented 9 years ago
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

GoogleCodeExporter commented 9 years ago
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

GoogleCodeExporter commented 9 years ago
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

GoogleCodeExporter commented 9 years ago
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

GoogleCodeExporter commented 9 years ago
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

GoogleCodeExporter commented 9 years ago
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

GoogleCodeExporter commented 9 years ago
Ant+ bike cadence and speed distance are checked in.

Original comment by jshih@google.com on 11 Sep 2012 at 12:49