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?
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.
So change it to a calculation that will give an integer!
eg, if
would give the speed in m/s, just change it to
the_speed = 1000/pulse;
to give the speed in mm/s - simple!
the "wind speed sensor" is the very same as a tachometer. Tachometer design is a well known excersize and there are basically two methods a) number of pulses in a given time b) time between two pulses
both are "basic timer coding"
Erik
But it is actually a bit innovative to get a digital processor to simulate the analog method of having an RC filter and reading the analog average of the pulsed signal :)
Frisky has told me that the hardware is good. but he thinks that the processor cant keep up with it so he thinks we need to upgrade to something faster# maybe an arm.
So i now need to know if i can move my code to the new one.
Anyone got any good ideas?
but he thinks that the processor cant keep up with it so he thinks we need to upgrade to something faster# maybe an arm.<p>
Well, I think you merely need to upgrade/debug your program.
Switching to an ARM won't help you if your program has fundamental flaws in it.
Frisky is a wise man. He wants more computing power to crunch numbers! I like that! yammi! But I am afraid that you'd have to apply the above recommendations first, and above all: to understand the source of your current difficulties!