How to connect a Moving coil gauge

[Kaellis991]

My knowledge of these things is very limited. I’m still trying to crawl yet.
I know the idea behind PWM and I know what DAC means.
Aren’t the Arduino digital pins that are marked with a tilde the DACs? Wouldn’t I be using one of those to connect to the EGT gauge?
I still haven’t yet learned how the software works with respect to setting the frequency and calibrating the meter.
Those will be the next questions I have for the LUA code experts.

This is from a web page I found on modifying a moving coil meter to work with Arduino PWM output.
It leaves out a lot of information that I would need.

[jph]

My knowledge of these things is very limited

Luckily, mine is not. It is very extensive.

ALL you have to do is output a value between 0 and 1 to the hw_output_pwm_duty_cycle (once you have setup the arduino and told AM the pin it is wired to etc) corresponding to 0 to 100% PWM at a frequency of 1KHz with will give you a varying voltage from 0v to 5v in proportion where 0 = 0v and 1 = 5v.
That will drive your gauge from full left to full right and anywhere in between in a linear manner. It really cannot get much easier.
You can experiment all you like with the code now as you cannot damage the meter. You don't have to do or add anything for the hardware now apart from a wire to Arduino GND and a wire to a suitable Arduino HW PWM I/O as can be found on the Hardware specifications on AM. - look down the list for your board and for a pin that supports PWM output as listed https://siminnovations.com/wiki/index.p ... re_id_list

Start here -
https://siminnovations.com/wiki/index.p ... ut_pwm_add

I have already spent far far too much time on this in explaining and constant hand holding. I don't mind that as I like the work you are doing on the cockpit and you are keen which is great. Over to you. Enjoy.
Joe

[Kaellis991]

Joe,

Thanks for the links and all of your help. I think I can get it from here.

Kirk

[jph]

No worries Kirk, look forward to seeing the results.
Joe

[Keith Baxter]

Keith I would completely forget thermocouples here. ALL the meter needs is the correct current. The current can be varied directly from a varying 5V supply by means of an appropriate resistor. The varying voltage supply is 0 to 5V (or 0 to 3.3V depending on processor) and is produced from a DAC made using the HW PWM module of the Arduino or Pico and a Low Pass Filter (a resistor and capacitor) .

Joe.

The thermocoupler probe values will give the scope and tick point values. By far a more acculturate way of IRL gauge operation.

I am sure you understand that the LED function does not totally rely on fixed voltages. It could be 12V or 0.12V as long as the current draw is less than the boards pin max mA parameter.

We are basically doing the same thing.
I am simulating a real life probe for the instrument by simply supplying a variable mV to the instrument probe terminals.
1) If you have the full scope of the probe values then you can simply regulate a stable max voltage to the probe terminals.

I would connect this external n mV + output to the + terminal of the gauge probe terminal and the ground to the ground of the ground of the arduino.
Then the assigned "LED" pin to the input probe terminal on the instrument.
Coding will then be 1 = zero deflection and 0 full deflection. This is because 0 = ground which supply's full voltage and 1 = + supplying 0 voltage to the instrument.

Perhaps using PWM is ok for one or two instruments. I think only 10 PWM pins are available on a mega where as there are 52 led pins.

But yes, whatever works best and easiest for you.

Joe, something you said i do not understand. If the LED function is PWM, why do we have 52 LED pins and only 12 PWN pins on a mega2560?

Keith

[Keith Baxter]

Hi Kirk,

Here is the code to run the EGT gauge if you are going to use the PWM method. I suggest you stick with the PWM method as Joe has helped you and no point in changing.
I have just used arbitrary values in the <egt_table>. I can go through determining theses values on the discord should you not know how to do that.

Code: Select all

-- Create new PWM pin for the EGT gauge
-- PWM frequency is set to 1 kHz, with a duty cycle of 0%.
egt_probe = hw_output_pwm_add("EGT Gauge", 1000, 0.)

--Create a interpolate table. These values you will have to determine.
egt_table = {{0 , 0},
                     {200 , 0.2},      
                     {400 , 0.4},
                     {600 , 0.6},
                     {800 , 0.8},
                     {1000 , 1}}
                     
--Subscribe to the EGT dataref and drive the PWM                     
 xpl_dataref_subscribe("sim/cockpit2/engine/indicators/EGT_deg_C","FLOAT[8]"  , function(egt_val)
 -- We can change the duty cycle runtime,                
 hw_output_pwm_duty_cycle(egt_probe, interpolate_linear(egt_table,egt_val[1]))                               
end)  

The code for the LED method is basically the same.
However, Joe has guided you with the PWM method so stick with that.

Keith

[jph]

Keith I would completely forget thermocouples here. ALL the meter needs is the correct current. The current can be varied directly from a varying 5V supply by means of an appropriate resistor. The varying voltage supply is 0 to 5V (or 0 to 3.3V depending on processor) and is produced from a DAC made using the HW PWM module of the Arduino or Pico and a Low Pass Filter (a resistor and capacitor) .

Joe.

The thermocoupler probe values will give the scope and tick point values. By far a more acculturate way of IRL gauge operation.

I am sure you understand that the LED function does not totally rely on fixed voltages. It could be 12V or 0.12V as long as the current draw is less than the boards pin max mA parameter.

We are basically doing the same thing.
I am simulating a real life probe for the instrument by simply supplying a variable mV to the instrument probe terminals.
1) If you have the full scope of the probe values then you can simply regulate a stable max voltage to the probe terminals.

I would connect this external n mV + output to the + terminal of the gauge probe terminal and the ground to the ground of the ground of the arduino.
Then the assigned "LED" pin to the input probe terminal on the instrument.
Coding will then be 1 = zero deflection and 0 full deflection. This is because 0 = ground which supply's full voltage and 1 = + supplying 0 voltage to the instrument.

Perhaps using PWM is ok for one or two instruments. I think only 10 PWM pins are available on a mega where as there are 52 led pins.

But yes, whatever works best and easiest for you.

Joe, something you said i do not understand. If the LED function is PWM, why do we have 52 LED pins and only 12 PWN pins on a mega2560?

Keith

Hi Keith, It is absolutely not a case of 'what works easier for me' and it is not a case of 'doing the same thing really'. it is the correct solution for ANY moving coil unit in this type of use case.
What are you going to do if you get a 115V 400hz frequency monitoring meter ? How about an Ammeter ? or a CDI Pointer ?- try to reproduce the actual input ?. it is pointless, totally impractical and simply not needed when the basic meter unit is so absolutely simple.

I think there are two issue you are not quite understanding here bro. The first is simply - HOW a moving coil meter actually works. The second is in respect to Arduino and similar boards and their on-board Hardware modules that AM makes use of. Although I explained this before I will try again as I know it is not your main area. It goes beyond simple switches, encoders and leds.

Ok, how a meter works - the core meter at the heart of the instrument. Answer - CURRENT. that's all you need to know and understand.
Voltage is irrelevant. Utterly irrelevant. mV V or KV. It is Current.

The meter inside the instrument will have a certain current that gives FSD - full scale deflection. This meter has been determined to be a 1.2mA FSD coil unit. Hence, to move it to FSD a current of 1.2mA needs to flow through the coil. That is cast in stone. All other factors MUST work around this fact.

You 'can' if you so wanted - but god know why try and botch together some variable voltage arrangement that offers an accurate and fully variable 0 to 20 thousandth of a volt (0 to 20mV) (DC) - Bloody good luck with that! ) and use a 16.66 ohm 0.01% resistor in series and it will drive the meter very nicely. again, good luck with that...
Or
You can use a fully variable 1000V DC if you really like and use an 834K series resistor and it will work beautifully.
Or
You can use the nice 5V that Mr. Arduino kindly gave us with HW PWM to produce a really easy and incredibly stable and accurate 0 to 5V output via a very simple filter (a mathematically calculated capacitor and resistor combination) and via 4.16K in series- which we have done here. Simple.

I = V/R R=V/I V=IR. I(current) is fixed here at 1.2mA, the others are not. You make V and R suit your tools to give the correct (I) current.

Nothing at all to do with voltage. The ONLY fixed value is the current that the meter coil requires.

If a gauge requires more current than it's native coil value it is only because it has added components inside. In this case you have two choice. Either supply the required parameters or simply remove the extraneous items to get to the core gauge movement. The second option is the way to go. You don't have to 'destroy' a unit to do this, simply remove one end of the internal circuitry from the meter coil assembly. Job sorted. It can always be reverted however if using in a simulator there is no point.

The voltage output of the 5V (or 3.3V) PWM is linear and the gauge meter movement (movement refers to the mechanism) action is also linear hence the gauge NEEDLE movement is fully linear in relation to the voltage with the simple 5V conversion.
This can be used on ANY moving coil meter.

Any non linearity of a gauge scale is simply compensated for in software. The needle movement, as said, is linear and proportional to Voltage - hence PWM with the small conversion we did.

--------------------

Part 2.

PWM and LED etc.

I know you are not an Arduino or other embedded micro programmer hence this is not your field so I will try to explain it again. It is low level hardware on the boards Keith. The Arduino boards - and most other embedded micro boards - PICO etc - have a Hardware PWM module BUILT IN. This can be thought of as operating fully independently of the main processor core(s). You simply set the frequency and the duty cycle and it runs, all on its own, taking no precious processing time away from the main program in the board. The only thing it needs to know to change its output is a new duty cycle level to be sent to it. It is 'fire and forget'.
See datasheet here https://ww1.microchip.com/downloads/en/ ... asheet.pdf
Look for hardware PWM. This is what is used in the HW 'PWM output' pins listed in AM.

HW LED, is, as I said before, a different animal. Still PWM but a bit banged PWM code solution that will operate on any digital output. Of course it is subject to timing alterations and demands of other areas of code, and it takes up processor time, but it is perfectly ok for running non critical items such as LEDS which don't really give a crap if something varies by 5% even . It is a cheap and cheerful way of providing lots of led outputs with variable brightness.. although the board safe power levels would probably be surpassed buy that's another story.

Both are PWM, one is fully autonomous hardware which is extremely accurate and stable. It takes no demand from main core program load and makes a superbly accurate PWM output hence a superbly accurate DAC with a simple First Order LPF. The quality of the DAC can surpass many 'built in' units.

The other .... err, isnt.. it is bit banged PWM but works just fine for LEDS - as it was designed to do. It does what it says on the tin.

As for limited numbers of outputs of true HW PWM ? - well, a PICO offers a maximum 16 outputs of true hardware PWM on any of 26 pins - amazing ! - you can even run independent HW driven frequencies (as specified in the data) It only cost 4 euros. It DOES NOT use bloody serial, it is recognised immediately by AM also. Horses for courses. Chose the right tool for the job.

I think for any new build the PICO is the way to go, not Arduino and serial - but that a different story

Hope that clarifies it for you Mr K ?

Joe

- edit - clarify output combinations on PICO

[jph]

Hi Kirk,

Here is the code to run the EGT gauge if you are going to use the PWM method. I suggest you stick with the PWM method as Joe has helped you and no point in changing.
I have just used arbitrary values in the <egt_table>. I can go through determining theses values on the discord should you not know how to do that.

Code: Select all

-- Create new PWM pin for the EGT gauge
-- PWM frequency is set to 1 kHz, with a duty cycle of 0%.
egt_probe = hw_output_pwm_add("EGT Gauge", 1000, 0.)

--Create a interpolate table. These values you will have to determine.
egt_table = {{0 , 0},
                     {200 , 0.2},      
                     {400 , 0.4},
                     {600 , 0.6},
                     {800 , 0.8},
                     {1000 , 1}}
                     
--Subscribe to the EGT dataref and drive the PWM                     
 xpl_dataref_subscribe("sim/cockpit2/engine/indicators/EGT_deg_C","FLOAT[8]"  , function(egt_val)
 -- We can change the duty cycle runtime,                
 hw_output_pwm_duty_cycle(egt_probe, interpolate_linear(egt_table,egt_val[1]))                               
end)  

The code for the LED method is basically the same.
However, Joe has guided you with the PWM method so stick with that.

Keith

Nice.
Joe

[Keith Baxter]

Hi Joe,

Thank you for the explanation. I fully understand how moving coils work. I did not know how the arduino LED worked other than to vary voltage.
Lets not clutter this thread and cause confusion to others.

Kirk,
This is calibration logic to calibrate your gauge. Your gauge is a Fahrenheit gauge
and the small tick marks are in 25° F increments. I would assume that the maximum (last tick mark) is 2300° F (1260°C) and the first tick
mark is 1800° F (982°C)
These values are determined by the max EGT value of the airframe. The C172 has a max EGT of 1250°C so I use that value here as it is most
likely that instrument value.
However the dataref we use is most likely in °C and NOT in °F. That clarification can be obtained using dataref tool.

***
Based on that, we can create a interpolate table. This table is going to use the big tick marks which are 100°F apart. Lets do the conversion from °F to °C

1800°F = 982°C
1900°F = 1038°C
2000°F = 1093°C
2100°F = 1145°C
2200°F = 1205°C
2300°F = 1260°C

Now that we have the °C conversion tick mark values we need to find the values for n1,n2,n3,n4,n5 and n6. Then substitute those values in the table below

egt_table = {{0 , 0},
{982 , n1},
{1038 , n2},
{1093 , n3},
{1145 , n4},
{1205 , n5},
{1260 , n6}}

To do that we create a test instrument to return the tick mark values. Connect your instrument to the arduino mega2560. Assign a pin (use D5 or D6 as they are PWM outputs)
Now by simply placing your mouse over instrument and rotating your mouse wheel find the value for the first tick mark. Then make a note of that value and substitute n1 with that value in you instrument. Do the same for n2,n3,n4 etc.

Here is the test instrument.

Code: Select all

--***Test instrument***--

--Add the text
robR_36redC="font:arimo_bold.ttf; size:36px; color: red; halign:left; valign:center;"
n_value = txt_add("0",robR_36redC,150,100,200,40)


-- PWM frequency is set to 1 kHz, with a duty cycle of 0%.
egt_probe = hw_output_pwm_add("EGT Gauge", 1000, 0.)


--Add a Dial that we can rotate with our mouse
n_val =0
my_dial= dial_add(nil,50,50,400,400,function(dir)
   n_val= var_cap(n_val+(dir/1000),0,1)
   txt_set(n_value,n_val)              
   hw_output_pwm_duty_cycle(egt_probe, n_val)                               
       
end)

Keith

[Kaellis991]

Joe,

It's a lifetime achievement in understanding the 420 odd pages in that datasheet.

Keith,

Thanks for the code writeup.
About the temperature range. I know a Piper Arrow owner / AP that might be able to clarify what the min. and max. temperatures are.
But for now I guess I can go with your assumptions and then change it at a later date.

These are the datarefs in the Xplane arrow aircraft that change as the manifold pressure and mixture are advanced or retarded.
sim/cockpit2/electrical/APU_EGT_c
sim/cockpit2/engine/indicators/EGT_deg_C[8]
sim/flightmodel/engine/ENGN_EGT[8]
sim/flightmodel/engine/ENGN_EGT_c[8][
sim/flightmodel2/engines/EGT_deg_C[8]

As the throttle advances from idle to full power the top dataref changes from white to blue but the associated value does not change.
Also the EGT gauge will indicate a slight (1 tick mark) change in temperature with mixture lever at full fuel flow. Logical behavior with so much fuel being introduced into the cylinders.

At idle when the mixture lever is pulled back from full the temp will spike to max. on the EGT gauge. As it should due to reduced fuel for cooling.
Advancing the throttle brings the temp back down as it should...
Throttle and mixture combinations are what change the values of the other (4) datarefs. Does the behavior of any of those datarefs come into play other than the one you have in your code?
xpl_dataref_subscribe("sim/cockpit2/engine/indicators/EGT_deg_C","FLOAT[8]"

I need to connect the gauge to a Leonardo contoller. Per the Hardware Id list that Joe provided the link to, the table indicates the following pins for PWM output...D5* D9, D10*, D11*.
The asterisk refers to a comment at the end of the table that states ---*From AM/AP 3.6 for pin D5 and for pins D10 and D11---*From AM/AP 3.6 only when frequency is same as D9 or D10.
I assume that means that I can only use D9 on this Leonardo since it does not have an asterisk.

I will get this gauge connected to my Leonardo now and start in on that code.
No doubt I will run into issues along the way today.

These are the code intricacies for which there are no books, or youtube videos available. I see no way anyone but a lifelong programmer could ever think of this coding.

Kirk