speeduino
speeduino copied to clipboard
noisymime
VSS and Flex Init being overwritten by decoder init
Fixed issues where decoder inits disconnect interrupts from previously assigned inputs (VSS and Flex) even if those decoder inputs are not subsequently used. This fix allows assignment of VSS and Flex to existing RPM inputs if they are not used for trigger decoding. Also removed decoderHasSecondary variable which was global but not read anywhere. Tested on the bench and now VSS input can be used with the VR sec input (RPM2) when the trigger wheel is a single crank or cam decoder on RPM1. 2021-07-20_22.00.07_VSSfix.zip
Hey, Just updated this to provide a much more stable VSS reading when using real sensor wheels (possibly homemade) with teeth that aren't perfectly aligned. This code update makes VSS calculate over a whole revolution depending on the speed of the wheel. Also latency is reduced. Works just fine with ECU generated wheel speed signals also.
I'm struggling to see the benefit here of knowing the number of pulses in a revolution. The existing code already samples over a certain number of teeth (4 by default) which should minimise any impact from slightly inaccurate tooth placement.
In my testing, increasing the sample size above 4 doesn't seem to give any improvement in timing accuracy, but does greatly increase the VSS latency, which isn't ideal. Try out the recent changes that were pushed for VSS and see if they work in your setup.
I'm struggling to see the benefit here of knowing the number of pulses in a revolution. The existing code already samples over a certain number of teeth (4 by default) which should minimise any impact from slightly inaccurate tooth placement.
In my testing, increasing the sample size above 4 doesn't seem to give any improvement in timing accuracy, but does greatly increase the VSS latency, which isn't ideal. Try out the recent changes that were pushed for VSS and see if they work in your setup.
The sample size is X teeth, this means the stabiltiy of the speed highly depends on what sort of sensor you are reading and how many teeth it has per rotation.
Just like with crank and cam trigger wheels, a full revolution of the sensor is the most accurate way to determine the speed, this is becase reading the exact same tooth eliminates variation in trigger teeth spacing. In this PR621 code the latency is always at a minimum as the "latest" value is always provided to the read function. There are two possabilties.
- The read function is reading at a rate faster than a full sensor wheel rotation (slow vehicle speed). In this case the speed is calculated off the teeth of a partial rotation, however many teeth since the last read as long as at least minTeeth teeth have been seen.
- The read function is reading a rate slower that a full sensor wheel roation (high vehicle speed). The results of the most recent full roation are provided to the read function.
So I tested this reading off my own wheel tooth sensor which spins off driveshaft speed and uses a VR input. The old code would dither becase it was constantly reading off different teeth which are not evenly spaced because, hey i made it myself! 3% error in tooth spacing is a dither of 6 km/h at 100kmh. After the code changes there is no issue and speed is consistant to 1km/h
While your latest code does improve the latency, you use a lot of memory (4 unsigned longs), where you only need to store the timestamp of the start pulse, the last seen pulse time and a count of the number of pulses in between. The intermediate pulse times are not required becuase the time stamp of the (latest tooth - Start tooth) / number of pulses is the same as the "average of X pulsewidths you have in the array.
The init stuff I added in also is valuble to free up un-used VR inputs. if you like we can split this to just that section to add now and can discuss the revolution based VSS in a later update.
As discussed, reverted VSS wheel rev decoding for now. This PR is now just the init fixes to allow re-use of unused pins.