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?
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!
As Per specificed, the limiting factor here is the width of your signal. I don't think your processor is the problem.
No. We do not think you are right about it. Frisky has looked at the signal and says that it does go up and down all the time so it must be working.
But he thinks that it go down for a short time and he says that an 8 bit processor cannot be fast enough to see it!
So we want to know if we go to the arm am I going to use the code I've done already?
the only thing "not fast enough" is your software! your software is broken, and worse: you don't believe it and do obviousely don't understand how to fix it (even though we told you how) because you probably don't know the specs. do as your told. fix your software. a new controller will have the same problems. I bet you 2 bottles of scotch!