Generating sin/cos voltages for driving VDO wind instrument

[Lomax]

Hi all,

I would like to repurpose an analogue VDO wind direction gauge by feeding it analogue sine/cosine voltages from a dual channel DAC, but since I do not have the corresponding masthead unit ($$$) I can't measure what the voltage swing should be. I think the supply to the masthead unit should be 10V & GND, which suggests a 0-10V swing, but I'm not sure. Does anyone know?

[hlev00]

Raymarine is 8V at the instrument.

Attached should be Raymarine document - Wind Vane, Document number: 83170-1 or similar.

[Lomax]

Originally Posted by hlev00

Raymarine is 8V at the instrument.

According to this it's 2-6V. The VDO instrument may be different though. I guess I could do some tests to find at which voltages it starts to move.

[Lomax]

Knocked out a quick & dirty simulation, as a proof of concept. It's using a rotary encoder to generate a changing wind direction:



This outputs two 0-5V voltages which represent the sine and cosine of the input angle. The jaggedness of the curves is due to uneven rotation of the encoder - not easy to do evenly with the mouse... Rather than using a dedicated DAC, this simple circuit uses R/C filters to turn the PWM outputs into DC voltages. I reckon it will be good enough. The next step will be to listen to NMEA 0183 wind messages on the serial port, and extract the wind direction from these.

[bdbcat]

Lomax...
I did this some years back (ouch, must be 25 years!) to drive classic Brooks and Gatehouse analog wind displays from a commercial grade wind sensor.


https://novalynx.com/manuals/qm-2106-manual.pdf


Sensor is long out of production.


Showing my years now, but IIRC I used an 8051 with an external two channel 10 bit DAC. Used a pre-calculated lookup table of sin/cos to avoid floating point math. Worked fine with 5V swing.


And still working fine, btw. One of the few instruments aboard that has been continuously operating for 25 years, 24x7, on the same boat.


Good Luck
Dave

[Lomax]

Originally Posted by bdbcat

Lomax...
I did this some years back (ouch, must be 25 years!) to drive classic Brooks and Gatehouse analog wind displays from a commercial grade wind sensor.


https://novalynx.com/manuals/qm-2106-manual.pdf


Sensor is long out of production.


Showing my years now, but IIRC I used an 8051 with an external two channel 10 bit DAC. Used a pre-calculated lookup table of sin/cos to avoid floating point math. Worked fine with 5V swing.


And still working fine, btw. One of the few instruments aboard that has been continuously operating for 25 years, 24x7, on the same boat.


Good Luck
Dave

Sweet - perhaps I'm not crazy after all


Floating point math is not as heavy for a little MCU as it used to be; even the humble ATMega328 runs circles around an i8051. I'm even underclocking it to "just" 2MHz in this example...

[Lomax]

Originally Posted by bdbcat

Used a pre-calculated lookup table of sin/cos to avoid floating point math.

I checked how many clock cycles are used by the AVR to do the necessary calculations:


radian = angle * (M_PI / 180.0);

227

sine = (sin(radian) + 1) * 127;

2086

cosine = (cos(radian) + 1) * 127;

2005

That's a total of 4318 clock cycles spent calculating the sin/cos values. While this might seem excessive, at 2 MHz the AVR could perform these calculations 463 times per second (provided it did nothing else). Or in other words, with a 1 Hz update rate these calculations use less than 0.25% of the available time on a 2 MHz AVR. Unless I've misunderstood something?

[Be Free]

Originally Posted by bdbcat

Lomax...
Showing my years now, but IIRC I used an 8051 with an external two channel 10 bit DAC. Used a pre-calculated lookup table of sin/cos to avoid floating point math. Worked fine with 5V swing.

That was when programming was fun! There was no way you could afford to waste thousands of machine cycles recalculating something that could be looked up in a few dozen cycles. When you are running a processor that runs in the single digit MHz range every cycle counts!

Congratulations on still having it running after all this time. That's some solid hardware and great programming.

[Lomax]

Originally Posted by Be Free

That was when programming was fun! There was no way you could afford to waste thousands of machine cycles recalculating something that could be looked up in a few dozen cycles. When you are running a processor that runs in the single digit MHz range every cycle counts.

While I completely agree that limitations can make programming more fun, I fail to see what's wrong with using cycles that would otherwise be spent doing nothing. An ATMega328 draws about 5 mA at 2 MHz and 5 V, regardless of whether it's sitting there doing nothing or constantly performing some calculation (peripherals not included). If you're running it off a coin cell or something you could idle it I suppose, and only wake it up on USART interrupts, but a 0.025 W power saving is irrelevant for my application - and even then doing the calculations would only keep it awake for an extra 0.002 seconds. Given there's time for it I think calculating the actual value is more elegant than using a look-up table, which feels like a hack. Neat when you have to use it, but a hack.

[team karst]

Originally Posted by bdbcat

Lomax...
I did this some years back (ouch, must be 25 years!) to drive classic Brooks and Gatehouse analog wind displays from a commercial grade wind sensor.


https://novalynx.com/manuals/qm-2106-manual.pdf


Sensor is long out of production.


Showing my years now, but IIRC I used an 8051 with an external two channel 10 bit DAC. Used a pre-calculated lookup table of sin/cos to avoid floating point math. Worked fine with 5V swing.


And still working fine, btw. One of the few instruments aboard that has been continuously operating for 25 years, 24x7, on the same boat.


Good Luck
Dave

Ah yes. Syncros and resolvers. Wasnt burr-brown good with that hardware? Usefully for aiming turrets on battleships too. [emoji15]

[AKA-None]

Originally Posted by Lomax

While I completely agree that limitations can make programming more fun, I fail to see what's wrong with using cycles that would otherwise be spent doing nothing. An ATMega328 draws about 5 mA at 2 MHz and 5 V, regardless of whether it's sitting there doing nothing or constantly performing some calculation (peripherals not included). If you're running it off a coin cell or something you could idle it I suppose, and only wake it up on USART interrupts, but a 0.025 W power saving is irrelevant for my application - and even then doing the calculations would only keep it awake for an extra 0.002 seconds. Given there's time for it I think calculating the actual value is more elegant than using a look-up table, which feels like a hack. Neat when you have to use it, but a hack.

Personally looking up a constant vs recalculating wouldn’t be a hack in my book
It would be efficient particularly for such a small dataset

[dfelsent]

I recall lookups and linear interpolation was also a common approach for this.

[Be Free]

Originally Posted by Lomax

While I completely agree that limitations can make programming more fun, I fail to see what's wrong with using cycles that would otherwise be spent doing nothing. An ATMega328 draws about 5 mA at 2 MHz and 5 V, regardless of whether it's sitting there doing nothing or constantly performing some calculation (peripherals not included). If you're running it off a coin cell or something you could idle it I suppose, and only wake it up on USART interrupts, but a 0.025 W power saving is irrelevant for my application - and even then doing the calculations would only keep it awake for an extra 0.002 seconds. Given there's time for it I think calculating the actual value is more elegant than using a look-up table, which feels like a hack. Neat when you have to use it, but a hack.

The first machine I programmed had a blazing 800 Hz clock speed and a whole 2K of magnetic core memory. That's an example of when you have to be efficient.

I never said it was wrong to use cycles (going to waste or not). I just observed that I found it to be more fun to do it more efficiently. You'll get no argument from me if you want to do it differently.

However, if pushed, I might observe that the values from the instrument are not usually changing significantly over the span of seconds (and certainly not multiple times a second). Recalculating what is (for all practical purposes) the same values over and over again regardless of the existence of a plethora of unused machine cycles brings to mind images of "spinning one's wheels" or perhaps the reinvention of the same.

If you insist on doing the calculations at least check first to see if the input has changed enough to make the calculation worthwhile. The comparison and branch will still use magnitudes fewer cycles than calculating the trig functions. The fastest code is always the code you don't execute.

Please take this in the spirit it is offered, with my tongue firmly planted in my cheek!