Hello,
Is there a way to reduce conversion time in Compact by reducing the resoultion of the ADC MCP3550-50 to achieve higher effective sampling rate of the 8 RDT inputs? I do not need such high resolution, but would greatly benefit if i got the values faster.
So far I have been able to sample a single channel via piControl ( I modified the source and rebuilt the kernel obejct) with max 8 Hz, but naturally this reduces to 1 Hz when all the inputs are enabled.
Thanks for your replay, time and care!
Higher sampling rate in Compact
Re: Higher sampling rate in Compact
I'm afraid that's pretty much as good as it gets.
Per the spec, the MCP3550-50 requires 83.00625 msec for a readout (80 msec + 2% max deviation and 144 clock periods to exit shutdown, so 80000 * 1.02 + 144000 / 102.4). The chip doesn't allow decreasing the resolution to reduce conversion time. There's an alternative version of the chip, the MCP3553, which needs just 16.670 msec for a readout, but has worse noise characteristics. We opted for the slower, but more precise variant.
The remainder of the 125 msec cycle time (about 40 msec) is allocated for switching the mux and (if temperature is measured) turning the power source on/off. That's fairly generous and if you're not using the power source, could probably be reduced a little. piControl computes the cycle time by dividing 1 sec by number of active channels.
If you always read out the same input channel (so that the mux is never switched), changing the algorithm to allocate 85 msec for a readout might be safe. That would give you a bit more than 11 Hz. If you do use multiple channels but never turn the power source on or off, maybe 100 msec could be achieved, so that's 10 Hz.
Not a big improvement compared to the 8 Hz you've already got, but that's all I can offer, sorry.
Per the spec, the MCP3550-50 requires 83.00625 msec for a readout (80 msec + 2% max deviation and 144 clock periods to exit shutdown, so 80000 * 1.02 + 144000 / 102.4). The chip doesn't allow decreasing the resolution to reduce conversion time. There's an alternative version of the chip, the MCP3553, which needs just 16.670 msec for a readout, but has worse noise characteristics. We opted for the slower, but more precise variant.
The remainder of the 125 msec cycle time (about 40 msec) is allocated for switching the mux and (if temperature is measured) turning the power source on/off. That's fairly generous and if you're not using the power source, could probably be reduced a little. piControl computes the cycle time by dividing 1 sec by number of active channels.
If you always read out the same input channel (so that the mux is never switched), changing the algorithm to allocate 85 msec for a readout might be safe. That would give you a bit more than 11 Hz. If you do use multiple channels but never turn the power source on or off, maybe 100 msec could be achieved, so that's 10 Hz.
Not a big improvement compared to the 8 Hz you've already got, but that's all I can offer, sorry.
