## Tuesday, November 1, 2011

### Wind vane microcontroller code

Here is the code now used to calculate the measured apparent wind angle in this system.

The analog-to-digital code makes use of the files ‘adc.h’ and ‘adc.c’ found in this BDMICRO sample code. These 2 files shall be included in the project and be part of the compilation.

//...
//...

#define PI 3.14159265
#define RAD_TO_DEG ((double) (180.0/PI))

double awa_measured;

// Wind vane calibration data
double wcx[2];
double wcy[2];
double xc;
double yc;
uint16_t green, blue;

int main(void)
{
// ...

xc = 741.2638;
yc = 744.6921;
wcx[0] = 1.002073;
wcx[1] = -0.006924865;
wcy[0] = -0.006924865;
wcy[1] = 1.023132;

/* initialize A/D Converter */

for(;;)
{
// begin a new cycle
// ...

green = adc_readn(0, 10);  /* sample channel #0 10 times, take average */
blue = adc_readn(1, 10);   /* sample channel #1 10 times, take average */

double dgreen = ((double)green) - xc;
double dblue = ((double)blue) - yc;
double xmap = wcx[0] * dgreen + wcx[1] * dblue;
double ymap = wcy[0] * dgreen + wcy[1] * dblue;

awa_measured = atan2(ymap, xmap) * RAD_TO_DEG;

// ...

// Wait for timer signal to begin a new cycle

// ...
}
}

1. Nice going Merlin, can't wait to see the final results!
Maybe start a project like arduino for the instruments system? Open Software and Hardware?

Is there a small accuracy problem with first doing 10 samples of the green signal and then 10 samples of the blue one? How much time is between them?

2. Erik, the sampling time for 10 ADC conversions is exactly 1.04 ms. The delay between the green and the blue conversions is negligible compared to that. So the whole sampling time for a pair of green/blue values is around 2.1 ms. I think that it is preferable to take several measurements to cancel the noise over a relatively longer time rather than to rely on a single measurement over a shorter period. Because I use a 10 Hz refresh rate, this 2.1 ms is taken from the 100 ms budget available for each cycle.

But the major cause of error comes probably from the lack of repeatability of the value of the signals for the same position of the vane, depending on the previous movement, the tolerances of the mechanical and electromechanical linkages inside the vane, etc. This is apparent when looking at the ellipse, where we can see some parallel lines. This is why I rotated the vane both clockwise and counterclockwise while taking the measurements, to get a representative average.

I like to play with my Arduino Uno and I appreciate many things in this environment: rapid prototyping, extensive libraries, C++, etc. But I prefer to develop in the WinAVR environment where I have a complete control over the timing and optimization issues. I can examine the assembler code produced by the compiler, and even mix my own assembler code if required.

My high-resolution compass would be a good candidate for an Arduino-based Open Software and Hardware project. I had a hard time finding a suitable 3.3 V microprocessor. This was before Sparkfun announced the Mega Pro Mini 3.3 V (http://www.sparkfun.com/products/10743) . But it is still 3 times the price of the one that I am currently using (found on eBay, search Atmega 128A).

3. Well, no need to use the Arduino IDE, just an "arduino" like board programmed with WinAVR is fine. Key elements are performance and reliability.
Have you thought about NMEA 2000 support, some development board support a CAN bus.

Other considerations, add some fuses for all external parts, for instance our B&G displays had a 12 volt short, but the main computer just blew a fuse.

4. With NMEA 2000, it could not be an open source project. I know how to do it, but I could not publish the code. The best approach would be to provide for a very fast NMEA 0183 output, and use a third-party converter (existing or to be developed if required) to connect to the N2K network.

I fully agree with fused protection (which I have), and for voltage inversion protection (which I don't have, but I use keyed connectors to prevent it).