Odometer - New here so may have been covered previously

[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?

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?

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

I think that we cab all agree that a computer can pretty much count in it's sleep...
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?

[Gray Ghost]

I think that we cab all agree that a computer can pretty much count in it's sleep...
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?

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!

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

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

[Bob Denman]

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

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

Originally Posted by Gray Ghost

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!

[missouriboy]

Please!!!!

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

[PrairieSpyder]

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

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!

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

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

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

Hey, I hear ya!
And how about WORK? Isn't that a four-letter word too?

[Bob Denman]

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

[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 ImageUploadedByTapatalk1413004423.568285.jpg going out for daily ride. Hope there is no error!


Sent from my iPhone using Tapatalk

[StanProff]

Patti...
I have no idea what you just said...
But it sure sounds good!
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".

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

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