Suggestion from Hans in dealing with analog input pins if/when this capability is added, based on how he does this now with his YellowHat:
Even more important than the sampling rate is the transmission rate. You need to avoid that every small oscillation of the input is sent to the API. So you compare the actual sample value against the moving average and only send an update if deviation is more than a certain threshold. And since this will result in no messages if there is no change, you probably also want a timer based update of the value to the API, say every 30 seconds or so. From a coding point of view, the cost is more on memory than on performance, as you need to store the moving average and the last communicated value of each input, which depending on resolution up to is 4 bytes per input, which adds up quickly on the 328P.
I do it that way on the YellowHat and use the input value, which is then communicated over Loconet, to control the brightness of CTC panels, signals and other light outputs based on settings of a potentiometer or the input from an LDR. Not sure what JMRI would do with the information at this time 😉 but as model railroads become more IoT equipped, it is something users will want to have, I think.
Suggestion from Hans in dealing with analog input pins if/when this capability is added, based on how he does this now with his YellowHat:
Even more important than the sampling rate is the transmission rate. You need to avoid that every small oscillation of the input is sent to the API. So you compare the actual sample value against the moving average and only send an update if deviation is more than a certain threshold. And since this will result in no messages if there is no change, you probably also want a timer based update of the value to the API, say every 30 seconds or so. From a coding point of view, the cost is more on memory than on performance, as you need to store the moving average and the last communicated value of each input, which depending on resolution up to is 4 bytes per input, which adds up quickly on the 328P. I do it that way on the YellowHat and use the input value, which is then communicated over Loconet, to control the brightness of CTC panels, signals and other light outputs based on settings of a potentiometer or the input from an LDR. Not sure what JMRI would do with the information at this time 😉 but as model railroads become more IoT equipped, it is something users will want to have, I think.