This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Wind speed sensor question

I am using the C51 compiler and have code for the silabs C8051F120.

I have built a wind speed sensor with a rotary encoder but it seems to top out at 42mph. I know there have been gusts greater than that since I started using it.

I have considered calibrating the unit with an automobile and think i may be missing edges of the encoder signal because of processing overhead. I think the encoder counter routine should be interrupt driven.

My coworker Frisky suggested the circuitry is not able to handle fast counting signals coming from sensor and said that the 2nd problem circuitry should be analyzed.

Does anyone have an idea why that might happen?

  • "Does anyone have an idea why that might happen?"

    Why what may happen? Why your software may be too slow? For the same reason that any software may be too slow.

    You must set up your requirements. In this case the shortest interval between two pulses that your solution must be guaranteed to handle. Then you must decide what solutions are available that are able to handle that requirement.

    If you poll an input, you must prove that you are always (worst-case, with trigged interrupts etc) able to poll the input fast enough to not miss a pulse at max supported pulse frequency.

    Or you must count pulses in an interrupt handler, and prove that your interrupt response time is always fast enough.

    Or you must see if your hardware has any counter/timer that may count the pulses directly in hardware, so you only have to sample the counter at regular intervals.

  • I think the clock is going at 50MHZ and the pulses are going at about 18 to 22MS so i cannot see how the code can miss them.

    Give me your email address and I will send you the code. I want you to see it is right.

  • freyed,
    * have you tested your interrupt latency? you can measure it either with a scope or using a hardware timer that once rolls-over, generaes an interrupt. sum up the value of the hardware timer in the ISR (remember: it keeps ticking while waiting to invoke the software handler...), divide by the number of interrupts and there you have the average latency.
    * testing if you miss edges is possible like this:
    Start a hardware timer at 0xFFFF counting up, so if an interrupt is generated upon roll-over, the ISR should reset it to 0xFFFF. If an interrupt is missed - your counter will have a value bigger than 0.

    Kind regards,
    Tamir Michael

  • here is my code;

    void main ( void )
    {
      float pulse;                 // number of ticks for pulse
    
      while ( 1 != 2 ) {           // until the law changes
        pulse = 0.0;               // reset the variable
    
        while ( IP == 0 )          // while the input is at the level
          pulse = pulse + 1;       // increment the variable
    
        printf("pulse is %f ticks\n",pulse);
      }
    }
    

  • freyed,
    This code cannot possibly give a correct result as all circumstances. If you processor does other things except polling the input, you may lose signals!
    Make it interrupt driven or make a fully deterministic main loop.

  • Broken code!

    First off: Don't use any floating point numbers to count integers. It takes time and makes the code big.

    Second, you should be looking for a transition from one state to another, either low-to-high or high-to-low depending on polarity of the pulse. Your code do not look for such a transition. It counts time in one state. You may count the same pulse multiple times.

    When polling, you must compare the current pin state with the previous.

    However, the above can not be your code, since it does not read any wind speed, only the total number of pulses. Real code must count number of pulses for a specific time interval. Always post the real code if you want help!

    Another thing: Are the pulses really of fixed length? If using an opto-coupler or a mechanical switch, the pulse length will vary with the rotation speed. If you have electronics that shapes the pulse to a fixed length, then you automatically get a limit to the number of pulses you can process in a second. A pulse length of 22ms means that it isn't possible to receive more than 45 pulses/second. At higher pulse speed, the pulses will float together in a continuous signal.

  • hello?

    the lower frequency the bigger the time section of the gap seen,
    and the higher frequency the smaller time section of the gap required.
    Not only time section of the signal related with frequency, turns/second also related with
    the frequency.

    mkarim

  • Karim,
    And the punch line is?

    What do you want to say, actually? Please clarify.

  • The gap is expected to change with changing wind speed, since the time distance between the pulses will change.

    My question was: Do you have electronics that gives a fixed length of the pulse (not distance between pulses) or does the length of the pulse vary with the wind speed?

    If the pulse length is constant at around 22ms, you can never process more than 45 pulses/second before the gap will become zero.

  • Yes. I will try to explain the operation to you and how the code works.

    The electronics gives pulses from the speed sensor.

    The code first zerofies a variable and keeps adding one to it until the pulse is finished. The theory is that the variable will be bigger if the pulse is longer in time.

    I calculate the reciprocal of the count and this indicates the speed of the pulse. I did not put this into the code before because I didnt want to confuse you but it is like this;

    
      the_speed = 1/pulse;
    
    

    I use float because this calcualtion will not give an integer. Integers do not have any decimal point.

    I hope you now understand.

  • Integers do not have any decimal point.

    Integers do have a decimal point - it's up to the programmer to define where it is. That's called fixed point arithmetics.

  • So instead of counting # of pulses within a time interval, you are trying to integrate the average voltage, i.e. the quota between pulse high and pulse low.

    Any reason for this - in my view - more comples job? Note that every interrupt will loose you some time in your polling loop, thereby reducing the precision. Also, your counter are not guaranteeed to be able to take any value between 0 and "100%". The span are greatly affected by the pulse length, i.e. if the pulse length is fixed or is proportional to the pulse frequency.

    If you use interrupts - or a timer/counter - you must guarantee that the pulses are bounce-free.

    Another thing. You are counting # of samples at one level. The number of loop interations is an integer, so the number of high or low detections must also be integers. It isn't until you perform the division that you have to switch to floating point, or to perform fixed-point arithmetic.

  • Yes. The decimal point is always on the right and has no value.

    Its pointless ...... hahaha .... geddit???

  • To be precise:

    Mathematically speaking, integers do not have any radix point (decimal point in base ten).

    However, in software, an integral type can be used to represent a non-integer value by using a fixed-point approach.

  • This is getting too complicated.

    My brain is hurting.

    I think I give it up now.

    Does any one want some code ..... going cheap.