FreqMeasureMulti library update with extended functionality

Status
Not open for further replies.

Theremingenieur

Senior Member+
In a project, I'm currently getting several signals from 7555 timers and from D-flipflop based phase discriminators. The FreqMeasureMulti library helped me tracking the input frequencies from the timers which all vary between ca. 1kHz and ca. 4kHz. But it was useless for the phase discriminators since the frequency would not vary, just the duty cycle (the high time to full period time ratio). Then I found that since with that library, I'd only get a new value each time when a full signal period was accomplished, that means each time a rising ramp occurred, I'd get the time since the previous raising ramp. But if I had also the time between two falling ramps interleaved, I'd get the double actualization rate and thus could better track slow variations in the input frequency.

Time to extend the FreqMeasureMulti library... :) Not only for my specific purposes, but to allow everybody a much more detailed analysis of signal timing:

Extended in v0.22 :
As in the v0.1, an instance can be started with begin(pin). More capture modes are available through begin(pin, mode) by using the following constants for mode as follows :
  • FREQMEASUREMULTI_RAISING -> A new value becomes available at each rising ramp and contains the time since the previous rising ramp (default value when mode is not given in begin(pin))
  • FREQMEASUREMULTI_FALLING -> A new value becomes available at each falling ramp and contains the time since the previous falling ramp.
  • FREQMEASUREMULTI_INTERLEAVE -> A new value becomes available at each rising and each falling ramp and contains the time since the previous similar (rising or falling) ramp. That virtually doubles the actualization rate and allows quicker tracking of variations in the signal frequency.
  • FREQMEASUREMULTI_SPACE_ONLY -> A new value becomes available at each rising ramp and contains the time since the previous falling ramp. Thus, only the "low time" of the signal period is returned
  • FREQMEASUREMULTI_MARK_ONLY -> A new value becomes available at each falling ramp and contains the time since the previous rising ramp. Thus, only the "high time" of the signal period is returned
  • FREQMEASUREMULTI_ALTERNATE -> A new value becomes available at each rising and each falling ramp and contains the time since the previous ramp. Thus, the high and the low time of the signal period are returned alternating.

Since depending on the selected capture mode it is not always clear which part of the signal has just been measured, extended information can additionally be obtained with the function readLevel() after invoking read().
Possible return values are:
  • LEVEL_SPACE_ONLY (binary 0b00) -> the read() value contains only the duration of the "low time"
  • LEVEL_SPACE_MARK (binary 0b01) -> the read() value contains the duration of a full signal period, starting with "low" and followed by "high"
  • LEVEL_MARK_SPACE (binary 0b10) -> the read() value contains the duration of a full signal period, starting with "high" and followed by "low" (default when mode is not given in begin(pin))
  • LEVEL_MARK_ONLY (binary 0b11) -> the read() value contains only the duration of the "high time"

Finally, since not everything is about frequency but sometimes about time, a class member function countToNanoseconds(uint32_t count) has been added, similar to countToFrequency(uint32_t count), but it does return the corresponding time in nanoseconds.

Testers can find it here : https://github.com/universpharmacie/FreqMeasureMulti

Pull request will be done
 
Last edited:
Status
Not open for further replies.
Back
Top