I'm reading a wind vane sensor during 2.5 seconds. As you can imagine during this 2 seconds the vane moves several degrees because the wind direction is not linear moves some degrees.
I did these code to read the sensor value during 50 readings, then I do the average and the result is a number. But there is a problem
Imagine the compass, North is sensor Value from 810 to 820, North East from 520 to 530, East from 190 to 199...etc
I could not apply my code because the sensor values are not continous, so I could not do the average because the result has no sense
The Solution that I want to implement but I don't know how to do it. The compass is like a Clock, where north is 12, North east is 1, East 3, South East 5, south 6, south west 7, west 9 andnorth west 11.
The code that did not work as I explained before
direction = 0;
int wdirection = 0;
int windVanereadings = 50;
for ( int i = 0 ; i < windVanereadings ; i++ ) {
direction += analogRead(4); //V1 A1
if (direction >= 190 && direction < 199) //EAST
wdirection = 3 ;
else if (direction >= 270 && direction < 280)//SSE
wdirection = 5;
else if (direction >= 360 && direction < 375) //SOUTH
wdirection = 6;
else if (direction >= 515 && direction < 540) //NNE
wdirection = 1;
else if (direction >= 670 && direction < 685)//SSW
wdirection = 7;
else if (direction >= 810 && direction < 830) //NORTH
wdirection = 12;
else if (direction >= 960 && direction < 975) //WEST
wdirection = 9;
else if (direction >= 905 && direction < 920) //NNW
wdirection = 11;
else
wdirection = 0;
Serial.print(wdirection);
delay(50);
}
direction /= windVanereadings;
And if somebody could help to me I really appreciate
The values are different because the sensors returns me these values, if the values were from 0 to 360 could be easier, but the sensor value are absolutely crazy.
The idea is reduce the values from each vector to one like a clock...if I did not do that and Imagine the vane moves from south to North the average sensor value is out of the range and I could not to represent it
See attached the pdf of the wind vane, but the results are not the same that the tale shows, because depending on the model of the arduino it changes, but you can see the different values for each vector
ecabanas:
Arduino did not returns voltage, the way to read this sensor is Via Analogread() and returns values never voltage
I'm not sure what you mean... analogRead() returns indeed a value between 0 and 1023... and they are not random values... (assuming you wired things right) ??
J-M-L:
I'm not sure what you mean... analogRead() returns indeed a value between 0 and 1023... and they are not random values... (assuming you wired things right) ??
You should be able to get 16 positions
Hi,
The values are not random, for example if the vane is pointing north the values are from 810 to 830, but if we follow the logical compass North East has values from 515 and 540..East from 190 to 199
During the reading time the vane could move from north to East (because the wind direction is not straight). Imagine we have Only two readings:
1- Pointing pure North: 810
2- Pointing pure East: 190
The average returns (810+190)/2= 500 but 500 is not any value
what I'm looking for associate the sensor value range to a "clock value"
In the example:
1- Pointing pure North: 810 = 0
2- Pointing pure East: 190 = 3
Result (Imagining a compass like a clock) (0+3)/2=1,5 = North East
The example values provided by the OP with regard to what is returned with the vane pointing in various directions are all dependant on how the detector is oriented.
I would have thought it possible by orienting the base correctly, for example, to arrange that with the vane pointing North the value would be 0, West 255, South 512 and East 765 or thereabouts. East/West values may be the wrong way round but the principle is sound I think.
ChrisTenone:
Wow - that is wild data! If you plot it - volts vs angle - it's kind of a jaggy sine curve:
there is no rationale in drawing lines in between the points. This is not a continuous function because the way the system works ---> You deliver through the activation of physical switches and resistors a specific resistance (thus voltage) for a given interval of positions of the wind vane
if you were to draw the Angle° in X and the Voltage in Y, you would have 16 horizontal lines, and because of then quality of the ADC, those lines would be quite "thick" to represent a "hit"
The Vane is marked with the north, south east and west marks and is not possible to move it or turn it....my question is when the analog read has a value, map them to 1, 3, 5, 6,7,9,11 or 0
ecabanas:
During the reading time the vane could move from north to East (because the wind direction is not straight). Imagine we have Only two readings:
1- Pointing pure North: 810
2- Pointing pure East: 190
The average returns (810+190)/2= 500 but 500 is not any value
Your problem is defining what "average" means if your wind can be pure North for half of the reading period and pure East for the other half... trying to say the wind is North East is an alternate truth...
you probably need to extract the max of how long you stayed in a given position during a certain period of time and that's the dominant wind for that period. Your device delivers 16 positions, so have a array with 16 entries, make 255 readings (if your array is in bytes), adding one in the right array entry each time and then look at the entry with the highest count.
you could also look at distribution or standard deviation etc to gain a bit more confidence in what you extract
Note that given the values you want to measures, having a high quality 5V analog reference is going to be key (or change the value of R to fit in the range and use the built in analog ref)
I also attempted what you are attempting, averaging the compass direction over a time period. In my case the averaging period was 15 minutes and the sample rate was every 20ms, I think.
The code I wrote contained a bug that I was never able to find or fix. The results were random and unpredictable. I suspected overflow errors at first, but changing all the variables to long etc. did not fix it.
I think part of the problem is that the vane is not a great quality instrument. It does not perform well in less than ideal mounting locations, where a smooth airflow is not guaranteed. It swings about too freely.
In the end, I opted for a simpler solution. I read the vane's instantaneous direction (i.e. which one of 16 compass directions it can resolve) each time there was a rising or falling edge from the anemometer (4 edges per revolution). I maintain a count of the number of times each direction is seen over the 15 mins period. At the end of the 15 mins, I find the direction with the highest number of counts, and record that as the wind direction over the period.
The idea of reading the vane only on anemometer edges was to save battery power during calm periods. I'm not sure it makes any difference to the battery life in practice.
Here is my code if you are interested. It runs on an attiny85 which communicates to the main "Arduino" (actually a Wemos Mini Pro) via serial.
J-M-L:
Note that given the values you want to measures, having a high quality 5V analog reference is going to be key (or change the value of R to fit in the range and use the built in analog ref)
Why does that matter? By default, analogRead() uses the Arduino supply voltage as its reference. If you use that same supply for the voltage divider (half of which is the vane), as I do and I think the OP does, then the exact supply voltage becomes irrelevant.
Whatever the supply voltage, the analogRead() result (0..1023) for each of the 16 directions will always be the same (except of course for analog noise). In my code (see link in last post) I calculate the analogRead() values half way between each predicted readings (based on the nominal values of the voltage divider resistors), and use those to determine which of the 16 directions the vane is pointing, thereby avoiding the analog noise issue.
PaulRB:
Why does that matter? By default, analogRead() uses the Arduino supply voltage as its reference. If you use that same supply for the voltage divider (half of which is the vane), as I do and I think the OP does, then the exact supply voltage is irrelevant.
couple points:
1/ variation of Vin:
if voltage does vary — if you have a crappy power supply (even USB varies with a +/- 5% tolerance) you can't compare 2 results
Measurea would be Vina x (Rvanea / (R1 + Rvanea ))
Measureb would be Vinb x (Rvaneb / (R1 + Rvaneb))
if Vina and Vinb are the same, then I agree you do measure changes in R vane but if the input voltage did change "enough" then you don't really know if that was R vane which changed or just Vin
and Powering by Vin or the jack with a poor quality 9V for example will give you a nice 5V at the analogRef as you get this after going through the power regulator circuit but then you power the Vane with the shaky 9V and so you math could be off.
2/ depends on your arduino
A USB-powered Arduino Nano will have an ADC voltage reference which can't be relied on, due to the MBR0520 Schottky diode that will drop between 0.1 and 0.5 V depending on its own manufacturing tolerances, its temperature, and the current draw of your board
--> my point was more to ensure you have quality both for the reference being used and across measures.
I did not word my reply #16 precisely enough. When I said "Arduino supply voltage" I did not mean Vin or Vusb. I meant Vcc of the ATmega chip, which is connected to the 5V pin on most Arduino, e.g. Uno/Nano. That is the default reference voltage for analog pins, I believe. Using that voltage to drive the voltage divider avoids the pitfalls you pointed out, correct?
Reading back through the thread, I have no evidence that the OP has used the Vcc/5V voltage to drive the voltage divider. I know that's what I did but I have assumed the OP did also without any evidence.
I did not word my reply #16 precisely enough. When I said "Arduino supply voltage" I did not mean Vin or Vusb. I meant Vcc of the ATmega chip, which is connected to the 5V pin on most Arduino, e.g. Uno/Nano. That is the default reference voltage for analog pins, I believe. Using that voltage to drive the voltage divider avoids the pitfalls you pointed out, correct?
No need to apologize, it's a discussion and you have good points
On a nano you would still have a pitfall if you power through USB as Vcc will be 5v indeed but due to the unpredictable behavior of the diode, the ADC does not see the same value - and that drives a bias.
