I’ve been coaching 449 through some signal integrity issues with their flywheels, and in the process we generated a pretty telling plot re: the default velocity filtering settings on the NEO:
The blue value is a REV through-bore encoder wired to the RIO w/ 1x decoding and 127 samplesToAverage. The red is the reported velocity from the spark max. Notice the substantial signal degradation due to the aggressive smoothing used by the default settings.
You can improve this modestly by changing the filtering settings, but this will come at the cost of noise and can only do so much.
A better solution is to use an external encoder. Please be aware, though, that the REV thru-bore encoder is a very poor choice for an external flywheel encoder with a NEO, since it is too high-resolution for the the alternate encoder pins on the Spark to decode it at high velocity.
Have you found values for the Spark MAX filtering parameters that better balance response time and noise to improve controllability in this low-mass flywheel application?
Maybe? I don’t know what the default settings are for the vortex/flex - it’s conspicuously absent from the current API docs, except for a few undocumented JNI handles. Maybe someone from REV could clarify.
The sensor is higher quality on the vortex, but if the firmware uses the same default settings then it won’t matter unless you change them. Changing the filtering settings for the ordinary NEO is only possible through the hardware client right now, as far as I’m aware, so it might be the same case with the vortex. Pure speculation until REV documents what’s going on.
Was there a recent change that unified handling of external and hall effect encoders in the API? I remember they were separate previously, because the structure of the filter was fundamentally different.
What exactly does average depth do? I understand measurement period but I’m still not fully sure what average depth is. I don’t think it can be how many samples are in a measurement period since either the # of samples or the measurement period must be variable to get a velo reading. What exactly does the average depth do?
Ok after posting this I have another guess. Is it how many measurements it does and averages them? i.e. 4 samples of measurement period time period each, averaged to get velocity?
I doubt this will be a big deal for this year’s game, since only one note can be shot at a time and most teams probably won’t need such tight control over their shooter velocity
If your signal delay is long compared to the system time constant then you cannot do meaningful feedback while remaining stable. If open loop is good enough, then it doesn’t matter.
Those aren’t new parameters though; that’s the api handle for external encoders. I’m confused as to if/when REV unified the filter structure between quadrature encoders and NEO Hall effect sensors.
It might have been during the refactor to support spark flex. I know that hall sensor, alternate encoder, and the Flex “external encoder” all extend SparkRelativeEncoder now.
