mdumdei wrote: ↑
Dec 30 2020 7:14pm
casainho wrote: ↑
Dec 30 2020 11:57am
mdumdei wrote: ↑
Dec 29 2020 10:10pm
I've got a strange problem I can't figure out. My 850C display went out on me and so I updated to an 860C. At the same time, I went from 1.00 to 1.10 on the opensource software. I have a 29 bike with larger tires and setting the circumference to 2410 had me sync'd with my GPS perfectly with the 850C. I put that same number in under the 860C / 1.10 setup and I'm constantly showing about 85% of actual distance no matter what I put in for wheel circumference. I moved it to 2800 since that was what it calculated out to, but was still off by the exact same percentage as when I had it at 2410. I looked in the source and saw 2100 is the default which calcs out to about what I'm seeing (2100/2410 = .87). It looks like it is not using the number in the UI and always using the default. Also dug through the source for both 1.00 and 1.10 and saw nothing that would appear to cause that. The trip stuff is in 1.10, but it doesn't look like it handles retrieval of the settings from the eeprom or the moving of the wheel_perimeter value any differently than 1.00. If no one has any suggestions, I'm going to revert to 1.00 and see if that resolves it (in case I missed something). Going to blame the 860C if that doesn't change anything. FYI: I've been running on various renditions for the last 8,000 km and it just works - good stuff.
Maybe you can try to change the sources for you specific value and see if it works...
This issue is strange since no one reported it before but everyone used it!!
Did that, but it's been raining too much to check it out. Thought about just trying the 'Reset to Defaults' to and reconfiguring to see if that shook it loose. Going to try the version compiled with the new perimeter default first though.
I did some more looking into the code and saw the odometer calc was done like it was in 1.0.0 so checked the distance on the odometer vs. the trip meter. I found the odometer gave a correct value but the trip meter was short. I'm still working out the logic of the trip code, but I'm wondering if it isn't cutting off precision at these lines in "state.c" around line 517:
// update all trip distance variables
rt_vars.ui32_trip_a_distance_x1000 += (ui32_temp / 1000);
rt_vars.ui32_trip_b_distance_x1000 += (ui32_temp / 1000);
ui32_temp is wheel_ticks * perimeter. For a wheel that is close to a multiple of 1000 mm, the error wouldn't be much. For a wheel about out in the middle like mine at 2410, the error would be larger and more noticeable. 'wheel_ticks' in the new code is right above that and is:
// calculate how many revolutions since last reset ...
uint32_t wheel_ticks = rt_vars.ui32_wheel_speed_sensor_tick_counter
// ... and convert to distance traveled
uint32_t ui32_temp = wheel_ticks * ((uint32_t) rt_vars.ui16_wheel_perimeter);
Looks unscaled to me at first glance and running integer math on it is going to drop trailing digits. The flaw in that logic is I see the var is named 'x1000' which would indicate it is scaled. Posting this in case someone has some insight and could save me some time. I'm going to attempt to resolve it myself, but not being familiar with the code, it may take a while. I "think" something is wrong though since on my bike the trip meter runs about 85% of the distance shown on the odometer. Anyone else seeing a discrepancy between the trip meters and the change in odometer value?