Our 2 Spyder's Odometers aren't accurate, but the Trip meters are - anyone else notice?

[Bob Denman]

 

[MidTNDawg]

Some years ago Suzuki

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]

Good Time for Topic

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 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! :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

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...

[TABLE="width: 516"]
[TR]
[TD="width: 12%"]

Odometer​

[/TD]
[TD="width: 13%"]

Miles​

[/TD]
[TD="width: 12%"]

Trip A​

[/TD]
[TD="width: 12%"]

ODO​

[/TD]
[TD="width: 12%"]

Error​

[/TD]
[TD="width: 12%"]

Trip B​

[/TD]
[TD="width: 12%"]

ODO​

[/TD]
[TD="width: 12%"]

Error​

[/TD]
[/TR]
[TR]
[TD="width: 12%"]
[/TD]
[TD="width: 13%"]
[/TD]
[TD="width: 12%"]
[/TD]
[TD="width: 12%"]
[/TD]
[TD="width: 12%"]
[/TD]
[TD="width: 12%"]
[/TD]
[TD="width: 12%"]
[/TD]
[TD="width: 12%"]
[/TD]
[/TR]
[TR]
[TD="width: 12%"]

23164​

[/TD]
[TD="width: 13%"]
[/TD]
[TD="width: 12%"]
[/TD]
[TD="width: 12%"]
[/TD]
[TD="width: 12%"]
[/TD]
[TD="width: 12%"]

(start)​

[/TD]
[TD="width: 12%"]
[/TD]
[TD="width: 12%"]
[/TD]
[/TR]
[TR]
[TD="width: 12%"]

23202​

[/TD]
[TD="width: 13%"]

38​

[/TD]
[TD="width: 12%"]

(start)​

[/TD]
[TD="width: 12%"]
[/TD]
[TD="width: 12%"]
[/TD]
[TD="width: 12%"]
[/TD]
[TD="width: 12%"]
[/TD]
[TD="width: 12%"]
[/TD]
[/TR]
[TR]
[TD="width: 12%"]

23235​

[/TD]
[TD="width: 13%"]

33​

[/TD]
[TD="width: 12%"]
[/TD]
[TD="width: 12%"]
[/TD]
[TD="width: 12%"]
[/TD]
[TD="width: 12%"]

70.4​

[/TD]
[TD="width: 12%"]

71​

[/TD]
[TD="width: 12%"]

0.6​

[/TD]
[/TR]
[TR]
[TD="width: 12%"]

23285​

[/TD]
[TD="width: 13%"]

50​

[/TD]
[TD="width: 12%"]
[/TD]
[TD="width: 12%"]
[/TD]
[TD="width: 12%"]
[/TD]
[TD="width: 12%"]

50.3​

[/TD]
[TD="width: 12%"]

50​

[/TD]
[TD="width: 12%"]

-0.3​

[/TD]
[/TR]
[TR]
[TD="width: 12%"]

23357​

[/TD]
[TD="width: 13%"]

72​

[/TD]
[TD="width: 12%"]

155.2​

[/TD]
[TD="width: 12%"]

155​

[/TD]
[TD="width: 12%"]

0.2​

[/TD]
[TD="width: 12%"]
[/TD]
[TD="width: 12%"]
[/TD]
[TD="width: 12%"]
[/TD]
[/TR]
[TR]
[TD="width: 12%"]

23364​

[/TD]
[TD="width: 13%"]

7​

[/TD]
[TD="width: 12%"]
[/TD]
[TD="width: 12%"]
[/TD]
[TD="width: 12%"]
[/TD]
[TD="width: 12%"]

78.6​

[/TD]
[TD="width: 12%"]

79​

[/TD]
[TD="width: 12%"]

0.4​

[/TD]
[/TR]
[TR]
[TD="width: 12%"]

23462​

[/TD]
[TD="width: 13%"]

98​

[/TD]
[TD="width: 12%"]
[/TD]
[TD="width: 12%"]
[/TD]
[TD="width: 12%"]
[/TD]
[TD="width: 12%"]

98.3​

[/TD]
[TD="width: 12%"]

98​

[/TD]
[TD="width: 12%"]

-0.3​

[/TD]
[/TR]
[TR]
[TD="width: 12%"]

23512​

[/TD]
[TD="width: 13%"]

50​

[/TD]
[TD="width: 12%"]

154.3​

[/TD]
[TD="width: 12%"]

155​

[/TD]
[TD="width: 12%"]

-0.7​

[/TD]
[TD="width: 12%"]
[/TD]
[TD="width: 12%"]
[/TD]
[TD="width: 12%"]
[/TD]
[/TR]
[TR]
[TD="width: 12%"]

23539​

[/TD]
[TD="width: 13%"]

27​

[/TD]
[TD="width: 12%"]
[/TD]
[TD="width: 12%"]
[/TD]
[TD="width: 12%"]
[/TD]
[TD="width: 12%"]

76.9​

[/TD]
[TD="width: 12%"]

77​

[/TD]
[TD="width: 12%"]

0.1​

[/TD]
[/TR]
[TR]
[TD="width: 12%"]

23587​

[/TD]
[TD="width: 13%"]

48​

[/TD]
[TD="width: 12%"]
[/TD]
[TD="width: 12%"]
[/TD]
[TD="width: 12%"]
[/TD]
[TD="width: 12%"]

47.4​

[/TD]
[TD="width: 12%"]

48​

[/TD]
[TD="width: 12%"]

0.6​

[/TD]
[/TR]
[TR]
[TD="width: 12%"]

23639​

[/TD]
[TD="width: 13%"]

52​

[/TD]
[TD="width: 12%"]

127.1​

[/TD]
[TD="width: 12%"]

127​

[/TD]
[TD="width: 12%"]

0.1​

[/TD]
[TD="width: 12%"]
[/TD]
[TD="width: 12%"]
[/TD]
[TD="width: 12%"]
[/TD]
[/TR]
[TR]
[TD="width: 12%"]

23641​

[/TD]
[TD="width: 13%"]

2​

[/TD]
[TD="width: 12%"]
[/TD]
[TD="width: 12%"]
[/TD]
[TD="width: 12%"]
[/TD]
[TD="width: 12%"]

54.4​

[/TD]
[TD="width: 12%"]

54​

[/TD]
[TD="width: 12%"]

-0.4​

[/TD]
[/TR]
[TR]
[TD="width: 12%"]

23790​

[/TD]
[TD="width: 13%"]

149​

[/TD]
[TD="width: 12%"]

150.7​

[/TD]
[TD="width: 12%"]

151​

[/TD]
[TD="width: 12%"]

-0.3​

[/TD]
[TD="width: 12%"]
[/TD]
[TD="width: 12%"]
[/TD]
[TD="width: 12%"]
[/TD]
[/TR]
[TR]
[TD="width: 12%"]

23792​

[/TD]
[TD="width: 13%"]

2​

[/TD]
[TD="width: 12%"]
[/TD]
[TD="width: 12%"]
[/TD]
[TD="width: 12%"]
[/TD]
[TD="width: 12%"]

150.8​

[/TD]
[TD="width: 12%"]

151​

[/TD]
[TD="width: 12%"]

0.2​

[/TD]
[/TR]
[TR]
[TD="width: 12%"]

23907​

[/TD]
[TD="width: 13%"]

115​

[/TD]
[TD="width: 12%"]

116.6​

[/TD]
[TD="width: 12%"]

117​

[/TD]
[TD="width: 12%"]

-0.4​

[/TD]
[TD="width: 12%"]

114.9​

[/TD]
[TD="width: 12%"]

115​

[/TD]
[TD="width: 12%"]

0.1​

[/TD]
[/TR]
[TR]
[TD="width: 12%"]
[/TD]
[TD="width: 13%"]
[/TD]
[TD="width: 12%"]
[/TD]
[TD="width: 12%"]
[/TD]
[TD="width: 12%"]

-1.1​

[/TD]
[TD="width: 12%"]
[/TD]
[TD="width: 12%"]
[/TD]
[TD="width: 12%"]

0.1​

[/TD]
[/TR]
[TR]
[TD="width: 12%"]

Totals​

[/TD]
[TD="width: 13%"]

see ODO>​

[/TD]
[TD="width: 12%"]

703.9​

[/TD]
[TD="width: 12%"]

705​

[/TD]
[TD="width: 12%"]

-1.1​

[/TD]
[TD="width: 12%"]

742​

[/TD]
[TD="width: 12%"]

743​

[/TD]
[TD="width: 12%"]

1.0​

[/TD]
[/TR]
[/TABLE]


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!

 

[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 View attachment 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]

FWIW (not much)

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.