> > I think it would make sense to unconditionally apply the hysteresis > > to low/high, i.e. always set > > low = low - hyst > > high = high + hyst > > > > so that you get "sticky" ranges once you're in them? > > Yes, maybe that's better, I guess I want to avoid just adding a lag / > delay in reporting changes that are not due to measurement error or > temporary. Could also do something in between, e.g. use "low - hyst" > if signal is close to low, otherwise just "low". That's sort of what you had, but except for the precise definition of "close", no? Actually, no, because you used "last - hyst" rather than "low - hyst" it's different. I think we can live with checking if it's close, say setting to "low - hyst" when it's within low + hyst - that avoids the problem I outlined above and gets a bit more responsiveness, I guess. > The question is how the current hysteresis parameter is defined, what > is expected of the firmware and how do driver authors decide whether > their firmware/hardware implements the same mechanism as expected by > the kernel. Would the same thing happen with firmware > implementations if the hysteresis value is 3 and the rssi fluctuates > by +/- 2? Or would it have to be +/- 3 or +/- 4 before this starts > to happen. (If this isn't well specified then it makes more sense to > try to do it in one place for consistency.) I'm not sure it's well-defined. johannes
