Odometer - New here so may have been covered previously

[rutger]

I have an '013 RTS and my wife has a '014 RTL and on both bikes the trip meters are very accurate.

Like with in .1 of a mile over a 5 mile interstate check. But also on both bikes the odometer milage reading isn't even close to being accurate. The miles clicking off will vary from .6 of a mile to 1.3 miles from one mile to the next.

And these are digital read outs. Has anyone else noticed this.

My wife's bike has piled up an addition 400 miles of none existing milages per her odometer vs the total trip readouts.

Only reason we even found this out was because we've been recording every full up and miles road from day one on hers and the trip totals were 1831 where the odometer read out was 2217 yesterday. then started watching the odometer and was astonished at how inaccurate it was simple mile to mile. Astonishingly inaccurate!!

[Bob Denman]

I think that she's sneaking out, to go on rides without you... :shocked:

Seriously?? :dontknow:
I'm pretty sure that no adjustments to the system are possible...

[rutger]

Wondering if anyone lease has noticed this. At that rate her bike and possibly both bikes along with who knows how many others are piling up none existence miles at an astonishing rate. A bike with 5,000 miles actually only has 4,000 miles on it.

Depreciating the value of the bike.

[retread]

I haven't paid close attention to the odometers on my Spyders, but I do know that the speedometers have been 3 mph fast on each one.

john

[rutger]

I haven't paid close attention to the odometers on my Spyders, but I do know that the speedometers have been 3 mph fast on each one.

john

You may want to check it out. They are so inaccurate just mile to mile it's astonishing and the 6100 miles I thought I got on my first rear time may have actually been less than 5,000 plus over a few years of riding and what you may believe is 50,000 miles may actually be less than 40,000 at trade in time.

I cant even imagine what the problem could be. How can the trip meter he reading so accurately and the total odometer reading be so far off on consecutive miles. As much as a 1/2 mile or more just from one mile to the next.

[PrairieSpyder]

I haven't paid close attention to the odometers on my Spyders, but I do know that the speedometers have been 3 mph fast on each one.

john

I've hear this is common on motorcycles, that the manufacturers do that on purpose. I'm not sure why.

I also track my MPG, but I use my odometer reading. If it was racking up extra miles, I'd be seeing better mileage, but I'm not. I may have to do a comparison on my next trip.

[rutger]

I've hear this is common on motorcycles, that the manufacturers do that on purpose. I'm not sure why.

I also track my MPG, but I use my odometer reading. If it was racking up extra miles, I'd be seeing better mileage, but I'm not. I may have to do a comparison on my next trip.

I can't even figure out how you could possible program a digital read out to be this inconsistent. It's literally off by up to 1/2 mile from mile to mile. And on both bikes. And speed doesn't seem to be the problem.

One mile will click off on the odometer at a .6 of a mile on the trip tick and the next mile won't click off till 1.2 or 1.3 miles on the trip tick. I can't even imagine HOW you could program it to be that far off.

[Dan McNally]

Good thing the BEST warranty is in years and not miles!

[BikerDoc]

Fortunately mileage does not affect our warranties..... I had noticed the inaccurate speedometer reading so on a recent 1000 mile ride I compared the bike mileage with googles maps and my garmin gps mileage (where the actual speed seems to display). In the end my Spyder had only 17 miles more on the odometer than google and garmin who were within 2 miles of each other....

[2RTsGV]

Fortunately mileage does not affect our warranties..... I had noticed the inaccurate speedometer reading so on a recent 1000 mile ride I compared the bike mileage with googles maps and my garmin gps mileage (where the actual speed seems to display). In the end my Spyder had only 17 miles more on the odometer than google and garmin who were within 2 miles of each other....

I am wondering if maybe one (ie: the mileage or the Trip) is set to Kilometers instead of miles. that sort of difference (.6 miles) aligns with the difference in calculation - 1km = .6m

Just a thought

[Chupaca]

I don't pay attention to mileage mpg's etc having to much fun ryding and using my RS for all the reasons I bought it and this is not one of them (just me). But there are several comparisons made here. Bike to bike (same models) bike to bike (different brands) spyder to the many GPS's and to road markings. The whole system depends on the sensors sending data to the cluster. This would be where to start looking..bent out of place wrong position different size tires and air pressure etc. Maybe a glitch in the conversion of kilometers and miles. Could have some buds correction program...:dontknow:

[bruiser]

Haven't noticed a big difference in mileage but noticed a difference in mph between bikes.

[rutger]

I am wondering if maybe one (ie: the mileage or the Trip) is set to Kilometers instead of miles. that sort of difference (.6 miles) aligns with the difference in calculation - 1km = .6m

Just a thought

Thought of that, even though both indicate miles. The difference works out to about 20%. Not 40%. Miles clicking off on the odometer are not consistent to any distance traveled or seemingly speed related. Mile to Mile the odometer will click off a mile on both Spyders anywhere from .6 up to 1.3 actually miles traveled. Same 5 mile trip check on interstate showed 5.9 miles on the odometer and 5.1 on the trip indicator. (The 5.1 works out to about 100 Ft per mile and that's pretty close. The 5.9 works out to nearly 1/6 of a mile off per mile.)

And that's astonishingly inaccurate as well as poor quality for such an expensive machine.

I've been riding bikes for over 50 years. Honda's mostly and Valkyries for the last 17, one with over 127,000 miles on it and I've never seen an odometer do this or this far off on any car or bike.

At this rate a bike ridden for 40,000 miles will indicate 50,000 at trade in.

I can't even figure out HOW the trip indicator can be so actuate mile after mile and the odometer in the very same cluster can be so inconsistent and inaccurate at the very same time?

[Bob Denman]

It's starting to sound like a, "take it to your dealer", sort of a thing... :opps:
Good luck; please let us know how you proceed with this! :thumbup:

[rutger]

Haven't noticed a big difference in mileage but noticed a difference in mph between bikes.

At least on our's there is very little difference in MPH between the two bikes. Set speed control at 65 on both and the '014 has to be bumped down a mph every now and then and then bumped back up to keep up so difference is well under 1 mph, at least a 65 mph.

[rutger]

It's starting to sound like a, "take it to your dealer", sort of a thing... :opps:
Good luck; please let us know how you proceed with this! :thumbup:

The '014 is getting a new speedo cluster due to condensation behind the plastic but seeing as both bikes act the same (two different year models), I'm doubtful that's the problem. Kind of believe their all doing this. At least the last couple of years worth.

But how? How can the trip indicator be almost dead on and the odometer in the same cluster be SO inaccurate, mile per mile? Aren't both running off the very same set up?

[ARtraveler]

When we go on a 100 + mile ride, we set the B trip meter to zero so that we can keep track of our trip mileage. The end results are usually a few tenths off when comparing one :spyder2: to the other.

I have always attributed that to the difference in tires from one :ani29: to the other. One always has "newer" tires. A newer tire would give a slightly lower reading since more territory was covered per rotation. I think I got this right. :dontknow:

[Bob Denman]

Correct... :clap:
Newer tire: slightly taller diameter and larger rolling circumference... fewer rotations per mile, so fewer miles are registered. ;)

I may be dumb; but I'm not uneducated! :D

[missouriboy]

I have an '013 RTS and my wife has a '014 RTL and on both bikes the trip meters are very accurate.

Like with in .1 of a mile over a 5 mile interstate check. But also on both bikes the odometer milage reading isn't even close to being accurate. The miles clicking off will vary from .6 of a mile to 1.3 miles from one mile to the next.

And these are digital read outs. Has anyone else noticed this.

My wife's bike has piled up an addition 400 miles of none existing milages per her odometer vs the total trip readouts.

Only reason we even found this out was because we've been recording every full up and miles road from day one on hers and the trip totals were 1831 where the odometer read out was 2217 yesterday. then started watching the odometer and was astonished at how inaccurate it was simple mile to mile. Astonishingly inaccurate!!I have long noticed that the total miles DO tick over at an unpredictable variance from the trip miles. I don't know the variance, but let's accept your observation of .6 to 1.3 miles per tick-over.

I have always surmised that this difference is because the total miles display gets updated at a LOWER PRIORITY than the trip miles display. Because the latter is in TENTHS and the former is in WHOLE MILES only? By priority, I mean that Miss Nanny is very, very busy and must tend to high-priority chores with more urgency, and then does the low-priority stuff (like total miles) when she can finally get a ROUND TUIT.

Since reading this thread, I've been watching my three displays, and notice NO 20% error between them, only a mile or so, and this is because it's impossible to accurately compare a TENTHS display to WHOLE NUMBER display. Especially if they truly do get updated at different priorities (instead of at the same time, which is how I would program it... I think!).

Now, I also surmise that miles/kilometers are not even stored anywhere, but are simply computed from scratch each time the screen-display is updated. Constantly storing them is an unnecessary burden for Miss Nanny! Only the total wheel-count needs to be permanently stored, for the life of the machine, and then all displays are computed from that value, when needed. There would be two more such counter-fields, one for each trip meter; when you reset them, the main counter is simply copied to it, then its display is computed from the difference between it and the total counter. That's why its display is always zero at reset, though the counter is not really zero at all!

Disclaimer: I am not an engineer or programmer for this system, nor have I ever played one on TV. I'm just saying this is how it would work, or something like this, if I were doing the job!

Therefore: I find it difficult to believe that there would be any 20% discrepancy between these displays... at least I have satisfied myself that MY Spyder, at 20,600 miles, has no such discrepancy.

[PrairieSpyder]

I have long noticed that the total miles DO tick over at an unpredictable variance from the trip miles. I don't know the variance, but let's accept your observation of .6 to 1.3 miles per tick-over.

I have always surmised that this difference is because the total miles display gets updated at a LOWER PRIORITY than the trip miles display. Because the latter is in TENTHS and the former is in WHOLE MILES only? By priority, I mean that Miss Nanny is very, very busy and must tend to high-priority chores with more urgency, and then does the low-priority stuff (like total miles) when she can finally get a ROUND TUIT.

Since reading this thread, I've been watching my three displays, and notice NO 20% error between them, only a mile or so, and this is because it's impossible to accurately compare a TENTHS display to WHOLE NUMBER display. Especially if they truly do get updated at different priorities (instead of at the same time, which is how I would program it... I think!).

Now, I also surmise that miles/kilometers are not even stored anywhere, but are simply computed from scratch each time the screen-display is updated. Constantly storing them is an unnecessary burden for Miss Nanny! Only the total wheel-count needs to be permanently stored, for the life of the machine, and then all displays are computed from that value, when needed. There would be two more such counter-fields, one for each trip meter; when you reset them, the main counter is simply copied to it, then its display is computed from the difference between it and the total counter. That's why its display is always zero at reset, though the counter is not really zero at all!

Disclaimer: I am not an engineer or programmer for this system, nor have I ever played one on TV. I'm just saying this is how it would work, or something like this, if I were doing the job!

Therefore: I find it difficult to believe that there would be any 20% discrepancy between these displays... at least I have satisfied myself that MY Spyder, at 20,600 miles, has no such discrepancy.

Nice try, but I don't think your assumptions will hold water. I have been a systems analyst, though we wouldn't know about how the Spyder systems work without having the algorithms to see, or commentary from the system developers.

In a system you have 2 costs: storage and processing. When storage costs more than processing, you recalculate whenever you need to. When processing is more expensive you use storage and retrieve as needed. Your speculation about the system recalculating mileage each time you turn on your Spyder heavily uses both storage and processing - keeping lots of mileage numbers and adding them up every time you turn on the key. It's also overly complex, when all the system really has to do is store three numbers: the last odometer reading, and the Trip A and Trip B totals. (Even though the odometer doesn't display tenths of miles, the system has to keep track of it to know when to incrementally increase the display.) No processing is needed except to retrieve those three pieces of data and put them in the appropriate area of the display.

As to prioritization of the ongoing addition of miles to the trip counters and odometer, I doubt that is necessary. The same input (not sure of this, but maybe number of rotations of the rear tire) go into a trigger to advance the three data fields. and a simple "add .1 mile" isn't that complex of a process. In fact, the same .1 mile increment probably goes into the odometer total, but it doesn't display an increase until it occurs 10 times.

[Bob Denman]

Patti... :shocked:
I have no idea what you just said...
But it sure sounds good! :D :thumbup:
I'm just gonna ride mine.
Each mile that I've added; is less important to me, than the next mile that I'll add...

[Oldmanzues]

Patti... :shocked:
I have no idea what you just said...
But it sure sounds good! :D :thumbup:
I'm just gonna ride mine.
Each mile that I've added; is less important to me, than the next mile that I'll add...

Iagree with this other Bob. I am one too.
My speedometer seems to agree with my GPS on that account. I would suggest writing down the milage at the start of a trip/time period, then seting the trip to 0 and after 200 or three hundred miles checking the difference.
Just a thought
Oldmanzues

[missouriboy]

Hi Patti :thumbup:

It's great to see your intelligent reply with further analysis, but I must still respectfully disagree with your conclusions. Your approach of using the 2 costs is very good, but the analysis doesn't compare all the required activity deeply enough, in my opinion.

I'll expand on this by embedding my comments within your quote, in bold like this. And then follow-up with......... after the quote.


Nice try, but I don't think your assumptions will hold water. I have been a systems analyst, though we wouldn't know about how the Spyder systems work without having the algorithms to see, or commentary from the system developers.
I'll attempt to demonstrate that my assumptions could hold water quite well. I too have enjoyed a very successful career as a programmer/analyst, although in a quite different field than would be required here. (Manufacturing, production control, etc. on mainframe and mini-computers.)

In a system you have 2 costs: storage and processing. When storage costs more than processing, you recalculate whenever you need to. When processing is more expensive you use storage and retrieve as needed. So far, so good. Excellent, in fact! Your speculation about the system recalculating mileage each time you turn on your Spyder NO, NO, much more often than that. Every 1/10th of a mile, at least. heavily uses both storage and processing - keeping lots of mileage numbers NO. No mileage numbers, just one simple count of total wheel revolutions, as they occur. and adding them up every time you turn on the key. Again, boot-up is not described here, though it would be involved also, of course.


It's also overly complex, when all the system really has to do is store three numbers: the last odometer reading, and the Trip A and Trip B totals. This is where I believe your analysis isn't thorough enough: first the system needn't store "odometer" readings at all; this is what I say is too expensive. To do so would require computing them from the wheel-counter each time that counter increments. For an 80-inch tire tread, that counter increments 792 times per mile, which at 60mph would be 792rpm, or 47,520 times each hour. The least expensive thing for the system to be doing this often is to increment and store ONE simple counter (for the life of the machine). All other desired information is converted from this one count. But there is NO NEED to do the conversion every time the counter increments. This is what I say is an unnecessary burden on Miss Nanny, because such information is not needed with every wheel turn. It's only needed every 79.2 turns, at the event of having covered .1 linear mile. How would it know when .1 mile has been covered? This could be incorporated in the much higher-priority task that updates the speedometer display, that is also being driven by the wheel-count function, compared against elapsed time. There would be an algorithm in that routine to indicate when to invoke the odometer display task, which would within itself reset the event-indicator used by the speedometer task.

(Even though the odometer doesn't display tenths of miles, the system has to keep track of it to know when to incrementally increase the display.) No processing is needed except to retrieve those three pieces of data and put them in the appropriate area of the display.

As to prioritization of the ongoing addition of miles to the trip counters and odometer, I doubt that is necessary. The same input (not sure of this, but maybe number of rotations of the rear tire) go into a trigger to advance the three data fields. and a simple "add .1 mile" isn't that complex of a process. In fact, the same .1 mile increment probably goes into the odometer total, but it doesn't display an increase until it occurs 10 times.Remember, the system must accommodate the user-selectable option to give the displays in either kilometers or miles. A single running copy of each processing task would serve either choice because it would use constants that get initiated during the user setup function. All these constants would have many decimal places, to provide accuracy in the rounded, truncated output.

We haven't analyzed the speedometer task at all, but it would be heavily coordinated in all of this, and leads me to surmise about the task prioritizing within a very busy multi-tasking system. Other tasks would have even higher priority than these, as they would have to do with safety and these are only casual displays.

You're right that we cannot know the whole truth until someone more knowledgeable chimes in. But it's been fun to speculate and debate with you about it; it keeps the ol' gray matter exercised, doesn't it?
What a great forum!:yes:

[ARtraveler]

Well...at least we got some good technical stuff to spar about. Just what the posters were screaming for about a week or so ago. :roflblack::roflblack:

[Bob Denman]

http://www.youtube.com/watch?v=X4OKPMm-vfc

[PrairieSpyder]

I'll defer to MissouriBoy about the system. I'm a logical analyst and not a programmer. Also, my eyes are spinning trying to figure it all out. It's a good thing I'm retired.

In any case, I don't think the software is the problem, or everyone would notice discrepancies.

[missouriboy]

Well, I don't think we've made any great conclusions here, I've only touched on some possible ways the system could work, without really coming up with a good answer to the OP's original question: Why the .6 to 1.3 variation in the 'total' odometer tick-over, when the 'trip' meter seems to update much more accurately? I only surmised it could be the lower priority of the screen-update task, but I don't feel I've actually proven a single thing.

I know this variance occurs, even on my own machine. But WHY? :banghead:

And has anyone else concluded that their main odometer could be off by up to 20%? I believe my own is NOT off by anything like that amount, so Rutger has really found a glitch here. Or has he?

Anybody else have similar observations? :dontknow:

[Gray Ghost]

Now, I also surmise that miles/kilometers are not even stored anywhere, but are simply computed from scratch each time the screen-display is updated. Constantly storing them is an unnecessary burden for Miss Nanny! Only the total wheel-count needs to be permanently stored, for the life of the machine, and then all displays are computed from that value, when needed.

Granted that all programmers bring their own ideas to the table, I can't see one taking your approach. A simple counting function is not really a burden on a computing system. The easiest way to do this process, IMHO, is one simple counting loop that sends a count to three different storage areas. One, the odometer has no reset capability and is written to storage (doesn't lose the value even when battery is disconnected). The other two would give the operator the ability to reset the count to zero, not sure if they save the data even without power but at least a couple of times that techs have had my bike for work that I would have disconnected the battery for the count has remained in the trip meters. As has been mentioned before it makes sense for the system to maintain the tenths even though it is not displayed in the odometer function.

But without the code or at least the flowchart none of us have the answer.

[Bob Denman]

:shocked: I think that we cab all agree that a computer can pretty much count in it's sleep... :D
How is it getting the inputs from the wheel's rotation? Is there any way for THAT input to be getting scrambled a bit, along the way? :dontknow:

[Gray Ghost]

:shocked: I think that we cab all agree that a computer can pretty much count in it's sleep... :D
How is it getting the inputs from the wheel's rotation? Is there any way for THAT input to be getting scrambled a bit, along the way? :dontknow:

There are Hall effect wheel speed sensors on each wheel. Every time a certain spot on the wheel comes by it sends a signal to the VCM. Any sensor can go bad, but I would believe that a code would be thrown if one was no longer reporting wheel movement. I don't know how the computer correlates the data from all three sensors, my experience has been with bikes that have one sensor for speed/distance.

[missouriboy]

Granted that all programmers bring their own ideas to the table, I can't see one taking your approach. A simple counting function is not really a burden on a computing system. The easiest way to do this process, IMHO, is one simple counting loop that sends a count to three different storage areas. One, the odometer has no reset capability and is written to storage (doesn't lose the value even when battery is disconnected). The other two would give the operator the ability to reset the count to zero, not sure if they save the data even without power but at least a couple of times that techs have had my bike for work that I would have disconnected the battery for the count has remained in the trip meters. As has been mentioned before it makes sense for the system to maintain the tenths even though it is not displayed in the odometer function.

But without the code or at least the flowchart none of us have the answer.This would work fine too, but the value to be added would not simply be '1'. And there would have to be six counters, not just three:
Remember, the system must accommodate the user-selectable option to give the displays in either kilometers or miles. A single running copy of each processing task would serve either choice because it would use constants that get initiated during the user setup function. All these constants would have many decimal places, to provide accuracy in the rounded, truncated output.So, lets say the wheel being counted has a 25" diameter... the values to be added would be .0012395 for the three 'miles' counters, and .0019949 for the three 'kilometers' counters.

So at each rotation, these six 'decimal add' operations would have to occur, instead of the single-counter bump of '1 bit' in a binary counter, to be edited only 2 ways, later, at each .1 mile.

Either way, the odometer-display update routine has approximately the same amount of work to do, each time it executes, 10 times per mile. The 'wheel-count' update happens about 806 times per mile.

So then the question of 'cost' is: do we choose a simple binary-increment of '1' to a single counter, 800+ times per mile? Or do we choose to execute a decimal-add operation against six counters each time, instead?

Let's just let the boss choose! :clap:

[Gray Ghost]

This would work fine too, but the value to be added would not simply be '1'. And there would have to be six counters, not just three: So, lets say the wheel being counted has a 25" diameter... the values to be added would be .0012395 for the three 'miles' counters, and .0019949 for the three 'kilometers' counters.

There is really no need for six counters. The diameter of the wheel, in inches and centimeters is a constant. The hall sensor counts each revolution of the wheel. If the display is set to miles, the count is multiplied by the inch constant, if you set it to kilometers, it is multiplied by the metric constant.

[PrairieSpyder]

http://smileys.emoticonsonly.com/emoticons/s/stop_sign-3669.gif Please!!!!

I woke up this morning writing in my mind some structured English logic for how to keep track and display the odometer and trip counters!!! I don't get paid for that anymore and I have more fun things to think about. I'm a recovering analyst and just because my mind is wired that way doesn't mean I have to keep doing it!!:gaah:

[Bob Denman]

:shocked: Won't someone help her, before she starts analyzing again! :yikes:

[missouriboy]

There is really no need for six counters. The diameter of the wheel, in inches and centimeters is a constant. The hall sensor counts each revolution of the wheel. If the display is set to miles, the count is multiplied by the inch constant, if you set it to kilometers, it is multiplied by the metric constant.ABSOLUTELY TRUE! And that puts back exactly to my original approach: the one that...

http://www.spyderlovers.com/forums/images/misc/quote_icon.png Originally Posted by Gray Ghost http://www.spyderlovers.com/forums/images/buttons/viewpost-right.png (http://www.spyderlovers.com/forums/showthread.php?p=885361#post885361)

Granted that all programmers bring their own ideas to the table, I can't see one taking your approach. <snip>

Review my original approach, which stated:

Only the total wheel-count needs to be permanently stored, for the life of the machine, and then all displays are computed from that value, when needed. There would be two more such counter-fields, one for each trip meter; when you reset them, the main counter is simply copied to it, then its display is computed from the difference between it and the total counter. That's why its display is always zero at reset, though the counter is not really zero at all!
Thus, the hall sensor only has to bump one counter each time. Thanks for validating it! :ohyea:

[missouriboy]

http://smileys.emoticonsonly.com/emoticons/s/stop_sign-3669.gif Please!!!!Sorry, Patti, I didn't mean to stress you!
I don't get paid for this either, but the mental exercise is fun! :yes:

[PrairieSpyder]

Sorry, Patti, I didn't mean to stress you!
I don't get paid for this either, but the mental exercise is fun! :yes:

It was fun when I realized there's a job for the way my brain works. But sometimes I can't turn it off!! No worries. I got off the wagon when I first responded to you.

[Bob Denman]

I don't get paid for this either, but the mental exercise is fun! :yes:

:lecturef_smilie: We'd prefer that you not use such profanity in here! :yikes:

[Dan_Ashley]

Three displays. Three little men. Two are tea totalers--they are in charge of trip A and trip B. They are unionized and very content.

The third man is a drunk. He is never sober. His favorite beverage is double malt. Once he went on the wagon and got the DTs. It was so bad all the guys who work on the cluster went on strike, and the cluster was just black--no display at all. Now, they just let him drink. At least he doesn't smoke and hang around with loose women--that would be really bad.

[missouriboy]

:lecturef_smilie: We'd prefer that you not use such profanity in here! :yikes:Hey, I hear ya!
And how about WORK? Isn't that a four-letter word too? nojoke

[Bob Denman]

http://smileys.smileycentral.com/cat/36/36_11_23.gif http://smileys.smileycentral.com/cat/36/36_12_1.gif

[MidTNDawg]

I have an '013 RTS and my wife has a '014 RTL and on both bikes the trip meters are very accurate.

Like with in .1 of a mile over a 5 mile interstate check. But also on both bikes the odometer milage reading isn't even close to being accurate. The miles clicking off will vary from .6 of a mile to 1.3 miles from one mile to the next.

And these are digital read outs. Has anyone else noticed this.

My wife's bike has piled up an addition 400 miles of none existing milages per her odometer vs the total trip readouts.

Only reason we even found this out was because we've been recording every full up and miles road from day one on hers and the trip totals were 1831 where the odometer read out was 2217 yesterday. then started watching the odometer and was astonished at how inaccurate it was simple mile to mile. Astonishingly inaccurate!!

did this and apparently with "intent". It was about 1972. They were made to extend the warranty to allow for the incorrect reading. I do think I will check mine more closely although warranty is not a particular problem.

[Gray Ghost]

Only the total wheel-count needs to be permanently stored, for the life of the machine, and then all displays are computed from that value, when needed. There would be two more such counter-fields, one for each trip meter; when you reset them, the main counter is simply copied to it, then its display is computed from the difference between it and the total counter. That's why its display is always zero at reset, though the counter is not really zero at all!

Patti, please ignore.

Actually missouriboy, we differ on the portion of your original post shown above. The way I would do it, and I surmise that they did it, is to have three counters, the count from the wheel sensor goes to each. The counters for the trip meters have a reset function to zero the count, the odometer does not. No copying from the odometer to the other counters.

If rider choice equals "metric"
odometer display = counter 1 x metric constant
trip a display = counter 2 x metric constant
trip b display = counter 3 x metric constant

if rider choice equals "standard"
odometer display = counter 1 x standard constant
trip a display = counter 2 x standard constant
trip b display = counter 3 x standard constant

At any point in time that the rider resets a trip meter, the appropriate counter is immediately zeroed out and the count begins at 1 again.

[missouriboy]

Actually missouriboy, we differ on the portion of your original post shown above. The way I would do it, and I surmise that they did it, is to have three counters,
Look closely at my solution again: it has exactly the same three counters.

the count from the wheel sensor goes to each.
And THAT'S where the big difference in "cost" lies! This entails 1,612 ADD operations that my solution eliminates. EACH MILE.

The counters for the trip meters have a reset function to zero the count, the odometer does not. No copying from the odometer to the other counters.

So? There is no "cost" difference here. It is not materially different for the computer to: MOVE ODOMETER-COUNT TO TRIP-COUNT (me) rather than MOVE ZERO TO TRIP-COUNT (you). Later, in the Cluster-Update task, the user still sees ZERO so he doesn't care.

If rider choice equals "metric"
odometer display = counter 1 x metric constant
trip a display = counter 2 x metric constant

My solution adds a SUBTRACT operation here: "trip a display = (counter 1 - counter 2) x metric constant"

By adding one SUBTRACT operation here, ten times per mile, I eliminate two ADD operations from the Hall Sensor update, 806 times per mile.

Which way would be more computer-efficient?

(I thought all of this would be obvious from my first descriptions, earlier. My bad!)
I be shutting down now, to embark on a little 2 or 3 week vacation trip, so I don't know when I'll be getting back on here. See ya!
Cheers, everybody! :yes:

[Gray Ghost]

Actually missouriboy, we differ on the portion of your original post shown above. The way I would do it, and I surmise that they did it, is to have three counters,
Look closely at my solution again: it has exactly the same three counters.

the count from the wheel sensor goes to each.
And THAT'S where the big difference in "cost" lies! This entails 1,612 ADD operations that my solution eliminates. EACH MILE.

The counters for the trip meters have a reset function to zero the count, the odometer does not. No copying from the odometer to the other counters.

So? There is no "cost" difference here. It is not materially different for the computer to: MOVE ODOMETER-COUNT TO TRIP-COUNT (me) rather than MOVE ZERO TO TRIP-COUNT (you). Later, in the Cluster-Update task, the user still sees ZERO so he doesn't care.

If rider choice equals "metric"
odometer display = counter 1 x metric constant
trip a display = counter 2 x metric constant

My solution adds a SUBTRACT operation here: "trip a display = (counter 1 - counter 2) x metric constant"

By adding one SUBTRACT operation here, ten times per mile, I eliminate two ADD operations from the Hall Sensor update, 806 times per mile.

Which way would be more computer-efficient?

(I thought all of this would be obvious from my first descriptions, earlier. My bad!)

Actually you aren't really saving any operations. The sensors are constantly updating, and the display is also constantly being updated, even though you only notice when the numbers change. So in your system, rather than just multiplying the count from the trip meter register by the constant, the system has to grab the odometer register, subtract the trip reset value and then multiply it times the constant. It would be possible to only update the system at a tenth of a mile, but then you are going to have to have a separate counter that counts up the wheel rotations and then triggers your subtraction loop once a tenth of a mile has been reached.

And you are adding two subtract operations, not just one. You have two separate trip meters so you would have to store separate values for each. And another counter operation for the other trip meter to determine when that trip meter needs to click over another tenth.

The processing time needed to run counts on three separate counters is not that great, especially since we are talking the Spyder as having multiple "computers". What is more critical is having each operation be as simple as possible.

Have fun on your trip.

[JayBros]

This thread comes at an opportune time for me. I left the dealership with an alleged full tank of gas in my new Spyder that had a five mile tech test ride. Filled the tank today in prep for tomorrow's ride and trip meter read 168.0 while odometer read 167. My Dilbert level spreadsheet sums the trip meter miles so I'll be able to compare that sum to the latest odometer reading--if I remember to write down the info.

[Bfromla]

Wow¿ dont know got me wondering, my trip meters seem to match my odometer & my respective tank milage, oddly enough I've racked up 8181miles in only 142days of ownership! Casual riding ,only one big trip 925m round trip, the rest is me just 96736 going out for daily ride. Hope there is no error!


Sent from my iPhone using Tapatalk

[StanProff]

Patti... :shocked:
I have no idea what you just said...
But it sure sounds good! :D :thumbup:
I'm just gonna ride mine.
Each mile that I've added; is less important to me, than the next mile that I'll add...

My gray matter was overloaded at "I have". :hun:
:dontknow:

[missouriboy]

Originally Posted by missouriboy http://www.spyderlovers.com/forums/images/buttons/viewpost-right.png (http://www.spyderlovers.com/forums/showthread.php?p=885898#post885898)

Actually missouriboy, we differ on the portion of your original post shown above. The way I would do it, and I surmise that they did it, is to have three counters,
Look closely at my solution again: it has exactly the same three counters.

the count from the wheel sensor goes to each.
And THAT'S where the big difference in "cost" lies! This entails 1,612 ADD operations that my solution eliminates. EACH MILE.

The counters for the trip meters have a reset function to zero the count, the odometer does not. No copying from the odometer to the other counters.

So? There is no "cost" difference here. It is not materially different for the computer to: MOVE ODOMETER-COUNT TO TRIP-COUNT (me) rather than MOVE ZERO TO TRIP-COUNT (you). Later, in the Cluster-Update task, the user still sees ZERO so he doesn't care.

If rider choice equals "metric"
odometer display = counter 1 x metric constant
trip a display = counter 2 x metric constant

My solution adds a SUBTRACT operation here: "trip a display = (counter 1 - counter 2) x metric constant"

By adding one SUBTRACT operation here, ten times per mile, I eliminate two ADD operations from the Hall Sensor update, 806 times per mile.

Which way would be more computer-efficient?

(I thought all of this would be obvious from my first descriptions, earlier. My bad!)





Actually you aren't really saving any operations. The sensors are constantly updating, and the display is also constantly being updated, even though you only notice when the numbers change. So in your system, rather than just multiplying the count from the trip meter register by the constant, the system has to grab the odometer register, subtract the trip reset value and then multiply it times the constant. It would be possible to only update the system at a tenth of a mile, but then you are going to have to have a separate counter that counts up the wheel rotations and then triggers your subtraction loop once a tenth of a mile has been reached.

And you are adding two subtract operations, not just one. You have two separate trip meters so you would have to store separate values for each. And another counter operation for the other trip meter to determine when that trip meter needs to click over another tenth.

The processing time needed to run counts on three separate counters is not that great, especially since we are talking the Spyder as having multiple "computers". What is more critical is having each operation be as simple as possible.

Have fun on your trip.I am having fun! Except for the constant rain during the first whole week of it, here in Missouri. But now, since Wednesday, the October weather in MO is as beautiful as ever here around Camdenton and the Lake area. Life is Gooood! But I haven't even seen a Spyder since October 7th! Dang!



Cliff, no offense man, but your interpretation and critique of my solution is just wrong, seven ways from Sunday! Let's walk through it step by step again:
Actually you aren't really saving any operations.



But of course I am... hundreds of them, at execution time. Read on:



The sensors are constantly updating, and the display is also constantly being updated, even though you only notice when the numbers change.



No. Not even close. The computer does millions of operations per second, but the sensor in question here only hits 806 times per mile, which at 60mph would be approximately 14 times per second. Now, 14 is only the teensy-tiniest fraction of "millions," isn't it? And all my other operations occur far less frequently than that! So, there is nothing about the odometer function that would be anything near "constantly."


The only thing that is constantly running is the loop that polls each sensor-value to see if it has changed since last time. When so indicated, a Task is invoked to process that new information. In our case here, the Hall-sensor just creates a hardware interrupt to signal the occurrence of some event, rather than passing some analog value, like temperature for instance. The operating system still must invoke its associated Task, and this task would ADD 1 TO WHEEL-COUNT. Period. ONE operation. Far, far less frequently than many other sensors do their thing, such as those for the ECM and VSS, for example.


Then, a running task may also invoke other tasks (or not) depending on some condition discovered during its own current run.


So in your system, rather than just multiplying the count from the trip meter register by the constant, the system has to grab the odometer register, subtract the trip reset value and then multiply it times the constant.

It doesn't have to "grab" anything, it's already there. Remember, I just used the WHEEL-COUNT to compute, edit and display the total miles. In the very next instruction, I subract the TRIP-COUNT from it to compute, edit and display the trip-miles. This ONE subtract operation is done here, ten times per mile, to eliminate TWO add operations in the sensor-task, 806 times per mile. All the other operations in this task already existed.

It would be possible to only update the system at a tenth of a mile, but then you are going to have to have a separate counter that counts up the wheel rotations and then triggers your subtraction loop once a tenth of a mile has been reached.

Believe me, it is already being done this way by some other task in the system, due to the periodic (occasional) nature of these tasks. Review the "task invocation" discussion above. I don't address this "trigger" function because I'm not changing it in any way.

And you are adding two subtract operations, not just one. No. Just one. Please read and comprehend the entire application.

You have two separate trip meters so you would have to store separate values for each. Yes. Exactly. Three counters, for total count, trip A count and trip B count. There is no change here; these counters obviously already exist.

And another counter operation for the other trip meter to determine when that trip meter needs to click over another tenth.

No. Look at your display... how many mileage figures appear there? Just two, not three. My "trip counters" are not counters at all, they're just constants that change only when you Reset them. Then they just lie there dormant and unchanging, so just one of them (not both) can be used in a simple subtract operation, ten times per mile, within a task that's already happening anyway.
Only "When needed," as I have mentioned before. Thus saving HUNDREDS more operations, mile after mile after mile...



<snip>I could write a synopsis of the whole application, but I should hope I wouldn't have to. It already appears throughout my previous posts in this thread.
Happy rYding, All! :yes:

[missouriboy]

I have an '013 RTS and my wife has a '014 RTL and on both bikes the trip meters are very accurate.

Like with in .1 of a mile over a 5 mile interstate check. But also on both bikes the odometer milage reading isn't even close to being accurate. The miles clicking off will vary from .6 of a mile to 1.3 miles from one mile to the next.

And these are digital read outs. Has anyone else noticed this.

My wife's bike has piled up an addition 400 miles of none existing milages per her odometer vs the total trip readouts.

Only reason we even found this out was because we've been recording every full up and miles road from day one on hers and the trip totals were 1831 where the odometer read out was 2217 yesterday. then started watching the odometer and was astonished at how inaccurate it was simple mile to mile. Astonishingly inaccurate!!I remembered this post, so recently I carefully recorded all figures each time I reset a Trip Count, for over 700 miles. Then I entered the raw numbers into a spreadsheet and let the computer "do the math" as displayed here...




Odometer

Miles

Trip A

ODO

Error

Trip B

ODO

Error





















23164









(start)







23202

38

(start)













23235

33







70.4

71

0.6



23285

50







50.3

50

-0.3



23357

72

155.2

155

0.2









23364

7







78.6

79

0.4



23462

98







98.3

98

-0.3



23512

50

154.3

155

-0.7









23539

27







76.9

77

0.1



23587

48







47.4

48

0.6



23639

52

127.1

127

0.1









23641

2







54.4

54

-0.4



23790

149

150.7

151

-0.3









23792

2







150.8

151

0.2



23907

115

116.6

117

-0.4

114.9

115

0.1











-1.1





0.1



Totals

see ODO>

703.9

705

-1.1

742

743

1.0




I was surprised to see the difference even reach as high as 1 mile, much less more than 1 mile. This may be an anomaly of displaying a different precision for each counter-type, which would normally give a discrepancy of "up to" +/- .9 mile. I can't explain why the total reached more than that, but I feel it could never reach more than 1.1 (without being able to explain why: I'm not a mathematician). Perhaps one more reading would have reverted back to 1.0 or less...?

At any rate, I've proven to myself that careful recording indicates NO such error as 20% or so, at least for my machine.

YMMV! :coffee:

[Dan_Ashley]

Nice try, but I don't think your assumptions will hold water. I have been a systems analyst, though we wouldn't know about how the Spyder systems work without having the algorithms to see, or commentary from the system developers.

In a system you have 2 costs: storage and processing. When storage costs more than processing, you recalculate whenever you need to. When processing is more expensive you use storage and retrieve as needed. Your speculation about the system recalculating mileage each time you turn on your Spyder heavily uses both storage and processing - keeping lots of mileage numbers and adding them up every time you turn on the key. It's also overly complex, when all the system really has to do is store three numbers: the last odometer reading, and the Trip A and Trip B totals. (Even though the odometer doesn't display tenths of miles, the system has to keep track of it to know when to incrementally increase the display.) No processing is needed except to retrieve those three pieces of data and put them in the appropriate area of the display.

As to prioritization of the ongoing addition of miles to the trip counters and odometer, I doubt that is necessary. The same input (not sure of this, but maybe number of rotations of the rear tire) go into a trigger to advance the three data fields. and a simple "add .1 mile" isn't that complex of a process. In fact, the same .1 mile increment probably goes into the odometer total, but it doesn't display an increase until it occurs 10 times.it probably stores wheel revolution counts. That would be the most granular data available. It is trivial to calculate miles or kilometers from that. What could account for the differences between the reported measurements could be rounding of the result verses truncating the results into whole numbers. I might suggest re-measuring the variance after a non-stop Ryde of 100 miles.

[kep-up]

Does it really matter? Or are some of us simply a bit anal-retentive?

[Dan_Ashley]

Does it really matter? Or are some of us simply a bit anal-retentive?
I am not a little bit anal.

NO NOT A BIT!

I am a whole lot anal. 💀💩
Sorry

[Bfromla]

Wow¿ dont know got me wondering, my trip meters seem to match my odometer & my respective tank milage, oddly enough I've racked up 8181miles in only 142days of ownership! Casual riding ,only one big trip 925m round trip, the rest is me just 96736 going out for daily ride. Hope there is no error!


Sent from my iPhone using Tapatalk

Now od is @ 11494 had recall service done today fuse box water seal (warranty) and chat with tech mentioned good point about we dont relies how much "slippage" happens when you hit a bump or pothole & it adds up quick. Especially if its on same street as your house! Air pressures can change the diameter of the tire enough to add extra kick to the math. Can't be to precise and comfort of rubber tires.
Relax like a biker and be glad your machine is working , enjoy the air[emoji41]


Sent from my iPad using Tapatalk

[MidTNDawg]

About 1972 Suzuki was found culpable of making their odometers "read fast". I do not recall for sure but I think the speedo was fast also. As already noted, this shortens the warranty period. Suzuki received a fine.