Page 1 of 1

msec timing

Posted: Wed Apr 17, 2019 12:23 pm
by RedDragon
I have assembled a simple 4 digit 1% precision RC meter. I will publish it under GPL soon, but there is something back in the software.
I need to measure time 4 digit precisely in sec and msec range. nanosleep() does not give the required stability, in the fourth digit there is an "instability". I would need something hardware controlled to reach stable msec reading.
Could anyone help me with an idea how to do it with Raspberry?

Re: msec timing

Posted: Wed Apr 17, 2019 1:35 pm
by joan
pigpio will time the difference between two GPIO level changes to the accuracy provided. If by RC you mean Resistance Capacitor timing circuit also see ... pot_cap_py and ... p_charge_c

Re: msec timing

Posted: Wed Apr 17, 2019 3:26 pm
by RedDragon
Thank you Joan for the example and for the idea. I will let you know how does this work in my case.
I also come back with the schematic of the meter. The difference is in the hardware, which is linear by nature of an integrator. It simple for a beginner, easy to assemble (actually work on a breadboard) and hopefuly I can write a useful example program based on pigpio. All this for four digit readings and 1% absolute precision for less than 20 USD. I hope you all will like it. Especially beginners.

Re: msec timing

Posted: Thu Apr 18, 2019 4:40 am
by RedDragon
I evaluated the gpioSetAlertFunc function. The program is very nice and short, but unfortunatelly, the tick reading is flucktuating in the fourth digit independently if I was working in 10 sec or 1 sec range. Do you have any idea how to reach stable four digit?

Re: msec timing

Posted: Thu Apr 18, 2019 6:42 am
by joan
Can you share some code which shows the problem? Some output which shows the problem would also be useful.

Re: msec timing

Posted: Thu Apr 18, 2019 11:38 am
by RedDragon
Hardware is set to 10sec periode. The output:
pi@raspberrypi:~/MyC/Raspberry/source/RCM/1% $ sudo ./RM2 -C -8
9598089 9.880 MOhm
9591959 9.874 MOhm
9590603 9.872 MOhm
9588335 9.870 MOhm
9588270 9.870 MOhm
9588054 9.870 MOhm

9587138 9.869 MOhm
9587929 9.870 MOhm
9586499 9.868 MOhm
9587389 9.869 MOhm
9586649 9.868 MOhm
9588075 9.870 MOhm
9587800 9.870 MOhm
9585634 9.867 MOhm
9587269 9.869 MOhm
9587391 9.869 MOhm
9587815 9.870 MOhm
9587239 9.869 MOhm
^C2019-04-18 13:29:41 sigHandler: Unhandled signal 2, terminating

pi@raspberrypi:~/MyC/Raspberry/source/RCM/1% $ ^C
The colored values are OK, but no mouse move or other interventions. Source is the next with the questionable sorce other parts are getopt and conversion of the float to engineering form. If you need I can put whole source on the net.

Code: Select all

void callback(int gpio, int level, uint32_t tick) {

   char string[21];
   uint32_t RCvalue = 0;
   float Rv;

   if (level == 1) { // 0 -> 1 start back integration 
      if (previous_tick == 0) return;
      RCvalue = tick - previous_tick;
printf("%d\t", RCvalue);
      Rv = (RCvalue/((COMP_MAX/COMP_MIN)*Cv))*1E-6;

      strcat(string, "Ohm");
   if (level == 0) { //start integration 1 -> 0

      previous_tick = tick;


int main(int argc, char **argv) {

   parse_opts(argc, argv);

   if (gpioInitialise()<0) return 1;

   gpioSetMode(GPIO_PIN, PI_INPUT); 

   gpioSetAlertFunc(GPIO_PIN, callback);


   return 0;


Re: msec timing

Posted: Thu Apr 18, 2019 2:28 pm
by joan
You are doing everything right as far as I can tell.

I believe mouse cursor updates now use DMA . pigpio uses DMA to capture the GPIO levels so perhaps the memory bus is getting too congested. I'm afraid I invariably use the Pi headless so it is not something I have experienced.