Hello Everyone,
I want to interface a (real) flap indicator for my BAe 146 simpit. I was thinking about a dc servo motor board, but this gauge would not accomodate this type of application. How would I go about setting this up as a 'plug and play' unit?
The gauge is a 5 volt unit...and I have already applied 1.5 volts to test the needle...and it moves.
Thanks in advance
Easiest way would be to use something like a Phidgets 4-Analog board. These will put out -/+ 10v, so put a resistor in series with it.
It seems to be a galvanometer.
You should tell which simulator and how are you interfacing the software with the cockpit.
The cheap way... Arduino/teensy to get data from simulator, PWM output pin and an uln2803a chip. 5-12v power supply.
With one arduino and one uln2803a chip you can drive 8 galvanometer gauges.
Hello, here are more specifics with respect to my question.
I am using FS2004 with QW 146 as my sim platform. The flap lever hardware is connected to the Bodnar 836x joystick board through a linear potentiometer. I am currently using a modified dc servo motor gauge using opencockpits DC servo motor board programed through SIOC.
Quote from: _alioth_ on August 03, 2023, 10:46:51 PMIt seems to be a galvanometer.
You should tell which simulator and how are you interfacing the software with the cockpit.
The cheap way... Arduino/teensy to get data from simulator, PWM output pin and an uln2803a chip. 5-12v power supply.
With one arduino and one uln2803a chip you can drive 8 galvanometer gauges.
I believe this is a good starting point. And it might not be necessary to have the buffer.
As my first experiment I'd probably try the Arduino "fade" example and hook up the instrument instead of an LED. Since the instrument is rated at 5V it shouldn't be damaged.
After the experiment I'd think about what to do next.
Sounds like a plan...will take a deeper look when I get home next week....more questions to follow...
In the meantime...(and this is due to the fact that I have had only one interaction with Arduino thanks to ame). for my own clarification, using my Flap selector lever through the 836X board to operate the flaps, as I do now, should (will) provide the input ( through USB interface from the FS9 program)to Arduino which in turn will send a (hard wired output) to the mechanical flap indicator gauge for selected flap positions.In order for Arduino to do this I will have to write and download code into the chip as I (we) did for the TMS (thrust management system)project. Am I close so far?
Quote from: Mach7 on August 05, 2023, 07:07:15 AMIn the meantime...(and this is due to the fact that I have had only one interaction with Arduino thanks to ame). for my own clarification, using my Flap selector lever through the 836X board to operate the flaps, as I do now, should (will) provide the input ( through USB interface from the FS9 program)to Arduino which in turn will send a (hard wired output) to the mechanical flap indicator gauge for selected flap positions.In order for Arduino to do this I will have to write and download code into the chip as I (we) did for the TMS (thrust management system)project. Am I close so far?
Pretty much. The details will vary, but data has to move around somehow, and actions must be initiated depending on the data.
Sometimes there are shortcuts insofar as you can take advantage of a side effect of something, or of something that is already present, but it's probably best to implement a naive solution and improve from there.
So the project boils down to:
Figure out where to get the input value, and what it means.
Figure out how to drive the gauge, including reliable conversion from flap angle (a number) to physical position.
Figure out how to get the data from the input to the output.
Out of interest, how many gauges will be present? This will help for planning ahead.
Hello ame..there is only one flap gauge..but I am thinking now of also connecting up my fuel quantity gauges..which are slso the same internal type..through arguing using the fs9 outputs.
Ok. Well I generally start with "what's the simplest thing that could possibly work?"
In this case, since the instrument responds to a 0-5V signal you may be able to use a PWM output from the Arduino directly.
The first step is to acquire your Arduino and set it up on your PC with the Arduino programming environment. Try a couple of examples on the Arduino to be confident that you can upload new code and everything is working.
Next, look at the PWM example code (which is documented here https://docs.arduino.cc/built-in-examples/basics/Fade).
You should be able to wire up the instrument in place of the LED, and no resistor is needed. I'd also change delay(30) on the last line to delay(100) or delay(500) to slow down the rate of change.
This will use PWM to alter the percentage of power supplied to the output pin, and the gauge should move in sympathy. Actually, it's a value from 0 to 255, with 0 representing 0%, and 255 representing 100%. One downside is of course you will only have 255 discrete positions on the gauge, but that can be addressed later.
If that works then you have the basic implementation ready to go. If it doesn't, then it's time for plan B (which I don't currently have to hand).
Thanks @ame
This is exactly what I will do. I am going to check my inventory, but I think I have an Arduino uno in stock. After the LED I will try the flap indicator gauge.
More to follow
Jim
Try Ame proposed approach first.
Later, my complete diagram would be something like this:
(https://i.imgur.com/OZ8zkx7.jpeg)
https://i.imgur.com/OZ8zkx7.jpeg (https://i.imgur.com/OZ8zkx7.jpeg)
Why using the uln2803a? We don't know the current needed to drive the flap gauge. If you direct drive the galvanometer inside, and you exceed the max arduino pin current, you can destroy the Arduino. With the 2803 buffer you are safe. (Max recommended current in arduino pin is 20mah, and due/teensy about 5-10mah, which is not so much).
Why the multiturn 10k pot? imagine you do a test and see that analogWrite (pin, 50) gets the maximun scale value. Then you only have 50 steps to drive the needle from 0 to 50.
In this case, do an analogWrite (pin, 255) and turn pot to exactly get the max value. In this way you get the 255 steps. 255 steps in a gauge like this is great.
You can get 1024 or 4096 steps using arduino due, teensy... etc, or some complicated methods. But 255 is great.
There are a lot of galvanometer gauges that need 12v. If you find this case with other gauges just remove the 5v line from arduino to uln2803a com_d pin and use a 12v power supply. Connect +12v to Com_d and GND to arduino GND
If you have a mixture of 12v and 5v galvanometers, then use 12v for all of them. Later, setup every multiturn pot to get the exactly max position with analogWrite( each galvanometer PIN, 255).
The second part would be writing a function to drive the needle exactly where you want.
I could help you when you get to this part.
Arturo.
Thanks @_aloith,
I think the current to drive the gauge is quite small...in attempting to find the pins to drive the needle I used a 1.5 volt battery and used trial and error. When I did find the correct pins the needle moved quite substantially, so not sure if the uln2803a would be necessary. The 10k pot idea is a good one for sure.
Quote from: Mach7 on August 09, 2023, 05:27:40 AMThanks @_aloith,
I think the current to drive the gauge is quite small...in attempting to find the pins to drive the needle I used a 1.5 volt battery and used trial and error. When I did find the correct pins the needle moved quite substantially, so not sure if the uln2803a would be necessary. The 10k pot idea is a good one for sure.
Be careful. Voltage and amperage are not the same thing!
Just because it moves a lot with a 1.5v battery doesn't mean anything about the amperage.
If you want to measure it correctly, set 5v to see all the deflection of the needle and put an ammeter in series to see how much current there is at that moment.
It needs to be lower than 20mah to be driven by Arduino uno/nano/mega, and about 10mah with arduino Due or teensy.
Arturo.
@_Alioth_, good point.
So, my progress thus far is finding the pins that control the gauge and rummaging around my spare parts to fine a quick connector that will accommodate this request.
I have also been researching and reading about Arduino interface applications, but I want to once again clarify one important part of my project using the attached picture.
My desire is to have the Arduino control the flap gauge through flap selector commands from the 836x board to FS9. Then usb output to arduino to manipulate the flap indicator gauge.
In other words, I am looking for clarification that this is something that is possible within Arduino, as most of the researched info I have found has a switch, pot, or button attached directly ot the board that will then close or modulate a circuit to operate a specific item within flight sim.
Jim
Quote from: _alioth_ on August 09, 2023, 09:53:39 PMQuote from: Mach7 on August 09, 2023, 05:27:40 AMThanks @_aloith,
I think the current to drive the gauge is quite small...in attempting to find the pins to drive the needle I used a 1.5 volt battery and used trial and error. When I did find the correct pins the needle moved quite substantially, so not sure if the uln2803a would be necessary. The 10k pot idea is a good one for sure.
Be careful. Voltage and amperage are not the same thing!
Just because it moves a lot with a 1.5v battery doesn't mean anything about the amperage.
If you want to measure it correctly, set 5v to see all the deflection of the needle and put an ammeter in series to see how much current there is at that moment.
It needs to be lower than 20mah to be driven by Arduino uno/nano/mega, and about 10mah with arduino Due or teensy.
Arturo.
I expect as the meter is designed to work from 5V it will work from the Arduino pwm output. I found a similar project before I gave advice:
https://hackaday.io/project/9696-not-another-darsonval-movement-clock
Quote from: Mach7 on August 10, 2023, 06:47:39 AM@_Alioth_, good point.
So, my progress thus far is finding the pins that control the gauge and rummaging around my spare parts to fine a quick connector that will accommodate this request.
I have also been researching and reading about Arduino interface applications, but I want to once again clarify one important part of my project using the attached picture.
My desire is to have the Arduino control the flap gauge through flap selector commands from the 836x board to FS9. Then usb output to arduino to manipulate the flap indicator gauge.
In other words, I am looking for clarification that this is something that is possible within Arduino, as most of the researched info I have found has a switch, pot, or button attached directly ot the board that will then close or modulate a circuit to operate a specific item within flight sim.
Jim
I'd say yes, but it will take a bit of research to find out how.
I thought it would be better to start at the end, and determine how to drive the gauge, on the assumption that if you couldn't drive the gauge then there was no point figuring the other stuff out.
You could do all the development in parallel, but there's only one of you.
As per ame's guidelines, I connected up the Arduino UNO as per the schematic with the successful download of the "Fade" program.
I have included a link to my youtube channel to see the operation.
I did not change any code in the text, so this is the direct result I got after connecting up 5 volts of power. (note I used a 5 volt dry cell battery, so the voltage may have been a bit below 5)
I suppose we can agree that the gauge can accept PWM outputs directly from the board...so what are the next steps in the implementation?
Jim
https://www.youtube.com/watch?v=MKtGRb3HmVk
That's great! It's not clear from the video, but does the needle cover the entire range? Did you have the meter connected directly to the Arduino, or is there a resistor in series?
If the needle covers the entire range, great! If not, it needs to be buffered, as alioth suggests. This could be done with a transistor, or uln2803a.
Next, you probably need a function in the Arduino code which converts the flaps value from the simulator into a PWM value to output. If you're lucky this will be linear, and you can use a simple equation like:
pwm=flap_angle_degrees*7.727
That will convert a number from 0-33 into 0-255.
If you're unlucky then it's non-linear, but hopefully predictable in some way.
Either way, you can print out the PWM value in the code and make a note of the value at each marked position on the gauge and figure it out.
But, this is a great start.
Hello ame,
No, the needle did not cover the entire range. I connected the gauge directly to the Arduino board, no resister.
Ok. If the needle doesn't cover the full range and there is no resistor present then it means this approach won't work. It could mean that a buffer is needed, as suggested, or I wonder if you have an air core meter:
https://en.m.wikipedia.org/wiki/Air_core_gauge
This needs a different method to drive the needle.
With respect to the needle movement...would this not be a function of the values set in the "Fade" program...in other words if the program was modified could the needle not be 'forced' to move the entire range of the gauge?
@ame, I don't think it is an air core gauge, but rather closer to a Desynn Type Position Indicator. The fuel gauges are the same construct as well.
With respect to the flap gauge, it does not travel a full 360 degrees, but rather closer to 250 degrees, (0 degree flap angle to 33 flap angle on the dial).
You could also try emailing the manufacturer.
https://www.rogersonkratos.com/
Bit of a long shot, but it might work. Even if they would describe the kind of mechanism inside, or a wiring diagram, it would help. Even to avoid damaging the unit.
I haven't had much luck googling the part number, other to find that it is a Rogerson Kratos flaps indicator, which I pretty much knew. :)
Quote from: Mach7 on August 10, 2023, 06:45:51 PMWith respect to the needle movement...would this not be a function of the values set in the "Fade" program...in other words if the program was modified could the needle not be 'forced' to move the entire range of the gauge?
The fade example program does indeed cover the whole PWM range from 0 to 255. If you forced the value to 255 it's the same as 100% on, and will basically output a constant 5V on the GPIO pin.
It could be that the Arduino can not source enough current to drive the coil to fsd, so a buffer may be necessary. Or perhaps the meter movement is very sluggish, and increasing the delay in the loop (therefore changing the output more slowly) would help.
This was basically the simplest experiment to glean information.
Quote from: Mach7 on August 10, 2023, 06:51:29 PM@ame, I don't think it is an air core gauge, but rather closer to a Desynn Type Position Indicator. The fuel gauges are the same construct as well.
With respect to the flap gauge, it does not travel a full 360 degrees, but rather closer to 250 degrees, (0 degree flap angle to 33 flap angle on the dial).
Ok. I am googling Desynn now. Soon I will know as much as the world knows.
I can see that the needle does not rotate 360 degrees, but a mechanism that does does not need to use the full range.
Hopefully it is possible to generate a variable voltage which translates to a variable deflection angle of the needle. If it's more complicated it's going to take a while to figure out.
Like this?
https://www.sphaera.co.uk/position.htm
It requires three connections with variable voltages with respect to each other. It ought to be possible to generate the appropriate signals, but I don't know how just now.
Hmm...
https://scottbouch.com/aircraft-cockpit-instrument-simulation.html
lol...i was just reading the same site as you...(scotchbott).
I was hoping there would be more markings on the gauge itself...it does say it's a 5 volt gauge max that's about it.
I do know that the fuel gauges..which have the same internal construct, can be manipulated to there full range, (which is about 300 degrees) using a 5 volt power source and manipulated through a potentiometer.
I am pretty confident that if i connected this gauge directly to 5 volts it would go off scale.
Quote from: Mach7 on August 10, 2023, 07:26:47 PMlol...i was just reading the same site as you...(scotchbott).
I was hoping there would be more markings on the gauge itself...it does say it's a 5 volt gauge max that's about it.
I do know that the fuel gauges..which have the same internal construct, can be manipulated to there full range, (which is about 300 degrees) using a 5 volt power source and manipulated through a potentiometer.
I am pretty confident that if i connected this gauge directly to 5 volts it would go off scale.
Ok. The Arduino PWM output will be 0V when the PWM value is 0, and 5V when the PWM value is 255. It is the same as hooking up a 5V supply directly to the instrument, but the current from the GPIO pin may be insufficient.
If you believe a single signal line varying from 0 to 5V will move the needle across its full range then you can test it independently from the Arduino (carefully) with a variable bench power supply varying from 0 to 5V. That would be a d'Arsonval movement, such as you would find in a moving coil meter.
If it's a Desynn Type position indicator then it's a little more complicated than a single signal on a single wire, but in true internet tradition you can copy someone else's work and give yourself a head start.
I am going to try...very carefully...applying a direct voltage to the gauge and see if I can get the required deflection at 5 volts...stay tuned more to come.
Quote from: Mach7 on August 10, 2023, 07:50:09 PMI am going to try...very carefully...applying a direct voltage to the gauge and see if I can get the required deflection at 5 volts...stay tuned more to come.
Fingers crossed.
You could use rechargeable AA batteries. Each one is nominally 1.2V, so you could get four indicative positions, with the last one being 4.8V (or a little over 5V if they are fully charged).
and the answer is yes...i can get full + deflection with 5 volts connected directly to the gauge...
I had to be careful not to exceed the needle travel, so I just tapped the positive terminal on and off and was able to determine without a doubt that 5 volts would be more than sufficient to drive the needle off scale.
@ame in fact...now using a combination of 1.5 volt batteries...i can move the needle from 0 to 18 degree mark on the dial with two batteries connected in series (3 volts), and with three batteries hooked in series (4.5 volts) I can just about reach the 33 mark on the gauge. I am pretty confident that it would indicate exactly at the 33 mark at 5 volts.
Sounds ideal. So it would seem that the current for fsd at 5V is larger than the Arduino GPIO pin can provide.
Does the gauge needle respond rapidly (instantly) to the applied voltage?
Can you measure the resistance of the coil? Basically the two wires you are using to drive the meter. From the resistance we can calculate the current requirement for fsd.
Next, how do you want to buffer the signal? Do you have a uln2803a? An op-amp? Some simple transistors? I don't know how extensive your junk box is.
I have seen the youtube video and I think you don't get full deflection with pwm arduino PIN because you are feeding 5v in the Barrel Jack Connector.
Arduino needs 7v to 12v in this jack (see arduino specs), because it is before the regulated circuit. So you probably don't have more than 3v in 5vPIN and HIGH level pins.
You can use 5v if connected to 5v arduino pin (you must regulated voltage perfectly well or you will destroy arduino), or usb power.
I think you should just connect the usb cable to pc, and thats all. Probably you will get the full deflection with PWM PIN in this way. And you will end connecting the arduino uno to PC because you need the data transfer from FS9. Therefore, it is better to connect the arduino to the pc from the beginning. You don't need any extra power supply.
I still say you should measure current when the needle is at full deflection. Or as Ame said, give the resistance value to calculate the amperage.
If the Arduino hasn't died already, it probably won't die. But it's better to be safe than to buy another Arduino.
About data transfer:
1.- My adviced would be try to start with Link2fs software.
Link2fs is a small piece of software where you check some boxes of simulator data you want to be sent to a serial port (the arduino serial port). Then you write the code in arduino to read that data, process it and send the pwm signal needed to move the needle.
Sure it is not the best way to do it, but it is "easy" and works just fine.
2.- A second plan, would be write a Lua script using FSUIPC that reads the data from simulator and sends it to arduino through serial port. You have better control of everything with this method. but it is not as easy.
link2fs is much easier to start with.
3.- If you were using FSX you could use mobiflight software. It is easy and you don't have to write code. But I think fs2004 is not officialy supported. I don't even know if it works with fs2004.
Arturo.
@ame, yes, the needle move very fast when connected directly to the battery(s), but at a slower pace, (and not full deflection) when connected to Arduino.
My junkbox is limited, so all I have is a handful of Arduino UNO's and NANO's :(.
@Arturo. What you say makes a lot of sense to me with respect to the 5 volt barrel jack connector.
Connecting the USB to the PC should kill two birds with one stone...supplying power to the gauge and allowing for data transfer at the same time.
I was actually reading up on the Link2ks software and I agree with you that this may be the simplest method to successfully accomplish this project...I will do more research today which will no doubt generate more questions.
Jim
@Arturo,
I am leaning towards using my (existing and installed) FSUIPC and,(somehow with help), writing a LUNA script as you suggested to operate the flap gauge.
The only problem I can see using Link2fs is that it might interrupt or offset something I already have working within my flight sim environment.
I know this may sound a bit paranoid, and the read me file does state that it should not have an impact on any other systems, but I have downloaded some pretty innocent FS9 addons then spent the day trying to reverse the process as something went array in my simpit.
Here is an exerpt form the read me file that bothers me a bit that I think may have an issue with my main computer;
You must do this ,,,,
=================================================
There is an attached file call FSConnect.dll ,,, it MUST be
put into FS9's module folder. (My program wont work if it's not there)
=================================================
What do you think...is my aforementioned paranoia warranted, or will downloading this .dll have zero effect on the other subsystems and fs9 itself.
Side note...
I connected the Arduino directly to the usb (for power), (no dry cell batteries involved), and ran the "Fade" program once again.
The needle moved from 0 to the 33 mark back and forth as anticipate!!
Quote from: Mach7 on August 11, 2023, 07:21:16 AMSide note...
I connected the Arduino directly to the usb (for power), (no dry cell batteries involved), and ran the "Fade" program once again.
The needle moved from 0 to the 33 mark back and forth as anticipate!!
This is not just a side note. This is precisely what you set out to achieve!
Next step is software.
Quote from: _alioth_ on August 11, 2023, 02:29:32 AMI have seen the youtube video and I think you don't get full deflection with pwm arduino PIN because you are feeding 5v in the Barrel Jack Connector.
Arduino needs 7v to 12v in this jack (see arduino specs), because it is before the regulated circuit. So you probably don't have more than 3v in 5vPIN and HIGH level pins.
Well spotted!
@ame & Arturo,
So been researching Link2fs and FSUIPC interface senario's...and it seems to me Link2fs is the most viable option, (regardless of my misgivings about changing or adding fcconnect.dll to the fs9 program)...i suppose I can always remove it if it interferes with other aspects of my simpit.
Regardless, I do not see another workable avenue to get my program (payware QW146) to communicate to arduino to display selected flap position following seletion through the flap pot and 836x.
I am finding that the tutorial information on Link2fs is a bit thin...i have watched a number of YouTube vids...but most deal with setting up switches or lights...also a bit confused as to the programming of the arduino chip....
For what i gather, you make a selection in Link2fs..so does this selection automatically write or download to arduino?.It can't be as simple as that...can it?
I found a link to "Arduino cards and Link2fs" on mycockpit.org...but the link seems to be dead or outdated.
I used to be a member on that site, so I am trying to resend my (forgotten) password...but it appears more difficult than expected...so I tried to re-register and now waiting on an email activation invite...that was an hour ago.
I can't find a comprehensive reference to link2fs. Is it originally from jimspage.co.nz? If so, the original has gone.
Doesn't really matter. Again, working backwards, you can now drive the needle to any arbitrary position by setting a PWM value from 0-255. Next is how to get the data out of the sim that tells you "this is the current flap position in degrees". Maybe link2fs will do this, or you may find an alternative. If link2fs is your preference then we can focus on that, so if you have some links for the package and documentation that would be great.
@ame...here is a link to "Link2fs"
https://web.archive.org/web/20190329143140/http://www.jimspage.co.nz/Link2fs_Multi_FS9.htm
Not an easy site to find....
What happened to SIOC?
I will download the link2fs Multi zip file and take a look. There are some Arduino examples in there. It seems that link2fs extracts the nominated data from the simulator (somehow) then sends it in a defined format out of a serial port to an attached Arduino. Then, a program on the Arduino parses the data and does whatever is necessary on its GPIO pins. I think it works the other way too, so that the Arduino can detect switch presses or pot changes and send stuff back to update the sim.
It seems to me that there are several similar solutions that do the same thing as link2fs, although from my research nothing really stands out as the "best". I'd be a bit concerned that the author's website is no longer active, but then again, if you have a consistent snapshot of the technology at the time then all the pieces should work together as they did, and continue to work if nothing else changes.
Yes..it was very difficult to get to the site or even find it for that matter. That sortof tells me it is not all it's marked up to be.
And like I said earlier...mycockpit.org had a whole section devoted to Arduino and Link2fs...but it no longer exists...or at least I cannot access it.
So another question...can you download a SIOC script into arduino?
Well your other problem is that whatever you choose must remain compatible with FS9 and your OS, so using something older like link2fs might be appropriate.
Early on you said "I am currently using a modified dc servo motor gauge using opencockpits DC servo motor board programed through SIOC."
So, currently, there is a data path from the sim to SIOC to a servo controller board to a servo motor. Is that right?
Would it be possible to go sim -> SIOC -> Arduino -> gauge?
If you are really keen on link2fs then that's fine, but unless you are averse to SIOC would it not be better to keep using it? Either way it's your choice, but I thought I'd at least ask the question.
Ha, you posted while I was typing, and posed the same question. :)
I don't know. Will have to google harder. Although I'd expect somebody here to have some experience with SIOC.
Yes I agree...but i was never sure if Arduino could accept SIOC language...and also the boards are for dc servo motors...but if there is a chance we could use the existing code and go SIOC > arduino > gauge..then yes for sure.
The only thing that attracts me to the Link2fs is that if I successfully integrate the flap gauge, then the fuel quantity gauges should be easy to interface.
The only thing that detracts me from Link2fs is the lack of tutorial or programming information.
@ame...im going to have a look see at MobiFlight...I was lead to believe it was only for FSX FS2020 and PD3D...but for what I have read so far it seems to support FS9 as well.
The good thing about MobiFlight is it will write and install the firmware to operate the respective gauge...or at least that's what I read into it.
@ame and Arturo,
Another option, although not ideal, would be for arduino to read flap selector position as opposed to actual flap position and avoid outputs from fs9 altogether. It could be done by connecting a parallel pot to the lever, or some other way of sending inputs to the board.
Just floating ideas
Sounds great. Yes, mobiflight keeps popping up as a viable solution. If it might work for you then it is probably a better choice than link2fs as it is currently active and being developed and maintained.
Quote from: Mach7 on August 11, 2023, 05:46:25 PM@ame and Arturo,
Another option, although not ideal, would be for arduino to read flap selector position as opposed to actual flap position and avoid outputs from fs9 altogether. It could be done by connecting a parallel pot to the lever, or some other way of sending inputs to the board.
Just floating ideas
This is not a terrible idea, as it will help with verisimilitude, but will lack the interactive property of working with the sim.
@ame..yes I agree with your last statement.
I have just finished getting up to speed on Mobiflight and there is maybe two references to FS9, and when you look at the internal drop down menu there seems to be NO FS9 selection.
Having said that I will now assume it is not supported.
At the very least we are eliminating options.
Well, if link2fs actually works then it might still be a good choice, despite being out of date and out of development. If the documentation is sparse it doesn't matter.
I'll look at the zip file and see if I can figure something out.
@ame, thanks for that.
I have been reviewing it as well, (link2fs)...it seems to me that a script will still have to be written even once the variable has been selected.
The screen shots the webpage provides are very small and difficult to make out.
I too downloaded the zip file and began to review it, but I do not find the page information intuitive. But then again I like tutorials that start with step 1 to 10, with 10 being the end result.
Quote from: Mach7 on August 11, 2023, 08:34:54 PM@ame, thanks for that.
I have been reviewing it as well, (link2fs)...it seems to me that a script will still have to be written even once the variable has been selected.
Yes, indeed, a script must be written, tailored to the specific hardware you have attached to specific pins on the Arduino. In the DemoINOs folder there are a bunch of Arduino programs that illustrate how to handle the incoming data.
The Arduino basically appears as a serial port (COMx:). Link2FS is an application written on top of FSConnect, from here:
https://www.dirks-software.ca/
FSConnect.dll does all the hard work. Link2FS makes the interface to FSConnect easier.
Once you have chosen which data elements you want to send out of FS9 link2fs fetches them and packages them all up into a string. The string is sent to the serial port, with each data element tagged with a letter, and separated with an equals sign.
So, in the Arduino code you just have to look at the incoming serial data stream, look for the '=' sign, then look at the next character. The next character tells you which data element you are going to get (and you know which ones to expect, because you set it up). So, in the case of flaps this is going to be a number, but the number is a sequence of numeric characters. We bring in however many numeric characters then convert the string of characters into a number. That number is the flap degrees. Then, multiply that number by a scaling factor and write it to the PWM output. Done.
The screen shots are a lot more visible on a laptop. Almost illegible on a phone.
If link2fs works then great, but there are others that you could investigate. You might find they won't go back as far as FS9.
Quote from: Mach7 on August 11, 2023, 03:32:11 PMYes I agree...but i was never sure if Arduino could accept SIOC language...and also the boards are for dc servo motors...but if there is a chance we could use the existing code and go SIOC > arduino > gauge..then yes for sure.
Sorry, meant to reply to this. Yes, this is probably a good choice because you already have it working. I'm going to look at SIOC too.
I was going to explain how link2fs + arduino works but Ame has done better than I would have done it.
I used this method years ago with 5 arduino megas in a whole cockpit (inputs and outputs) and it was reliable and fine.
It seems to be a little complex (and it is if you are only interfacing one gauge). But if you are interfacing several gauges, then the work for the second gauge it is just a tick in the link2fs window and a few lines more in the arduino sketch. If coded with care (word "delay" is forbidden) you can drive lots of gauges just with one arduino. Darsonvals, steppers, leds, dc motors, encoders etc etc..
Years later I migrate everything to FSUIPC (lua script + arduino).
The arduino part is the same (read data in com port), but you write the lua script that takes from simulator the data you want and sends it through com port when you want, in the way you want etc you want.
And the lua script reads data incoming from arduino to send data to simulator too.
But I think link2fs is better to start, because you only need to understand one part of the system. The arduino part (the fun part, in my opinion) :)
Arturo.
@ame,
Thanks for reviewing that ame...I think that the best direction, after reading all of your comments, seems to be link2fs. If we are successful with the flap gauge then this means I should be able to connect my three fuel gauges as well...(left, center, and right)
I am also curious with what you come up with SIOC as the code is already in the OpenCockpits network and is presently operating my existing, (make shift), flap gauge.
The next step I suppose is trying to find a flap script then tailor it to my own application. I have never written script before, I just modified it as per your instructions during the TMS project.
@Arturo
You seem to have a good working knowlege of Link2fs, so I hope I can lean on you as i stumble through the setup process...i might even make a step by step checklist and have you read it over to make sure I am moving in the correct direction. I have a lot of USB hubs and plugins in my simpit, so I want to make sure I do not reassign something using Link2fs by mistake.
Also...you mentioned that you ran a number of items off one Arduino board...will I be able to use one board to run 4 gauges, (flap, & the three fuel quantity gauges), or is it one board per gauge?
Thanks to both of you..
Jim
So...what I can gather after going through a very good youtube video
https://www.youtube.com/watch?v=OSzE6hgFWCM
the steps to use Link2fs may be a bit more straight forward than I thought...so correct me if I am wrong here...assuming the code is written to the Arduino board...by link2fs selections would be as follows
1. set up serial com(s) for the Arduino card (select respective serial port and select "connect")
Question....This is where I hit a bump in the road...how do I know which com (USB) port to select as I have many USB plugin on my sim.
2. Select "FSsimconnect extractions, page 2 and check the box that indicates "?x flap handle %"
3. Select Simconnect inputs (?? not sure about this one...but assuming it needs to know the pot values of the mechanical flap selector lever??) scroll down and to highlight one of the flap variables, (either c15, Decrements flap handle postion or, c17xx sets flap handle to closest increment...not sure which one or either for my application at this point)
4. Finally select "other stuff" for PWM outputs for
meters ($F flap position) click this box.
how many missteps or misinterpretations have I made so far??
@ame
Here is a copy of the SIOC code, (notepad) that runs my (DC Servo motor driven) Flap gauge at present...not sure if this gives us any insight into preparing the code for the type of Flap Gauge we are dealing with now;
Var 0033, name servo_flaps, Link USB_SERVOS, Device 2, Output 5, PosL 471, PosC 715, PosR 959
Var 0034, name flaps_fsuipc, Link FSUIPC_IN, Offset $0BE0, Length 4 // flap indicator gauge
{
L0 = &flaps_fsuipc
L0 = ABS L0
IF L0 = 0
{
&ind_le_extend = 0
&ind_le_trans = 0
}
ELSE
{
L1 = 0
&ind_le_trans = 1
IF L0 = 409
{
L1 = 1
&ind_le_trans = 0
}
IF L0 = 819
{
L1 = 1
&ind_le_trans = 0
}
IF L0 = 2047
{
L1 = 1
&ind_le_trans = 0
}
IF L0 = 4095
{
L1 = 1
&ind_le_trans = 0
}
IF L0 = 6143
{
L1 = 1
&ind_le_trans = 0
}
IF L0 = 10239
{
L1 = 1
&ind_le_trans = 0
}
IF L0 = 12287
{
L1 = 1
&ind_le_trans = 0
}
IF L0 = 16383
{
L1 = 1
&ind_le_trans = 0
}
&ind_le_extend = L1
}
L2 = L0
C0 = L0 >= 0
C1 = L0 <= 496
IF C0 AND C1
{
&flaps_low_val = 0
&flaps_high_val = 496
&servo_high_val = 471
&servo_low_val = 742 // 0 and 18 degrees
}
C0 = L0 >= 496
C1 = L0 <= 8000
IF C0 AND C1
{
&flaps_low_val = 496
&flaps_high_val = 8000
&servo_high_val = 742
&servo_low_val = 867 // 18 and 24 degrees
}
C0 = L0 >= 8000
C1 = L0 <= 11000
IF C0 AND C1
{
&flaps_low_val = 8000
&flaps_high_val = 11000
&servo_high_val = 867
&servo_low_val = 910 // 24 and 30 degrees
}
C0 = L0 >= 11000
C1 = L0 <= 14000
IF C0 AND C1
{
&flaps_low_val = 11000
&flaps_high_val = 14000
&servo_high_val = 910
&servo_low_val = 959 // 30 and 33 degrees
}
&servo_calc = &servo_low_val - &servo_high_val
&flaps_calc = &flaps_high_val - &flaps_low_val
&flaps_val = L0 - &flaps_low_val
&servo_val = &servo_calc * &flaps_val
&servo_val = &servo_val / &flaps_calc
L1 = &servo_high_val + &servo_val
&servo_flaps = L1
}
Var 0003, name servo_val
Var 0004, name flaps_calc
Var 0005, name servo_calc
Var 0006, name flaps_val
Var 0007, name flaps_low_val
Var 0008, name flaps_high_val
Var 0009, name servo_high_val
Var 0010, name servo_low_val
Var 0011, name ind_le_extend, Link IOCARD_OUT, Output 22
Var 0012, name ind_le_trans, Link IOCARD_OUT, Output 21
Quote from: Mach7 on August 12, 2023, 05:37:51 AM1. set up serial com(s) for the Arduino card (select respective serial port and select "connect")
Question....This is where I hit a bump in the road...how do I know which com (USB) port to select as I have many USB plugin on my sim.
Go to Device Manager in Windows, plug and unplug the arduino usb and look in Com ports. there will be one appearing and disappearing.
Quote2. Select "FSsimconnect extractions, page 2 and check the box that indicates "?x flap handle %"
Fine.
Quote3. Select Simconnect inputs (?? not sure about this one...but assuming it needs to know the pot values of the mechanical flap selector lever??) scroll down and to highlight one of the flap variables, (either c15, Decrements flap handle postion or, c17xx sets flap handle to closest increment...not sure which one or either for my application at this point)
you weren't using a leo bodnar card for this? So you don't need. Perhaps you can use it in future. But keep things simple first. So Leo bodnar moves the flaps, and you read the flap position with link2fs. That's fine.
Quote4. Finally select "other stuff" for PWM outputs for
meters ($F flap position) click this box.
I don't know what this is. When you get the flap position in arduino, you will do PWM thing there, in the arduino sketch.
I can't find a simple solution for SIOC to Arduino, so that might be a non-starter I'm afraid. And some of the other solutions that pop up don't work for fs9.
You are right, keeping track of the Arduino serial port might be tricky. In general, windows seems to attach the same device to the same serial port if it can. You may find that every time you boot up you will get the same COM port for this Arduino. One possible solution is to buy a genuine Arduino, which has a serial number (clones do not). This allows you to see exactly where the Arduino is by following the serial number. But that's not a problem yet.
You can drive up to six PWM pins on the Arduino, so four instruments that work like the flaps gauge is no problem. And yes, you can measure a pot to get the position of the flaps lever and send that back to the sim (so the data makes a round trip: pot -> Arduino input -> Arduino serial output -> PC serial input -> link2fs -> simulator -> link2fs -> PC serial output -> Arduino serial input -> PWM output -> gauge).
I'll get back to you about the link2fs settings. At the moment I suggest you focus only on getting a single piece of data out and into the Arduino, specifically the current flaps position. Don't worry about the other gauges or the simconnect inputs.
There is a monitor section on link2fs which shows the data going to the Arduino. If you get it going you should see an equals sign followed by a lowercase letter followed by a string of numeric digits representing the flaps position. I think it is live, so if you vary the flaps the number will change.
Doing development like this at arm's length will take a while, but it will be methodical.
Once you know that link2fs can extract the data element that you want, and you can see the format of the number the next step is to write the Arduino code. Fortunately that appears to be really straightforward.
I think Arturo and I agree.
If we ever disagree it will be an interesting exercise for you to decide who is right.
Hey...both you guys are great and I cannot thank you enough for the help...all good agreeable information so far...
So...I am going to take ame's advice and concentrate on building the flap program from scratch. Once the Arduino has the flap code...then it will be on to Link2fs.
I have spent the day going over programming tutorials, and I think I might be able to pull this off...of course I will need answers to a lot of questions.
lets see how far i get...
So i need a bit of a launching pad to get started...I have successfully written a few codes using the arduino examples section..some from scratch and others by just modifying the existing code.
I was hoping the examples would contain a pwm circuit that I could copy and modify...but no joy so far.
Can I actually write and download the code on my laptop then install the arduino uno and configure useing link2fs? or am I going to have to do it all at once.
Not sure if my rambling makes any sense.
Woah, Trigger! You pretty much have to work with link2fs and the Arduino code together. For the Arduino code you need to know what data to expect, which you only know after you've set it up in link2fs.
Yes, you can write the Arduino code on your laptop, download it to the Arduino itself, then unplug the Arduino and plug it in to the flight simulator pc. That might become a bit tiresome, but hopefully you only need to do it a couple of times.
Don't worry too much about the pwm. You're basically going to get a number from link2fs representing the flaps position, do a bit of maths to convert it to 0-255, then analogWrite(pin, value) to drive the gauge.
I've read a little more, and I now realise that stuff coming out of link2fs is not always separated by an equals sign. Sometimes it's equals, sometimes a question mark, sometimes less than, etc., followed by another letter (upper or lower case).
Doesn't matter. All you need to know is the marker for the flaps angle. Are you sure it's "?x flap handle %"? That sounds like the control lever, not the flaps themselves. In one of the screenshots I saw it's "FSConnect Extractions (1)" "<G Flaps Position", but it could be different for your aircraft.
Whatever it is you should be able to see it in the Traffic Monitor "to card". When you change the flaps the number should change. Please report back the marker (maybe ?x, maybe <G) and the format of the number. Change the flaps and note down a few values at key flap positions, so you know the range of values to expect. For the purposes of illustration let's say it's ?x followed by zero padded three digits of degrees (from 000 to 359, but actually you only see from 000 to 033 because that's the range of the gauge). I have no idea if that is correct, but it's an example.
Next, copy one of the sample INO files for Arduino. The setup code has to set up the pwm output pin that has the gauge attached, and drive it to zero. The loop code continually waits for incoming serial data. In the example case, if you see an incoming "?" then you wait for the next character. If it's an "x" then you know the next three characters are your degree value. So you bring in three more characters, convert them to a number, do some maths (maybe just multiply by 7.727) and write the pwm value. Obviously there are a few details to take care of, but that's basically it.
Then you loop around and do it all again.
Ok thanks ame,
Yes...I was wondering how I would see the inputs outputs then remembered the "traffic" monitor on linkf2fs itself.
With respect to the flap box...i think you may be correct as i am not sure it would be ?x flap handle %.
I will do some experimenting today.
Jim
@ame & Arturo
Some progress has been made...
So I downloaded link2fs onto my main sim computer...the computer already had "FSconnect.dll" in the FS9 modules folder, so that is one step i could skip.(most likely due to the OpenCockpits program).
I had some trial and error, but found you cannot read anything off the (link2fs) monitor unless fs9 is up and running with the respective sim platform booted up...in my case Quality Wings 146.
Next I connected the USB + Arduino and found that it would only take info from com port 1, if anything else was selected, (say com 2, 3, 4 etc), it would flash on and off (green) at the communications portal box. Since it seemed happy at this selection I left well enough alone.
Regardless, the next step was to select card one, move to the FS extractions page where I selected <G flaps position, then moved to cycle the flaps from zero to 18, then to 24, then to 30, then to 33, (Fs9 + qw146 program booted up).
With each flap selection the monitor would indicate an increasing value from <G000 to <G002..003 etc etc until the flaps stopped at 18 degress where the monitor showed <G020. (Not sure why it did not say <G018, but that is something we can deal with later)
Anyway, once the flaps were moved all the way to 33, the monitor showed (and stopped counting) at <G033.
When I retracted the flaps, the counter went from <G033 all the way to <G000 once the flaps were indicating at zero.
I have included some screen shots...take note they are random, but they outline the selections I made on Link2fs and also what the monitor was showing when the flap lever was being selected.
As the flaps travelled to
Perfect! Now an Arduino program that looks for "<", then "G", then pulls in three characters that are digits, convert the three digits to a number, multiply by the scaling factor*, then analogWrite(). Done!
I can picture the code. If you can't find an example that is close to this don't worry, I'll write something. Unfortunately it's Monday morning here in NZ, so I don't have so much free time today.
* I am assuming a linear relationship between the applied pwm value and the markings on the gauge. If it's not linear we can look at that later.
Hello ame,, yes...i have been searching for code on GITHUB for something similar, but so far no luck. I think a lot of this is new territory as a lot of sim's are straight glass cockpits now.
I will keep looking for an example.
Thank you again
Jim
How about the examples folder in link2fs?
Here's something to look at:
https://github.com/maxime-a/Airspeed-Indicator-for-flight-simulation/blob/master/Multi_Keys_with_flaps_servo.ino
I don't know why the author refers to flaps with character "G" in the comments, but "P" in the code, but you can see the general structure of how it's done.
Read the incoming data stream. Find "<", jump to LESSTHAN. Find "P" (in your case should be "G"). Pull in three more characters. Convert to a number. Do stuff. Done.
I will use that example if you like, by stripping out everything but the flaps code.
It uses the Arduino string library, which is universally disliked, but it's such a small program it won't matter.
ok...i guess whatever happens it can be modified with trial and error.
Quote from: Mach7 on August 13, 2023, 12:57:46 PMok...i guess whatever happens it can be modified with trial and error.
Software development in a nutshell.
Ok. Try this. I decided to removed some unused code, but not all, so you can see the general structure. You could add code in the "Do something" sections if you decide to send other elements from link2fs.
Quote/*
This code is in the public domain
For use with "Link2fs_Multi"
Jimspage.co.nz
*/
int CodeIn;// used on all serial reads
String flaps;
int flaps_PWM_out_pin = 3; // Must be one of 3, 5, 6, 9, 10, or 11 for Arduino Uno
void setup()
{
Serial.begin(115200);
// Set up PWM pin to drive flaps gauge
pinMode(flaps_PWM_out_pin, OUTPUT);
// Set PWM value to zero.
analogWrite(flaps_PWM_out_pin, 0);
}
void loop() {
if (Serial.available()) {
CodeIn = getChar();
if (CodeIn == '=') {EQUALS();} // The first identifier is "="
if (CodeIn == '<') {LESSTHAN();}// The first identifier is "<"
if (CodeIn == '?') {QUESTION();}// The first identifier is "?"
if (CodeIn == '/') {SLASH();}// The first identifier is "/" (Annunciators)
}
}
char getChar()// Get a character from the serial buffer
{
while(Serial.available() == 0);// wait for data
return((char)Serial.read());// Thanks Doug
}
void EQUALS(){ // The first identifier was "="
CodeIn = getChar(); // Get another character
switch(CodeIn) {// Now lets find what to do with it
case 'A'://Found the second identifier
//Do something
break;
case 'B':
//Do something
break;
case 'C':
//Do something
break;
}
}
void LESSTHAN(){ // The first identifier was "<"
CodeIn = getChar(); // Get another character
switch(CodeIn) {// Now lets find what to do with it
case 'A'://Found the second identifier
//Do something
break;
case 'B':
//Do something
break;
case 'G': //Found the second identifier ("G" Flaps position)
// Next three characters should be numeric
flaps = "";
flaps += getChar();
flaps += getChar();
flaps += getChar();
// convert 3-character numeric string to a float
// Expected range is 000 to 033
float flaps_degrees = flaps.toFloat();
// Convert degrees to PWM 0-255.
// 33 degrees is full scale, so multiplier is 255/33=7.727
int PWM_out = flaps_degrees*7.727;
// Clip output to maximum if (for some reason) it's >255
if(PWM_out > 255) PWM_out=255;
// Drive the gauge by writing to the PWM pin
analogWrite(flaps_PWM_out_pin, PWM_out);
break;
}
}
void QUESTION(){ // The first identifier was "?"
CodeIn = getChar(); // Get another character
switch(CodeIn) {// Now lets find what to do with it
case 'A'://Found the second identifier
//Do something
break;
case 'B':
//Do something
break;
case 'C':
//Do something
break;
}
}
void SLASH(){ // The first identifier was "/" (Annunciator)
//Do something
}
No, I haven't tried this code. I recommend first that you look at it and read it (even if it looks complicated). It's basically one simple step after another. Everything should fall into place when you get to the end, but keep in mind there is other stuff coming from "outside" which is what is driving the program.
Any joy?
The code works. I have uploaded in an Arduino Nano to test. I don't have a galvanometer here to test now, but I have tested with some serial.prints
Some things I see:
1.- The way the serial port is read in those link2fs examples are not the best. It can happen that "if (Serial.available())" sees incoming data, but the data is not complete yet (something like <G0, because de last two numbers 18 have not arrive yet ) and you lose that comnunication.
For this reason, a simple fix is to add a delay before reading the characters when serial.avaliable says there is something to read. In this way you are sure that the incoming data will be complete before trying to read it. (something about 10ms worked fine I remember)
This fix was commonm in link2fs days. And for one (or several) simple galvanometers will work great. But the ideal would be a diferent approach to read the data, without delays.
I think Mach7 should test the code as is, because it should work and this is a big step.
2.- Later, (only when Ame code is working for you) a smoother funtion for the needle should be coded. Because in the way the code is written, you only have 30 needle steps. Arduino can make 255 steps so going for 0 to 1 degree in flaps should go 0..1..2..3..4...5..6...7 in pwm.
But now it will go for 0 to 7, so the needle is not going to be very smooth.
3.- <G indicatesd flaps position. But It can happen flaps are really in 18 degrees, but master bus in aircraft is switch off, so the gauge should be at 0. When you switch on the master bus, the gauge (which needs energy in bus), will go to 18 position.
The way to do this is tick the box in link2fs for bus voltage, reading this data in arduino and write some conditions there in the pwm function.
Sometimes you will find a variable that indicates needle position, instead of "flaps or whatever" position. In this case you don't need to make any condition. Just use the needle position variable. But I think this is not the case. You will have to look at it.
Step by step!
Arturo.
Hello @ame and thank you!!
will be home to test the code this afternoon...at work right now and report back!.
Thanking both of you and Arturo for all the effort you are putting into this for me...it is greatly appreciated!
Jim
Just came home for a bit and here are what the results were.
I downloaded the script to Arduino (uno)....(ot sure if that makes a difference as Arturo said he tested the code with a nano).
I connected the said gauge wires..one to ground the other to pin 3 (as per script).
Fired up FS9 and the 146 program..booted up link2fs and selected com 1...card 1..and simconnect extractions box as before.
When I manipulated the flaps I could read the values on the traffic monitor but nothing going to the arduino board.
And the gauge needle didn't move a millimeter.
Here are some other observations
Link2fs confirmed FS9 was connected
I did not connect a second power supply to the gauge..only the USB was connected
Is there something else I need to select on linksfs that i might be missing?
Thanks guys!
Jim
First test the arduino part:
Close link2fs
Open Arduino IDE.
Be sure you have selected the correct com port Tools->Port
Open the Serial Monitor window (control + shift + m)
Write in the upper line <G018 and push send. this is the data type that arduino is expecting.
-If works and needle moves, the problem is link2fs related
-If doesn't, the problem is with arduino code, or wiring
Usb power supply is fine. You tested this before.
Arduino Uno and Nano work exactly the same with this sketch.
@_alioth
I am going to do all of that...pretty sure there is something I missed in either the hardware or the software aspect...
Will report back tonight.
jim
i actually have gauge wire (+) set to pin pwm 3 and the other wire i put to ground...does this sound like a viable set up...? maybe it's a simple connection error?
Quote from: Mach7 on August 14, 2023, 10:46:49 AMi actually have gauge wire (+) set to pin pwm 3 and the other wire i put to ground...does this sound like a viable set up...? maybe it's a simple connection error?
+ to pin3
- to gnd
It is ok.
To be sure the wiring is fine, load the Fade example sketch (which worked days ago), change line:
int led = 9; to
int led = 3; upload the sketch and see if needle moves. It should move.
Ok...so some additional info..and I am pretty sure it is a communication problem from the com port to the io board.
a few strange things going on with port com 1.
so when i removed the gauge/ wires/ usb/ arduino and connected it up to my laptop, doing the "ctrl+shift+M" allowed me to enter <G020 and the gauge moved accordingly.
when I went to my main computer to run the same test, it DID recognise the port as com 1, but would not run the test..in other words nothing happened when I hit "send".
So...the programming is sound...the UNO board is sound..the wiring is sound, and the gauge is sound.
Our problem here is the port (I think) 0n the main computer.
I thought that the link2fs monitor was good to go as it was showing me flap register values as the flaps were selected and travelling from 0 to 33 and back to 0...but then of course it would because it is getting its info directly from FS9...has nothing to do with the com port 1.
I tried to select a number of other ports on the link2fs communication page...but none of them will go green except com port 1.
My next step is to connect it to one of my USB (powered) hubs and see what happens..(i have been using one of the spare USB plugins at the back of the computer.
In addition....when I plug the usb into the computer with Arduino connected...i don't get the "happy" connect sound, but rather three abrupt tones...like "buh..buh.buh"
If I plug a usb stick into the same port..the tone is different.
SUCCESS...SUCCESS..SUCCESS
Ok guys...after some troubleshooting I re-installed the drivers for the Arduino board...that is the only thing that made sense to me.
After I did this...it recognised com 3 (not com 1) and I ran the flaps successfully from 0 to 33 and back to 0.
None of my other USB items seem to be affected thus far.
The only thing that the gauge does...that does not happen in the real aircraft, is it acts like a stepper motor...in other words the needle travels fine, but it travels in little movements, lie 05..stop for a millisecond...5 to 10 etc etc...like the hands of a stop watch.
This could be a product of the program as well (QW 146)
Is there anyway to smoothin out the sweep?
Thank you again guys!!!
Jim
i re-read your reply @_alioth
with respect to the needle smoothness....you have already addressed that so i sure there is a fix:)
Great!
Quote from: Mach7 on August 14, 2023, 12:41:28 PMThe only thing that the gauge does...that does not happen in the real aircraft, is it acts like a stepper motor...in other words the needle travels fine, but it travels in little movements, lie 05..stop for a millisecond...5 to 10 etc etc...like the hands of a stop watch.
This could be a product of the program as well (QW 146)
Is there anyway to smoothin out the sweep?
Yes. I anticipated this would happen:
Quote from: _alioth_ on August 14, 2023, 01:47:04 AM2.- Later, (only when Ame code is working for you) a smoother funtion for the needle should be coded. Because in the way the code is written, you only have 30 needle steps. Arduino can make 255 steps so going for 0 to 1 degree in flaps should go 0..1..2..3..4...5..6...7 in pwm.
But now it will go for 0 to 7, so the needle is not going to be very smooth.
This need a little of work. The most important thing is you understand the way to do it. Code will go later.
Now:
You recieved a new position, and move instantly the needle to the new position.
And you only have 33 steps for full range movement.
How to smooth:
You need two variables. 1.- actual needle position 2.- target position
When you receive new data, put the data in target position.
Then, move the actual needle position to target, step by step, with a delay (non blocking delay, because you need the rest of the code working.
If you want to go from 0 to 255 in 5 seconds, then you should move one step every 20 miliseconds.
So, create a nonblocking flag every 20 miliseconds. And every 20 miliseconds move the needle one step from actual position to target position.
There are other ways to do it. But this is quite easy to understand.
If you want to progress, you will need to write and understand the arduino code.
First look for info about non blocking delays. It is a good point to start.
Arturo.
It's morning in New Zealand. Whilst the country was asleep you guys did all the hard work. Thanks!
@Mach7 I think it's important to note exactly how you got to this point and internalise the data flow from the sim to the gauge. Every time you use the sim and change the flaps position all of the elements must be in place: sim working, link2fs working, Arduino driver working (on the same COM port), Arduino working, gauge working. It should be pretty reliable, but as you can see, anything that goes wrong in that path will stop things working.
Regarding the needle smoothing, you will need more code. You can write it yourself (remember to stash a copy of the current working code somewhere so you can go back to it if you get completely lost), or myself or maybe Arturo will suggest some code for you.
If you want to add more gauges then you can have up to six PWM pins driven by the same Arduino. You would have six different variables to record the gauge value, and six different sections of code looking for tags (like "<G") for the other data elements. Then get link2fs to export them.
If you want input from something attached to the Arduino (such as a button or a pot) back into the sim, it's possible. But, one step at a time.
@ame, thanks for all of that.
The only extra thing I would like to include and then the sim if 100 percent finished, are the three fuel gauges...left, center, and right. They two are the same design as the flap gauge.
With respect to flap smoothing...if you could give me a bit of a head start on that I would appreciate it. If it involves just adding values to certain lines, then yes I am comfortable with that.
Right now I am just excited that it is all working...for now I will run all the sub-systems and make sure nothing is being interfered with.
With respect to the fuel gauges, I am assuming this would have to be added to the existing flap code as one long string, then reprogrammed and pin identified.
as Arturo suggested;
1.- The way the serial port is read in those link2fs examples are not the best. It can happen that "if (Serial.available())" sees incoming data, but the data is not complete yet (something like <G0, because de last two numbers 18 have not arrive yet ) and you lose that comnunication.
For this reason, a simple fix is to add a delay before reading the characters when serial.avaliable says there is something to read. In this way you are sure that the incoming data will be complete before trying to read it. (something about 10ms worked fine I remember)
From this I gather a delay code would have to be written before each "serial.available. line is read. would this look something like this, (for each line prior to seral.available ?
delayMicroseconds (10);
Quote from: Mach7 on August 14, 2023, 02:58:35 PM@ame, thanks for all of that.
The only extra thing I would like to include and then the sim if 100 percent finished, are the three fuel gauges...left, center, and right. They two are the same design as the flap gauge.
With respect to flap smoothing...if you could give me a bit of a head start on that I would appreciate it. If it involves just adding values to certain lines, then yes I am comfortable with that.
Right now I am just excited that it is all working...for now I will run all the sub-systems and make sure nothing is being interfered with.
With respect to the fuel gauges, I am assuming this would have to be added to the existing flap code as one long string, then reprogrammed and pin identified.
Ok. Basically you need to start thinking in terms of precisely what is going on in both human timescale (compared to a microcontroller we are glacially slow) and microcontroller timescale (compared to a human they are insanely fast). Also think about basic physics, inertia, momentum, time.
This is the last step before affecting the outside world:
analogWrite(flaps_PWM_out_pin, PWM_out);
At that point a value from 0-255 is written to the PWM module, this causing the GPIO pin to be turned on and off at a certain frequency, with a variable ratio of on period to off period. The effect of this is that the average power transferred from the GPIO pin is 0% of available power to 100% of available power. We know, because we designed it that way, by varying the power transferred to the electromagnetic coil in the gauge we can get it to move anywhere as a percentage of its full range. The mechanical inertia of the coil and spring in the gauge serves to dampen the on/off signal from the PWM module so that it appears to be stable.
Consider the situation where the gauge is at zero, but the sim is at 33 degrees. link2fs sends <G033. Arduino converts this to 33.0, multiplies this by 7.727 to get 254.991, converts it to an integer (not sure if if will round it, so you might get 254, or 255. Doesn't matter. Let's use 255 for illustration) and writes it to the PWM pin. Now the output is 255 which is 100%, which is fully on.
The effect of this is the same as applying 5V from a power supply or battery. The gauge will move to full scale. You can imagine that on a micro timescale it's very slow, because the magnetic force in the gauge coil has to overcome inertia and the spring tension in the gauge mechanism (it's basically a moving-coil Galvanometer). On a human timescale it might appear instead, or quite rapid.
So, to make it slower you have to simulate inertia. Instead of writing a new value directly to the PWM module you have to calculate over time what the needle position should be, based on the elapsed time and the target position. You could use some physics equations and simulate it accurately, or you could fake it.
Arturo already outlined this, but if coding is new to you it might be tricky to know where to start. The key point is that the Arduino loop() function literally goes round in a loop forever. Sometimes it has something to do on any particular loop iteration. Sometimes it has nothing. So your code can do incremental stuff (like moving a needle by a small amount) every time around the loop.
I'll draft some code (faking it, of course. No need for accurate physics) and see how it looks.
For the other three gauges you have to go through the entire process we just did, without making any assumptions. Specifically,
Does the gauge work like a simple voltmeter from 0 to 5V?
Is the gauge scale linear?
Does link2fs have a data element for each of the three gauges?
What is the tag (like "<G") for each gauge?
What is the format of the data following the tag, and what does it represent?
What is, therefore, the relationship between the reported data and the gauge position?
That's basically what we just did.
And yes, the string of data from link2fs will just get longer because it just keeps tacking on whatever elements you choose. There's obviously a practical limit, but you won't hit it.
Quote from: Mach7 on August 14, 2023, 03:09:38 PMas Arturo suggested;
1.- The way the serial port is read in those link2fs examples are not the best. It can happen that "if (Serial.available())" sees incoming data, but the data is not complete yet (something like <G0, because de last two numbers 18 have not arrive yet ) and you lose that comnunication.
For this reason, a simple fix is to add a delay before reading the characters when serial.avaliable says there is something to read. In this way you are sure that the incoming data will be complete before trying to read it. (something about 10ms worked fine I remember)
From this I gather a delay code would have to be written before each "serial.available. line is read. would this look something like this, (for each line prior to seral.available ?
delayMicroseconds (10);
Not sure. It might not be necessary.
I can see why the example code has been written in that way. It's clear, simple, and obvious, but it's inelegant. Doesn't matter, it works.
If you start seeing problems then we could suspect this issue and fix it, or rewrite the code so that the issue does not occur.
Just out of curiosity, if you have flaps at zero, and you drive them to 33 degrees (either with your flaps lever or keyboard or on-screen control) how long does it take for the on-screen simulated flaps gauge to travel from 0 to 33 degrees? An approximation is fine, are we talking one second, 10 seconds, a minute? This will help to make the make the real gauge movement look less fake.
I will boot it up and time it right now...give me 5 mins
It takes 35 seconds from zero to 33 degrees.
Ok. So approximately one second per flap degree.
My guess is that the simulator is simulating a slow movement, and will send intermediate needle positions (i.e. <G000<G000<G000<G001<G001<G002<G002<G003 etc.) but the resolution is only one flap degree, no decimals, so the gauge movement will be a little lumpy.
So currently when the sim goes from 001 to 002 the gauge will jump. We need to feed out some small increments to the needle over one second. It means that the real gauge will lag from the sim gauge, but only slightly.
There are a couple of techniques for this.
Yes...that is totally acceptable
Ok. Here's an attempt. It's not very elegant, but it does two things:
1 Allow the gauge to move only one PWM unit per 0.1 second (or 10 PWM units per second). There are 255 PWM units across the whole gauge range.
2 Jump to whatever the first value is after the Arduino gets turned on.
Hopefully you can see how it works. There's basically two separate parts, and every time around the loop the code decides which part needs to do anything. Either read in from serial and update the value, or trigger every 10th of a second and move the needle closer to the target if necessary.
Quote/*
This code is in the public domain
For use with "Link2fs_Multi"
Jimspage.co.nz (via archive.org)
*/
int CodeIn;// used on all serial reads
String flaps;
int flaps_PWM_out_pin = 3; // Must be one of 3, 5, 6, 9, 10, or 11 for Arduino Uno
// Variables to support incremental update of gauges
unsigned long currentMillis; // store the current time
unsigned long previousMillis;
unsigned long period = 100; // 100millis = 0.1s, 10 updates per second
// Variables for flaps gauge
const int flaps_max_PWM_per_slot=1; // Maximum amount we can move in 0.1s
int flaps_PWM_target; // Target PWM value, based on last flaps degrees
int flaps_PWM_current; // Current PWM value, can only move slowly
bool first_flaps_PWM_value; // Flag to see if we should go directly to target
void setup()
{
Serial.begin(115200);
// Set up PWM pin to drive flaps gauge
pinMode(flaps_PWM_out_pin, OUTPUT);
// Set PWM value to zero.
analogWrite(flaps_PWM_out_pin, 0);
flaps_PWM_target=0;
flaps_PWM_current=0;
first_flaps_PWM_value=true;
}
void loop() {
// Deal with incoming data from link2fs
if (Serial.available()) {
CodeIn = getChar();
if (CodeIn == '=') {EQUALS();} // The first identifier is "="
if (CodeIn == '<') {LESSTHAN();}// The first identifier is "<"
if (CodeIn == '?') {QUESTION();}// The first identifier is "?"
if (CodeIn == '/') {SLASH();}// The first identifier is "/" (Annunciators)
}
// Other tasks
currentMillis = millis(); // store the current time
if (currentMillis - previousMillis >= period) { // check if 100ms passed
// We're on a 100ms boundary
previousMillis = currentMillis; // update the time we were here
if (flaps_PWM_target > flaps_PWM_current) {
flaps_PWM_current += flaps_max_PWM_per_slot;
if (flaps_PWM_current > flaps_PWM_target) flaps_PWM_current=flaps_PWM_target;
}
else if (flaps_PWM_target < flaps_PWM_current) {
flaps_PWM_current -= flaps_max_PWM_per_slot;
if (flaps_PWM_current < flaps_PWM_target) flaps_PWM_current=flaps_PWM_target;
}
else {
// target and current are equal. Nothing to do.
}
analogWrite(flaps_PWM_out_pin, flaps_PWM_current);
}
}
char getChar()// Get a character from the serial buffer
{
while(Serial.available() == 0);// wait for data
return((char)Serial.read());// Thanks Doug
}
void EQUALS(){ // The first identifier was "="
CodeIn = getChar(); // Get another character
switch(CodeIn) {// Now lets find what to do with it
case 'A'://Found the second identifier
//Do something
break;
case 'B':
//Do something
break;
case 'C':
//Do something
break;
}
}
void LESSTHAN(){ // The first identifier was "<"
CodeIn = getChar(); // Get another character
switch(CodeIn) {// Now lets find what to do with it
case 'A'://Found the second identifier
//Do something
break;
case 'B':
//Do something
break;
case 'G': //Found the second identifier ("G" Flaps position)
// Next three characters should be numeric
flaps = "";
flaps += getChar();
flaps += getChar();
flaps += getChar();
// convert 3-character numeric string to a float
// Expected range is 000 to 033
float flaps_degrees = flaps.toFloat();
// Convert degrees to PWM 0-255.
// 33 degrees is full scale, so multiplier is 255/33=7.727
int PWM_out = flaps_degrees*7.727;
// Clip output to maximum if (for some reason) it's >255
if(PWM_out > 255) PWM_out=255;
// New flaps PWM is calculated. Copy to other variables to
// be handled by main loop on next 100ms boundary
flaps_PWM_target=PWM_out;
// If this is the first value we have received, go directly there.
if (first_flaps_PWM_value) {
flaps_PWM_current=flaps_PWM_target;
first_flaps_PWM_value=false;
}
break;
}
}
void QUESTION(){ // The first identifier was "?"
CodeIn = getChar(); // Get another character
switch(CodeIn) {// Now lets find what to do with it
case 'A'://Found the second identifier
//Do something
break;
case 'B':
//Do something
break;
case 'C':
//Do something
break;
}
}
void SLASH(){ // The first identifier was "/" (Annunciator)
//Do something
}
Thanks ame!
Ill give it a go and report back!!
Jim
Hello ame
Much much better!! thank you!
It runs much smoother, still a tiny bit of stutter, but I think if we made it smoother it would slow the gauge down "too" much.
I am very happy with it!!!
I will post a video here shortly.
Jim
Here is the video link;
https://www.youtube.com/watch?v=2wFFUdXCoGY
Excellent! I can see what's up, but I lack the motivation to get deep into the problem. Basically the gauge is allowed to move one pwm unit per 1/10th second, but it should be about 0.8 units. But integer maths is easier than floating point.
If you're happy with it then that's all that matters. I'm glad the code actually works. I did test it, but I didn't know how it would look in reality.
Next, the fuel gauges?
Yes!!! fuel gauges next!!.
I will start the prelim testing with the results on the gauges when I get home on Saturday...leaving today for work again:(
Thank you again for the code ame...i appreciate it!!
Jim
Hey guys...back again after 4 days of work to tackle the fuel gauge project using arduino.
So...i am still in the prelim stages...but it appears these fuel gauges are a lot less than 5 volts...i gently touched the positive probe with a 1.5 battery and it shot off the scale...so I am going to use resistors to get a more accurate value.
I am looking at the 'fade' program..is there anyway to reduce the arduino output voltage through the sketch program...or just attach a resistor to the output pin?
Here are some pics of the gauges...looks like they run from 2 to 7.04 milliamps. Unsure of the resistance to calculate the voltage...so looks like trial and error. Hopefully the former.
Hello again. Glad to see you had some time to work on this.
You can't really reduce the PWM voltage out of the Arduino. The PWM module basically turns the pin on and off very rapidly, from 5V to 0V. The ratio of on time to off time sets the percentage of power transferred to the load. In the case of a moving coil meter, the needle is quite sluggish, so it doesn't flick between zero and fsd. Instead it shows the average power transferred, which is what you want it to do.
For the new gauge let's assume it's a moving coil meter again. And let's assume that 7.04mA represents the fsd. You can use shunts and multipliers to tailor the meter to the desired behaviour. I did this in high school, so I'm a bit hazy on the details, but no doubt there is an online calculator these days...
Thanks ame,
So having understood that Arduino sends out this pulse voltage...could I not do the same with a resistor off the arduino ouput pin?
Ok. You need a multiplier. To calculate the multiplier resistance you need to know the meter's coil resistance. But you could do it by trial and error as you suggested. You could use a pot and the fade program. When the pot is set correctly you could measure the set position and install the equivalent resistor.
Quote from: Mach7 on August 20, 2023, 01:49:35 PMThanks ame,
So having understood that Arduino sends out this pulse voltage...could I not do the same with a resistor off the arduino ouput pin?
Yes. You could calculate it, if you know the meter's resistance, or derive it empirically.
I'll do some testing with the fade circuit and some resistors...I will post when finished.
Update, using 660 ohms of resistance I can connect the 'fade' program up and the gauge will travel to "just about" full travel and back again. It only needs to register 8200 on the dial for full fuel (one tank) and with 660 ohms it travels to the 9k mark.
Quote from: Mach7 on August 20, 2023, 04:15:12 PMUpdate, using 660 ohms of resistance I can connect the 'fade' program up and the gauge will travel to "just about" full travel and back again. It only needs to register 8200 on the dial for full fuel (one tank) and with 660 ohms it travels to the 9k mark.
Excellent. The resistor of the Beast (within tolerance).
So, again stating assumptions, assume that the gauge is linear, and responds to 0-255 values of PWM as 0-100% of full scale, it should be possible to receive the fuel value from the sim and convert it to a PWM value to drive the gauge.
Conveniently, the fuel gauge is marked from 0 to 100, but it seems to me that 0 on the gauge is not at the zero position of the meter. Also, you implied that the needle goes past the topmost marking on the gauge. So, there's a small offset in the maths, and the scale factor is not going to be precisely 2.55.
Incidentally, you stated that the gauge shows 8200 for full scale, and the needle goes to 9000, but the photo shows a gauge with 0 to 100 markings. Are your two gauges different?
Anyway, if you are familiar with the Arduino programming environment you can find the terminal program (icon in top right of the main window). What you can do is modify the fade program so that it prints the current PWM value to the terminal. Then you can make some notes of what PWM value indicates what value on the gauge. This means you can confirm linearity, and derive the maths easily.
I can give you the code for this if you like.
Hello ame,
I mention the 8200 mark due to the fact that the main fuel tanks hold 8120 max (left and right) and the center tank holds a max of 4400 lbs.
Having said that, the gauges go from 0 to 100, but with a full tank of gas they should only read the max capacity of approx 8000 lbs, with the center tank registering something a lot lower at 4400 max, (which is max capacity for the center tank).
In the real aircraft, the center tank gauge is graduated from 0 to 5000k, but will only go to 4400 as that is the max capacity.
Since I don't have a spec gauge for the center tank, I am using a (normal) main tank gauge, and hopefully when the programming is complete will indicate only 4400 lbs when the tank is full of fuel.
I am thinking that, once the code is written to drive the fuel gauges, than the link2fs should be able to do the rest to feed the information directly to Arduino(?). I am assuming we just have to make sure that the gauge can be driven to the 8200 mark, (which it can with the resister intact).
Here are a couple of pics, first the real gauge environment, and the second is the setup I have now, using a main fuel gauge in place of the (real) center tank unit.
Ok, so the gauge is a percentage of full capacity?
i.e. when there is 8120 lbs of fuel present the gauge will show 100?
It should be easy to make the needle point however you like, if you know the relationship between PWM value and needle position, and you know the range of values sent out by the simulator.
Anyway, do you know how to use the terminal in the Arduino programming environment?
The gauge is graduated from 0 lbs to 10,000 lbs (1 to 100)
The gauge is not a percentage of, but rather an actual indication of the amount of fuel, (in pounds) that is currently in the respective tank. (Its a bit hard to read on the gauge itself, but at the bottom in blue letters it says x100).
For example, the gauge could read 3000 lbs, or 6000lbs, but the maximum capacity of said tank (mains) is 8120.
3000 lbs of fuel in the tank would have the gauge indicate at the "30" mark, 6000 bls would indicate the "60" mark, so on and so forth.
With respect to reading the terminal on the Arduino script, I see the serial monitor icon on the top right of the screen. I have never done it before, but I am assuming it will give me a bunch of values as the fade program works with which I will copy and paste for reference?
.
Ok. I understand. I did not see the x100 indicator.
So, the fade program sends PWM values from 0 to 255. What you are saying is that the maximum you see with the chosen resistor is 9000, and the maximum your plane can hold is 8120 therefore it is not necessary to calibrate the resistor to allow the needle to get to 100?
If that is the case, I understand now.
Back to serial. The Arduino can be a standalone device, but the USB port appears as a serial port. This means that as well as programming the Arduino over the serial port you can also send and receive data. If the Arduino is standalone it doesn't matter. But if the Arduino is connected to something then data can go back and forth between the Arduino and what it's connected to.
In the case of the flight simulator the Arduino communicates serially with link2fs, which itself is connected to the simulator. But you can also send and receive data manually through the terminal, which is great for interacting with something on your Arduino, or for debugging.
In the setup() part of the fade program you can start the serial port:
Serial.begin(115200);
In the main loop of the fade program you can print out the current value of the PWM, which you will see on the terminal:
Serial.println(fadeValue);
You probably want to increase the loop delay to slow everything down so you can see the correlation between PWM value and needle position.
So your code will look something like this:
Quote/*
Fading
This example shows how to fade an LED using the analogWrite() function.
The circuit:
- LED attached from digital pin 9 to ground.
created 1 Nov 2008
by David A. Mellis
modified 30 Aug 2011
by Tom Igoe
This example code is in the public domain.
https://www.arduino.cc/en/Tutorial/Fading
*/
int ledPin = 9; // LED connected to digital pin 9
void setup() {
Serial.begin(115200);
}
void loop() {
// fade in from min to max in increments of 5 points:
for (int fadeValue = 0 ; fadeValue <= 255; fadeValue += 5) {
// sets the value (range from 0 to 255):
analogWrite(ledPin, fadeValue);
Serial.println(fadeValue);
// wait for 500 milliseconds to slow down the printing rate
delay(500);
}
// fade out from max to min in increments of 5 points:
for (int fadeValue = 255 ; fadeValue >= 0; fadeValue -= 5) {
// sets the value (range from 0 to 255):
analogWrite(ledPin, fadeValue);
Serial.println(fadeValue);
// wait for 500 milliseconds
delay(500);
}
}
Now, download this program to the Arduino. When it's done, click on the terminal button. Something should happen.
Take a note of the reported PWM value at key points on the gauge. There should be a linear relationship between PWM and gauge position. And the "zero" position might not be at PWM 0.
You are correct, it is not necessary to calibrate the resistor to ensure the gauge goes to "100", due to the fact that I only need it to go to slightly above "80", or in other words 8120.
I will download this program and report back.
Jim
Hi,
Why not using a multiturn pot?
(https://encrypted-tbn0.gstatic.com/shopping?q=tbn:ANd9GcRI9ePbulFZyOTZ_QdLYLwLN1KuIe8HVcgS0oTBVQ0ik9KfZinOF0fsRB49YfTB2ibu_OEvjLbk3lXg5T0mr5Z1rbLDtlPEwsxOqn86k9YNNKSoe5MZB61BlA&usqp=CAc)
If you get about 100% range with a 600ohm, just use a 1k multiturn pot in series.
The you can setup to achieve de max value you want (10.000 ot 8000 or whatever you want), sending 255 pwm output and turning screw to get that value.
Later, code everything knowing 255pwm gets that max value you want.
One advantage is you can calibrate the needles in future without coding.
This is the way I use for my galvanometer gauges:
Gauges.jpeg
multiturnPots.jpeg
About the code, there is a very useful function in Arduino:
pwmValue = map( SIMNeedleValue, needleValueMin, needleValueMax, minPwm, maxPwm);
needleValueMin = 0
needleValueMax = 8000
minPwm = you need to find this value, testing the gauge, as Ame already suggests.
maxPwm = 255
This works great if the movement is lineal but there is no 0,0 in origin..
If the scale or movement is not lineal, then I like finding a function that fits all values range. I use excel or www.mycurvefit.com
then you can limit values with constrain
pwmValue = constrain (pwmValue, 0, 255);
And in case there is no main bus voltaje, the needle is not in 0, but full left (no voltage).
If (mainBusVoltage < MINVoltage) pwmValue = 0;
Then write the pwm value:
analogWrite (FuelGaugePIN, pwmValue);
Arturo.
Thanks Artro,
This puts an interesting idea into the mix. I like the multiturn post install and I actually might have one in my electrical junk box. I will look today.
So basically are you saying if I can get the needle to move through it's full extent I could avoid trying to find the in between values so the gauges maintain accuracy with fs9 (fuel qty) inputs?
In other words, with the resister installed, I am getting 90 percent of the needle movement using the "fade" program, and because of this, the values will have to be manipulated in the code to accommodate the (link2fs) fuel qty inputs (?). If the code is not modified then when the (FS9) fuel quantity indicates 4000 lbs then the gauge may (will) read something different (?).
Am I close or correct in this assumption?
Jim
@ame,
I downloaded the program and ran the gauge. I tried selecting the serial plotter and monitor, both through the icon at the top right corner, and through the tools menu. It did not display anything.
Regardless, this program seems to show the gauge going to full travel now with the resister(s) installed.
Here is a clip, (running the program created by David Mellis).
https://www.youtube.com/watch?v=BeX5Hp5oCZA
I will keep trying to find the data...not sure why I cannot read the monitor.
Quote from: Mach7 on August 21, 2023, 03:00:10 AMSo basically are you saying if I can get the needle to move through it's full extent I could avoid trying to find the in between values so the gauges maintain accuracy with fs9 (fuel qty) inputs?
In other words, with the resister installed, I am getting 90 percent of the needle movement using the "fade" program, and because of this, the values will have to be manipulated in the code to accommodate the (link2fs) fuel qty inputs (?). If the code is not modified then when the (FS9) fuel quantity indicates 4000 lbs then the gauge may (will) read something different (?).
Am I close or correct in this assumption?
Jim
What I say is it is a good idea to have the multiturn pot because:
1- you can set the 255pwm output to the value in the gauge you want. it would be normal to have it at 100% of the range of the gauge.
2.- you can calibrate the gauge in future if you need, without change and upload the code again. I have seen multiples professional Frasca cockpit gauges and all of them have a pot to calibrate them.
But you must look for the correlation beetwen pwm output and values.
The way I do this is.
I code the sketch in a way I send a value from 0 to 255 in the serial monitor, and analogWrite the value in the gauge pin. (this is what Ame is saying you to do). It can be done using the same type of data you will have to code in future. (or a new sketch that just only received the number and write it in the analogWrite, or a sketch that does is automatically and you read the data in serial monitor, as Ame suggest. For example:
<H000
<H012 (as example, looking for a value that indicates 0 in the gauge)
<H100
<H150
<H200
<H255
Then write these values in the analogWrite and make a chart with the value in the needle with your pwm values:
PWM - Gauge
12 __ 0
50 __ 1.550
100 __ 3.600
150 __ 5.700
255 __ 10.000
You can use the values you want, just note the correlation and make a chart.
Then go to mycurvefit or excel or whatever you want to find the function that works with this correlation:
mycurve03.jpg
mycurve04.jpg
This chart fits a line, and mycurvefit says the function is PWMoutput = 0.02426791 * fuelReadinSIM + 12.12281
Then, use the function in your code:
PWMoutput = 0.02426791 * fuelReadinSIM + 12.12281; // the function we found to correlation gauge value and pwm
PWMoutput = constrain (PWMoutput, 0, 255); // making sure we don't write out range.
if (there is no voltage in master bus) PWMoutput = 0; //if there is no voltage in master bus, we want the needle to be dead.
analogWrite (gaugePIN, PWMoutput); // output the analogwrite to move the needle
The beauty of this, is you can find very complex correlations (second or third degree curves) and you resolve the problem with just one line in the code.
The most important thing now is you understand the way everything works so you can code whatever you need in your sim. Or if Ame takes holidays.. ;D
Arturo.
Thanks for the info Arturo,
I am still having some difficulty getting the info from the serial monitor...so until I do that I will not know the variables.
Going to try and re-install the drivers...maybe that is the issue.
Jim
Here is some information about the serial monitor tool.
https://docs.arduino.cc/software/ide-v2/tutorials/ide-v2-serial-monitor
It's unlikely that you need to reinstall any drivers. More likely that I made an error in the code I gave you. I didn't actually test it, and I can't test it right now. Maybe later.
It's also possible that the baud rate in use is incorrect. There is a drop-down box at the bottom of the serial monitor. The baud rate must match the rate specified in the Arduino program. In this case 115200.
Quote from: Mach7 on August 21, 2023, 07:59:51 AMThanks for the info Arturo,
I am still having some difficulty getting the info from the serial monitor...so until I do that I will not know the variables.
Going to try and re-install the drivers...maybe that is the issue.
Jim
Can you post a pic of the Serial monitor window?
2 critical points:
-Select the correct com port in IDE menu
-Choose in the serial monitor the same baud rate you have written in the code
In the Ame code:
void setup() {
Serial.begin(115200);
}
So, be sure you select "115200" in the serial monitor window
@Arturo,
I figured it out!
I will run some values and post here in a bit...i am assuming we are looking for the 0-255 values that correspond with the needle location?
Jim
Yes. Watch the output on the serial monitor, and watch the gauge. Make a note of the reported value for each graduation on the gauge scale, i.e. 0 to 10.
Then you can establish a formula for the relationship between PWM value and where the needle is pointing.
Ok guys, here are my values..I also have a link to the video I took when tabulating the numbers;
I found the needle remains below zero until a value of "75" is reached on the serial monitor as it is increasing. at this point (75) the needle on the gauge then moves to the "0" mark...(or at least this is when the power is sufficient to move the needle to zero).
I found some variances in value from needle increase to decrease, there might be a couple of reasons for this, it may be due to my tabulation speed, or, due to the lag of the needle going up or down...hard to say. Like I said, I will publish a link to the video, and if there is any question on my math then this link should clear it up.
Here are the values as the needle is INCREASING;
Needle / Monitor value
0 = 70
10 = 95
20 = 115
30 = 130
40 = 150
50 = 170
60 = 190
70 = 210
80 = 230
90 = 250
95 = 255 (gauge needle does not go all the way to 100
mark due to resistor installation).
Here are the values with the needle DECREASING. Note I found some variances at the higher numbers, but they seemed to (somewhat) sync in alignment with the increasing values around the (gauge needle) 60 mark.
I have identified the values that differ from the increasing numbers with an asterisk.
95 = 255
90 = 245 *
80 = 225 *
70 = 205 *
60 = 190
50 = 170
40 = 150
30 = 130
20 = 110 *
10 = 90 *
0 = 75
Here is the link to the video;
https://www.youtube.com/watch?v=yrbliurCPhI
put a longer delay (2000 or something like that), because Im not sure the coil+neddle are fast enough to the 500 milis delay, and it could be the reason to read different values going up and down.
oK, will do
Increasing the delay from 500 to 2000 on the program allowed me to obtain some more accurate numbers..especially at the higher values.
I found as the needle is decreasing it would land at exactly the 90..80..70..and 60 marks on the gauge which gave me a confirmation that the decreasing values were the most accurate.
so..
Increasing and decreasing values are exactly the same,
to review following the increase in delay code, here are the solid values;
0 = 75
10 = 95
20 = 110
30 = 130
40 = 150
50 = 170
60 = 190
70 = 205
80 = 225
90 = 245
95 = 255
You could test this code:
Then just write in the Serial monitor
A=0 (send, or enter) to send pwm 0 to pin 9
A=100 (send, or enter) to send pwm 100 to pin 9
etc...
In this way you can send a pwm value, look peacefully the needle and note the needle value.
Quote#define MAX_STRING_LEN 32
String cadenaCharEntrada = "";
char vectorChar[MAX_STRING_LEN];
bool finCadena = false;
int pwmPIN = 9;
void setup() {
cadenaCharEntrada.reserve(MAX_STRING_LEN);
pinMode(pwmPIN, OUTPUT);
Serial.begin(115200);
}
void loop() {
if (finCadena) {
finCadena = false;
cadenaCharEntrada.toCharArray(vectorChar, MAX_STRING_LEN);
String key = subStr(vectorChar, "=", 1);
int value = atoi(subStr(vectorChar, "=", 2));
int value2 = atoi(subStr(vectorChar, "=", 3));
cadenaCharEntrada = "";
if (key == "A") {
analogWrite(pwmPIN, value);
}
}
// do things
} //loop end
void serialEvent() {
while (Serial.available()) {
char CaracterEntrada = Serial.read();
cadenaCharEntrada += CaracterEntrada;
if (CaracterEntrada == '\n') {
finCadena = true;
}
}
}
char* subStr (char* str, char *delim, int index) {
char *act, *sub, *ptr;
static char copy[MAX_STRING_LEN];
int i;
strcpy(copy, str);
for (i = 1, act = copy; i <= index; i++, act = NULL) {
sub = strtok_r(act, delim, &ptr);
if (sub == NULL) break;
}
return sub;
}
So with values you noted:
0 = 75
10 = 95
20 = 110
30 = 130
40 = 150
50 = 170
60 = 190
70 = 205
80 = 225
90 = 245
95 = 255
I have gone to mycurvefit, and they are quite lineal:
OMuqs0c.png
and the function you need for your code is:
pwmValue = 1.893 * FuelSimValue + 74;
so... for every each value of needle (from 0 to 95), you get the correct pwm value from this function.
Ok...will try that as well...thanks!!
they are all giving me the same values...
Quote from: Mach7 on August 21, 2023, 10:38:26 AMthey are all giving me the same values...
I suposed that, but you can test every value you want taking all the time you need. And the code can be quickly mod to add more gauges, so:
A=100 means pwm 100 in pin 9
and with a few lines B=120 sends 120 to pin 10....
etc..
Look..
Just with these few lines you can connect two gauges, and test both, one sending A=xxx and the second one sending B=xxx
Quote#define MAX_STRING_LEN 32
String cadenaCharEntrada = "";
char vectorChar[MAX_STRING_LEN];
bool finCadena = false;
int pwmPIN = 9;
int pwmFuelLeftPIN = 10;
void setup() {
cadenaCharEntrada.reserve(MAX_STRING_LEN);
pinMode(pwmPIN, OUTPUT);
pinMode(pwmFuelLeftPIN, OUTPUT);
Serial.begin(115200);
}
void loop() {
if (finCadena) {
finCadena = false;
cadenaCharEntrada.toCharArray(vectorChar, MAX_STRING_LEN);
String key = subStr(vectorChar, "=", 1);
int value = atoi(subStr(vectorChar, "=", 2));
int value2 = atoi(subStr(vectorChar, "=", 3));
cadenaCharEntrada = "";
if (key == "A") {
analogWrite(pwmPIN, value);
}
if (key == "B") {
analogWrite(pwmFuelLeftPIN, value);
}
}
// do things
} //loop end
void serialEvent() {
while (Serial.available()) {
char CaracterEntrada = Serial.read();
cadenaCharEntrada += CaracterEntrada;
if (CaracterEntrada == '\n') {
finCadena = true;
}
}
}
char* subStr (char* str, char *delim, int index) {
char *act, *sub, *ptr;
static char copy[MAX_STRING_LEN];
int i;
strcpy(copy, str);
for (i = 1, act = copy; i <= index; i++, act = NULL) {
sub = strtok_r(act, delim, &ptr);
if (sub == NULL) break;
}
return sub;
}
Would this be what the code would somewhat look like, then controlled by link2fs?
If that is the case then A would could equal the left fuel gauge, B the center, and C the right fuel gauge(?)
It could be quite similar
It accepts "A", or "<A", or whatever you want.
And it takes the number, it does not matter if it is one, two or 3 digits...
but:
-Link2fs does not send a \n (enter) after every send value. I think It can be done in the main page where you connect Arduinos, but I am not sure. This code needs a (enter) after every sent value. Can you test this?
-my code needs a "=" between the characters and number, and link2fs does not send this "="
So, some mods would be needed to work with link2fs.
I can not use link2fs now, so I can not test..
I can try in future, but Ame code based in link2fs examples works, so..
Arturo
The <enter> can be sent in every command with this I think:
return.png
oK...i am going to wait for ame to come back online and look at our discussions....we have made quite a bit of progress so far with the values...all the gauges should work the same and now that we have confirmed they are linear. My assumption is that it should be quite straight forward, (for you guys anyway) when we are talking about coding, and connecting. Link2fs should be able to supply the data needed from fs9 to display the left, right, and center tank quantities with all three gauges using various outputs form arduino.
I think we can connect all 4 gauges up as well, (3 fuel gauges and one flap gauge), by adding code to the flap program(?)
yes.. arduino Uno has 6 pwm capable pins (3,5,6,9,10,11)
So you can connect until 6 galvanometer type gauges in the same way you have seen.
You will have to send data from link2fs of:
-3 fuel gauges
-flap gauge
-Master bus voltage!!! Remember, you will want to kill those needles if there is no bus voltage in the plane!!
Also, for what i can see...link2fs has only these three box selection options for fuel quantity...
"x" for the left tank in percent
"Y" for the center tank in percent
"z" for the right tank in percent.
Just to make sure I went into the fs9 menu, (QW 146) and you can enter your fuel load either in percent or total pounds. With this information I am sure the output will convert to pounds for display on the gauges...pretty sure this is what jim...the link2fs developer had in mind.
You mentioned bus voltage...once the sim is powered down, and surge bars selected off, all the needles will go to zero as the boards no longer will have power.
Is there a precaution here I should be worried about re gauge life?
If you run the simualtor and qw146 you can see in link2fs which values are you sending, if they are percent or pounds or whatever.
The chart we made before must be done with these units, because they are the units Arduino will receive.
There are some quite complex addons that don't use standard simulator variables. They use some custom variables (called Lvars) and link2fs can not read them in an easy way. It is not the moment to open this can of worms. But if you can't find some variable, you must know that probably it is a Lvar and a total different story.
A2A comanche (the software in my cockpit) use a lot of Lvars... and this was the main reason I migrate everything from link2fs to my own lua scripts in fsuipc. Link2fs and Lvars are a nightmare to manage.
But you are interfacing fuel levels and seems link2fs seems to read the fuel correctly in the qw146. So qw146 is using standard variables here.
Quote from: Mach7 on August 21, 2023, 11:53:23 AMYou mentioned bus voltage...once the sim is powered down, and surge bars selected off, all the needles will go to zero as the boards no longer will have power.
"boards" mean Arduinos here?
If the answer is yes.. imagine this situation:
You have all power switches on, but the aircraft batteries are empty:
-In your Fs9, needles will point to 0 (no energy to drive the gauges)
-In your cockpit, the needles will indicate the fuel level, because you have switches powering on the arduinos and they read the fuel level..
If you power on and off Arduinos with power switches, you may lose synchronization arduino-simulator. You stop the com ports and you will have to power on each arduino in link2fs again.
Your Arduinos shoud have power all the time, and drive the needles with simulator information (in this case.. fuel level and enough voltage in the gauge bus).
Arturo.
Yes...in my sim setup once the computer is powered up then the arduino boards will be powered as well through usb com port 3...well before the fs9 or qw 146 boot up.
I think that would be acceptable to prevent gauge damage (?)
Then if you are in a cold and dark situation in qw146... your arduinos are power on. aren't they?
Yes for sure...i am deriving the power from the 5 volt usb port, so once the computer is "on" the port will supply the necessary power.
WHen I shutdown the qw 146 sim...exit fs9..the arduino is still showing that it has power..up until I shutdown the computer.
Quote from: Mach7 on August 21, 2023, 02:22:55 PMYes for sure...i am deriving the power from the 5 volt usb port, so once the computer is "on" the port will supply the necessary power.
So... in a cold and dark situation, qw146 fuel gauges will indicate 0. This is correct.
But your hardware cockpit, will indicate the fuel level, because arduino receives fuel level in the plane. And this is not correct.
In a cold and dark situation, your gauges should indicate 0.
So... in a cold and dark situation, qw146 fuel gauges will indicate 0. This is correct.
But your hardware cockpit, will indicate the fuel level, becasue arduino receives fuel level in the plane. And this is not correct.
In a cold and dark situation, your gauges should indicate 0.
Yes...of course they will. they will read zero until the cockpit is powered up...or rather qw 146 is powered up, (batteries on). Regardless of this fact the Arduino board is still receiving power from the usb port if the computer is on....
I think we are talking about the same thing (?)
are you sure will they read zero?
The variables you are reading in link2fs are tank fuel level. Real fuel level. They don't indicate needle gauge level, but tank fuel level.
So, even in cold and dark situation, the fuel level is fuel level, and your gauge will indicate the fuel level, and not zero.
Can you confirm variables fuel level go to zero in link2fs when power off the aricraft? This wasn't in this way in my link2fs days with the aircrafts I interfaced..
ok...well...i don't know yet because I have not hooked the fuel gauges up...not close to that stage in the game at this point.
I do know that I have to boot link2fs up in order for it to interface, so I am thinking that once fs9 is online, the gauges will still indicated zero until link is up and running...but I am of course speculating as I do not, or have not, connected the gauges up as of yet.
Quote from: Mach7 on August 21, 2023, 02:31:27 PMSo... in a cold and dark situation, qw146 fuel gauges will indicate 0. This is correct.
But your hardware cockpit, will indicate the fuel level, becasue arduino receives fuel level in the plane. And this is not correct.
In a cold and dark situation, your gauges should indicate 0.
Yes...of course they will. they will read zero until the cockpit is powered up...or rather qw 146 is powered up, (batteries on). Regardless of this fact the Arduino board is still receiving power from the usb port if the computer is on....
I think we are talking about the same thing (?)
What Arturo is alluding to is that the code in the Arduino should be looking at
two data elements. Link2fs needs to export the fuel data (or flaps data) and the power up status of the aircraft. In the Arduino code you can look at the power up status. If the aircraft is off then you can drive the needles to the rest position (thus simulating the power down status). If the aircraft is on then you can drive the needles to their actual position.
It's a very slight increase in complexity, but adds to the sense of realism. It can be added later, if you want.
Ok...i understand now.
I was worried that there may be some damage the gauges due to the scenario he was explaining.
The order should be:
- power up pc, so arduinos are alive.
- enter simulator an load the qw 146
- start link2fs and push connect.
I understand you becasue you are thinking in the needle of the software.
But you are reading a variable that tells you how many fuel is in the tank, not the needle position in the software.
And they are different things.
It is not the most important thing now. But you will have to deal with it, and this is the reason I talk about bus voltage.
I didn't want to sound rude. I'm just trying to help!
Arturo.
With the qw 146 software, there is a program called "qw dispatcher'. before you boot up fs9, you can basically calculate the required fuel load and wt and balance..(pax cargo etc) for all of your weights.
Once the fs9 qw 146 aircraft is online...then the fuel gauges will indicate what you previously set in the "qw dispatcher'.
My start up would have me bring link2fs online following qw 146 program...not sure what the gauges would read, but according to you guys they will probably read the requested fuel load, regardless if they read zero in the aircraft (sim program) or not.
If this is the case, then it would be more than realistic for this type of aircraft as the fuel gauges will read tank levels under two conditions when the aircraft is powered down (cold and dark).
The first scenario is when the refuel panel switch is selected "on" at the pressure refueiling location, (right side of the wing leading edge). This will allow the aircraft to be fueled without power on the aircrat...it will also make the fuel gauges come alive in the aircraft.
The second scenario is whenever the fuel quantity switch is selected in the flight deck..you can read the total fuel quantity, (gauges come alive) without turning the batteries on.
@Arturo,
You don't sound rude at all...i actually appreciate the information and anything you can clarify the better.
I guess I just want to make sure I am not going to damage these gauges by doing something dumb.
so to that point....if for example my startup is as you outlined
1, computer on...arduino board alive
2. boot up fs9/qw 146
3. connect link2fs
now say the fuel gauges run to full fuel...then settle down to whatever fuel load I re enter...will this damage the gauges ?
You can tell what the gauges are going to do by looking at the link2fs output window. In fact, we need to do that next. Just like the flaps position was sent as "<Gnnn", where nnn is a three digit value representing flaps angle, you need to know how link2fs sends fuel data. You can start with one gauge, but you need to know the tag (similar to "<G"), the format of what follows (similar to "000", or "012", but probably more characters), and what it represents (e.g. angle in degrees, with leading zeros, and a range of 000 to 033).
@ame, yes...by tags I believe you are referring to the check boxes in link2fs.
I have already mapped those out as "x" "y" and "z"
x being the left main tank, y the center, and z the right main tank,
also the format that link uses seems to be in percent...so not sure what that would look like after <x (y) (z).
Right now I am trying to find an opensource code relating to fuel gauge that we can use as a template....so far no success.
Fuel gauges are more likely to damage the arduino than the other way.
You can't send a pwm value bigger than 255 (even if you try). And even 255 is not enough to go to 100% range in the gauge.
Your gauges are safe.
Thanks Arturo!
I can think of two ways to damage the gauges. First is to apply too large a voltage. The Arduino can only supply 5V, and you have a current limiting resistor in place, which is set to allow fsd at 5V. So, the gauge is safe for any output from the Arduino, up to its maximum.
The second is to have some software that sends full on and full off voltages to the gauge, causing the needle to peg at the top and bottom of its range. Technically that's how PWM works, but it's very fast so the needle can't respond, and instead shows the average voltage. But if you slowed it down to once a second or so you might get some mechanical damage. You're not going to do that on purpose, and it's unlikely that the Arduino software would "go wrong" and do that, so it's not a worry.
More creative people could probably think of more ways to damage the gauges, but in general they'll be fine.
Quote from: Mach7 on August 21, 2023, 03:14:54 PMRight now I am trying to find an opensource code relating to fuel gauge that we can use as a template....so far no success.
No need. We can just write it.
Ok great!
Quote from: Mach7 on August 21, 2023, 03:12:21 PM@ame, yes...by tags I believe you are referring to the check boxes in link2fs.
I have already mapped those out as "x" "y" and "z"
x being the left main tank, y the center, and z the right main tank,
also the format that link uses seems to be in percent...so not sure what that would look like after <x (y) (z).
Ok. So in the link2fs output window if you have checked the box for only one fuel gauge you should see <xsomething
Is "something" just a string of digits? How many? What values do you see if the fuel tank is empty, full, and some points in between?
Later you can turn on flaps and all three gauges and you will see <G000<xsomething<ysomething<zsomething. This will all go to one Arduino, which can split up the data and drive four gauges on different pins.
ok...i am going to run link2fs and see the values and report back.
I forgot that if I check those boxes i should see some data going out...at least I think i should.
Ok...just ran qw 146 (FS9) and check marked the fuel gauge percent boxes, (x) (y) and (z).
it seems that link2fs sends out the information to arduino as a "percentage"...so 10 percent fuel would look something like this <X010 which would equate to a conversion to 'pounds' on the gauge.
so the monitor would read something like <X088, <Y099, Z088 this would display as full fuel load, (left main tank 8120, center tank 4400, and right main tank at 8120 for a total fuel load of 20640lbs)
Now here is the rub...
The qw 146 platform displays maximum wing tank capacity as 9200 lbs (9192.7) due to the fact that they assume you may one day pay for the upgrade of the installation of extra fuel tanks which feed into the main tank but register on one gauge. These "exta" fuel tanks increase the main tank capacity by 1000 lbs per side. Therefore a 100 percent setting on the fS9 drop down menu equals 9192.7 lbs.
I do not have this option, so if I try and put 100 percent in the FS9 drop down menu, it will give me an alert that I have exceeded the maximum fuel tank capacity or 8120.
so as you can see, the percentage that is placed in the FS9 drop down menu (fuel and payload options) is a percentage of 9200..therefore full tank capacity of 8120 is 88 percent set..(9200 x 88% = 8096..or approx full fuel)
The center tank is the center tank....it holds 4400 pounds maximum so 100 percent is equal to 4400..(in actuallity i have to put a value of 99.9 percent or else I will get a warning that I have exceeded the center tank fuel by 1 or 2 pounds.
If I select qw 146 dispatcher program BEFORE booting up FS9 i can select 100 percent fuel load on the sliding scale...however when I boot qw 146 program and look at the fuel load under "change fuel and payload" drop down menu, it will show 88 percent on the mains, and 99.9 percent on the center.. (88 percent = 8120 lbs of fuel, 99.9 is a bit less than 4399). and everything is fine.
Ok. It's not a problem. Ironically for this kind of thing you have to think inside the box. In this case, imagine you are the Arduino. You get three numbers. That's it. You have to convert those three numbers to needle positions.
At this moment in time your simulator configuration is fixed, so you have to work within the restrictions you have.
What you are saying, I think, is that you will never see a value of 100 for your left/right tanks? Instead, the largest value you will see is 088. Is that right?
Yes...that is correct...in fact..there is no way the system will let me go above that value,therefore there is no way I could 'hurt' or damage the gauge.
Quote from: Mach7 on August 21, 2023, 04:49:37 PM...therefore there is no way I could 'hurt' or damage the gauge.
I think this sentence means you don't understand yet how the system you are building works. And I want to help you.
Why are you thinking the gauge is or not safe depeding on simulator variables values? I am interested in your thoughts in order to help you understand the system.
@Arturo,
Probably not the best sentence to use on my behalf. I think I am just reinforcing the fact that...if program was written in a way that allowed variables above the maximum limit, (which it won't be),and for some reason I in inadvertently entered a value of 110 or 120 percent fuel. The FS9 program would see that as an aircraft exceedence in fuel quantity and not allow that value to be pushed through link2fs to the gauge and possible exceeding the needle authority.
@ame. With respect to the code, would it be prudent to run a test code on one gauge before we include the entire string of gauges under one script?
Quote from: Mach7 on August 22, 2023, 05:05:43 AM@ame. With respect to the code, would it be prudent to run a test code on one gauge before we include the entire string of gauges under one script?
Yes and no. Once the operation of the gauge has been understood it can be incorporated into the other code running on the Arduino. Although the Arduino is running only one program it's very compartmentalised, so the section that drives one gauge is independent of the others. Even link2fs can be configured right now to export all the data that will be needed for all four gauges. The current code will ignore anything except the data that is tagged to mean flaps.
Ok, i understand. Do you need anything additional from my end with regards to values?
I see.
Part 1:
We'll think about it the other way around. Think only about the Arduino first and forget about the fs9/link2fs.
The arduino pin can send 0v when the state is LOW. And 5v when the pin is HIGH (HIGH is the maximum that Arduino can send through the pin).
You have already tested that when you send 5v, the fuel gauge is not damaged. It doesn't even reach the top of the scale. So... there is nothing you can do inside the Arduino code to make the needle go beyond the limit.
You cannot physically send more than 5v (HIGH) from an Arduino UNO pin.
Whether you get a value from the simulator that says 1, 100, or 10000, you can't send more than 5v through the pin.
Part 2:
We don't want the needle to be only in the rest position and in the maximum position. We want intermediate positions.
This is what PWM is for.
Although it is not quite correct, for now you think that with pwm we can send from 0 to 5v, in 255 intermediate steps.
But we can't send less than 0, nor more than 5v. Even if we want to, we can't. Physically we can't. There is no more than 5v on the Arduino pin.
The important thing here is that we can send 255 possible positions between the minimum of 0v and the maximum of 5v.
Part 3:
This is where we receive data from the simulator, no matter what the values are. We need to know the total range, and that's why Ame asks you what numbers you see link2fs sending in reference to the fuel. We convert those values to the different steps between 0v and 5v. But again, even if we want to, or if we miscalculate, we cannot send less than 0v, nor more than 5v. Physically you can't.
What we do is to convert the fuel values (in this case they seem to be from 0 to 100) into pwm values from 0 to 255, so that the needle matches in the software and in our cockpit.
When we find the correlation, both needles will be synchronised.
So... there is no value that you can receive from link2fs... that can damage the fuel gauge... are you understanding why?
It is the basis for programming any gauge.
I do understand, thanks for the clarification.
Quote from: Mach7 on August 22, 2023, 05:26:15 AMOk, i understand. Do you need anything additional from my end with regards to values?
Actually, I'm not sure where we're at.
I think I'd like to review two things.
1) We have established that the fuel gauge reaches fsd at much less than 5V. You installed a 660R resistor as a multiplier (and to protect the gauge), but you no longer got fsd. You then replaced it with a multiturn pot, but the needle only hits 95. Is that right? I'd really like to fix it so that 100% PWM hits 100 on the gauge.
2) We have established that link2fs sends a number for the left, centre, and right tanks:
"<X" for the left tank in percent.
"<Y" for the center tank in percent
"<Z" for the right tank in percent.
These values are sent as three numeric characters 000 to 100.
The gauge face is marked 0 to 10,000lbs (as 0 to 100 x100lbs), and the left and right tanks hold 8120 lbs of fuel. Therefore if link2fs reports <X100 it means 100% fuel in the left tank, so the gauge points to 81.2? Further to this, the centre tank has a capacity of 4400 lbs, so when link2fs reports <Y100 it means 100% fuel in the centre tank, so the gauge points to 44?
I'm going to ignore the extra 1000 lbs fuel tank that you don't have, and concentrate on the current configuration. If you add the upgrade later you will have to edit the Arduino code because 100% will mean something different.
I should have made two posts with these questions, sorry. Feel free to answer in two different replies.
Hello ame,
1) We have established that the fuel gauge reaches fsd at much less than 5V. You installed a 660R resistor as a multiplier (and to protect the gauge), but you no longer got fsd. You then replaced it with a multiturn pot, but the needle only hits 95. Is that right? I'd really like to fix it so that 100% PWM hits 100 on the gauge.
That was a suggestion by Arturo, but I never installed the pot...i still have the resistors in place. With the resistors in place the gauge goes to "just" about full scale..on the fade program it goes up to 95 to 96 out of 100...100 being full scale. I could probably make adjustments to have it go right to 100 if it is absolutely necessary.
2) We have established that link2fs sends a number for the left, centre, and right tanks:
"<X" for the left tank in percent.
"<Y" for the center tank in percent
"<Z" for the right tank in percent.
These values are sent as three numeric characters 000 to 100.
This is correct.
The gauge face is marked 0 to 10,000lbs (as 0 to 100 x100lbs), and the left and right tanks hold 8120 lbs of fuel. Therefore if link2fs reports <X100 it means 100% fuel in the left tank, so the gauge points to 81.2?
Yes,..(sort of). If I use the FS9 drop down menu and put a value of "100" percent it will tell me that I have exceeded the fuel load. If I put "88" percent, the tank will read 81.2. When I note the link2fs monitor..it too shows a value of <X088. The resaon for this is the values are a percentage of 9200 pounds not 8120 pounds...just the way the sim is set up....so 88 percent of 9200 is approx 8120.
Further to this, the centre tank has a capacity of 4400 lbs, so when link2fs reports <Y100 it means 100% fuel in the centre tank, so the gauge points to 44?
Yes, this is correct..but again, i have to put a value in of 99.9 or the program will tell me I have exceeded the fuel capacity by 2 pounds. I have not tested it..but I am confident that the monitor would show <Y099
I'm going to ignore the extra 1000 lbs fuel tank that you don't have, and concentrate on the current configuration. If you add the upgrade later you will have to edit the Arduino code because 100% will mean something different.
I will never add the upgrade later...most 146 variants did not have this extra fuel anyway.
Thanks for clarifying things. I think that's everything, but I'll state my assumptions every time so please stop me if I make a mistake.
It's not critical for 100% PWM to cause the needle to hit fsd, but I assert it will make a bunch of future headscratching disappear if you don't have to remember why you didn't do it the first time around. If I can convince you to do it then please do. Unfortunately it means you can't just pick up three identical resistors, one for each gauge. Instead you'll have three identical pots, but each one must be adjusted until it's correct. Actually, you can do it any way you like, if you choose to do it.
It also means that the table you made for PWM to gauge reading will have to be re-done, and the maths recalculated, but that's a good exercise.
And I understand that because of the way the simulator is written, 100% represents 9200 lbs (because, reasons). The good news is that if you ever buy the upgrade you won't need to change the code.
So, in order to proceed we need a definite decision on whether you will or will not adjust the resistor to get 100% PWM hitting 100 on the gauge. Either way I don't mind, but I recommend that you do it.
Then, double check the table of results for PWM to gauge position if you didn't change the resistance, or create a new table of PWM to gauge position if you did.
I'll hack together a quick Arduino program to drive the gauges and you can try it out. You'll see it looks very similar to the flaps code, and is basically: get some data in from link2fs, do some simple maths, write to the PWM pin.
For the fuel gauge I think it is unnecessary to dampen the needle movement. In normal use they will move very slowly. At start up they will jump instantly to the initial position. However, if that's not what you want we can look at that later.
I will endeavour to get the gauge to 100 mark using various resistors...I am pretty sure I can achieve that so that will be my work for tonight/tomorrow.
Following this I will re due the numbers and send these values to you.
fuel needle movement at start up will be fine..whether it is fast or slow.
Ok...testing complete...
I reduced the resistor value to 637 ohms giving me a needle indication of exactly, or very close to 100 on the gauge. (Maybe a mm away from the 100 mark)
Following this I tabulated the values again, and actually found little to no difference...here are my findings, (I did not populate the increase/ decrease list as the values were the same...some more accurate on the way up..and others more accurate on the way down..that is to say the needle stopped at exactly a benchmark value like 10..20..30 etc.)
needle value / serial monitor
0..............75
10..............90
20..............110
30..............130
40..............145
50..............165
60..............180
70..............205
80..............220
90..............240
100..............255
Ok. Try this. It does compile, but it has not been tested at all. What could possibly go wrong?
Quote/*
This code is in the public domain
For use with "Link2fs_Multi"
Jimspage.co.nz (via archive.org)
*/
int CodeIn;// used on all serial reads
String flaps;
String fuel; // Re-use this variable for all fuel gauges as we only do one at a time
// PWM pins for gauges. Must be one of 3, 5, 6, 9, 10, or 11 for Arduino Uno
// Flaps
int flaps_PWM_out_pin = 3;
// Fuel
int fuel_L_PWM_out_pin = 5; // Left fuel gauge
int fuel_C_PWM_out_pin = 6; // Centre fuel gauge
int fuel_R_PWM_out_pin = 9; // Right fuel gauge
// Variables for fuel gauges
// Can be reused for each gauge as we do one at a time.
int fuel_PWM_out;
float fuel_percent;
float fuel_lbs;
// Variables to support incremental update of gauges
unsigned long currentMillis; // store the current time
unsigned long previousMillis;
unsigned long period = 100; // 100millis = 0.1s, 10 updates per second
// Variables for flaps gauge
const int flaps_max_PWM_per_slot=1; // Maximum amount we can move in 0.1s
int flaps_PWM_target; // Target PWM value, based on last flaps degrees
int flaps_PWM_current; // Current PWM value, can only move slowly
bool first_flaps_PWM_value; // Flag to see if we should go directly to target
void setup()
{
Serial.begin(115200);
// Set up PWM pins.
pinMode(flaps_PWM_out_pin, OUTPUT);
pinMode(fuel_L_PWM_out_pin, OUTPUT);
pinMode(fuel_C_PWM_out_pin, OUTPUT);
pinMode(fuel_R_PWM_out_pin, OUTPUT);
// Set PWM values to zero.
analogWrite(flaps_PWM_out_pin, 0);
analogWrite(fuel_L_PWM_out_pin, 0);
analogWrite(fuel_C_PWM_out_pin, 0);
analogWrite(fuel_R_PWM_out_pin, 0);
flaps_PWM_target=0;
flaps_PWM_current=0;
first_flaps_PWM_value=true;
}
void loop() {
// Deal with incoming data from link2fs
if (Serial.available()) {
CodeIn = getChar();
if (CodeIn == '=') {EQUALS();} // The first identifier is "="
if (CodeIn == '<') {LESSTHAN();}// The first identifier is "<"
if (CodeIn == '?') {QUESTION();}// The first identifier is "?"
if (CodeIn == '/') {SLASH();}// The first identifier is "/" (Annunciators)
}
// Other tasks
// Currently we have to smooth the flaps output.
// Fuel gauges don't need smoothing.
currentMillis = millis(); // store the current time
if (currentMillis - previousMillis >= period) { // check if 100ms passed
// We're on a 100ms boundary
previousMillis = currentMillis; // update the time we were here
if (flaps_PWM_target > flaps_PWM_current) {
flaps_PWM_current += flaps_max_PWM_per_slot;
if (flaps_PWM_current > flaps_PWM_target) flaps_PWM_current=flaps_PWM_target;
}
else if (flaps_PWM_target < flaps_PWM_current) {
flaps_PWM_current -= flaps_max_PWM_per_slot;
if (flaps_PWM_current < flaps_PWM_target) flaps_PWM_current=flaps_PWM_target;
}
else {
// target and current are equal. Nothing to do.
}
analogWrite(flaps_PWM_out_pin, flaps_PWM_current);
}
}
char getChar()// Get a character from the serial buffer
{
while(Serial.available() == 0);// wait for data
return((char)Serial.read());// Thanks Doug
}
void EQUALS(){ // The first identifier was "="
CodeIn = getChar(); // Get another character
switch(CodeIn) {// Now lets find what to do with it
case 'A'://Found the second identifier
//Do something
break;
case 'B':
//Do something
break;
case 'C':
//Do something
break;
}
}
void LESSTHAN(){ // The first identifier was "<"
CodeIn = getChar(); // Get another character
switch(CodeIn) {// Now lets find what to do with it
case 'A'://Found the second identifier
//Do something
break;
case 'B':
//Do something
break;
case 'G': //Found the second identifier ("G" Flaps position)
// Next three characters should be numeric
flaps = "";
flaps += getChar();
flaps += getChar();
flaps += getChar();
// convert 3-character numeric string to a float
// Expected range is 000 to 033
float flaps_degrees = flaps.toFloat();
// Convert degrees to PWM 0-255.
// 33 degrees is full scale, so multiplier is 255/33=7.727
int PWM_out = flaps_degrees*7.727;
// Clip output to maximum if (for some reason) it's >255
if(PWM_out > 255) PWM_out=255;
// New flaps PWM is calculated. Copy to other variables to
// be handled by main loop on next 100ms boundary
flaps_PWM_target=PWM_out;
// If this is the first value we have received, go directly there.
if (first_flaps_PWM_value) {
flaps_PWM_current=flaps_PWM_target;
first_flaps_PWM_value=false;
}
break;
case 'X': // "X" left fuel gauge
// Next three characters should be numeric
fuel = "";
fuel += getChar();
fuel += getChar();
fuel += getChar();
// convert 3-character numeric string to a float
// It's a percentage of full, where full is 9200 lbs (left)
// Expected range is 000 to 100
fuel_percent = fuel.toFloat();
fuel_lbs = fuel_percent * 9200;
// Convert lbs to PWM 0-255.
// 0 lbs on gauge is PWM 75
// 10,000 lbs on gauge is 255
// So PWM is (1.8 x (lbs/100)) + 75
fuel_PWM_out = ((fuel_lbs * 1.8)/100.0)+75.0;
// Clip output to maximum if (for some reason) it's >255
if(fuel_PWM_out > 255) fuel_PWM_out=255;
// Drive the gauge
analogWrite(fuel_L_PWM_out_pin, fuel_PWM_out);
break;
case 'Y': // "Y" centre fuel gauge
// Next three characters should be numeric
fuel = "";
fuel += getChar();
fuel += getChar();
fuel += getChar();
// convert 3-character numeric string to a float
// It's a percentage of full, where full is 4400 lbs (centre)
// Expected range is 000 to 100
fuel_percent = fuel.toFloat();
fuel_lbs = fuel_percent * 4400;
// Convert lbs to PWM 0-255.
// 0 lbs on gauge is PWM 75
// 10,000 lbs on gauge is 255
// So PWM is (1.8 x (lbs/100)) + 75
fuel_PWM_out = ((fuel_lbs * 1.8)/100.0)+75.0;
// Clip output to maximum if (for some reason) it's >255
if(fuel_PWM_out > 255) fuel_PWM_out=255;
// Drive the gauge
analogWrite(fuel_C_PWM_out_pin, fuel_PWM_out);
break;
case 'Z': // "Z" right fuel gauge
// Next three characters should be numeric
fuel = "";
fuel += getChar();
fuel += getChar();
fuel += getChar();
// convert 3-character numeric string to a float
// It's a percentage of full, where full is 9200 lbs (left)
// Expected range is 000 to 100
fuel_percent = fuel.toFloat();
fuel_lbs = fuel_percent * 9200;
// Convert lbs to PWM 0-255.
// 0 lbs on gauge is PWM 75
// 10,000 lbs on gauge is 255
// So PWM is (1.8 x (lbs/100)) + 75
fuel_PWM_out = ((fuel_lbs * 1.8)/100.0)+75.0;
// Clip output to maximum if (for some reason) it's >255
if(fuel_PWM_out > 255) fuel_PWM_out=255;
// Drive the gauge
analogWrite(fuel_R_PWM_out_pin, fuel_PWM_out);
break;
}
}
void QUESTION(){ // The first identifier was "?"
CodeIn = getChar(); // Get another character
switch(CodeIn) {// Now lets find what to do with it
case 'A'://Found the second identifier
//Do something
break;
case 'B':
//Do something
break;
case 'C':
//Do something
break;
}
}
void SLASH(){ // The first identifier was "/" (Annunciator)
//Do something
}
Thank you ame!!!
Will give it a try today and report back
Eek! There's a bug!
We have to divide by 10000, not 100!
Change this line:
fuel_PWM_out = ((fuel_lbs * 1.8)/100.0)+75.0;
To this:
fuel_PWM_out = ((fuel_lbs * 1.8)/10000.0)+75.0;
In three places.
oK..will do.
If 100% full is 9200lbs I think it should be:
fuel_PWM_out = ( 1.8 * 100/9200 ) * fuel_lbs + 75;
or just:
fuel_PWM_out = 0.01956522 * fuel_lbs + 75;
But why not use the percent read, and map function?
fuel_PWM_out = map ( fuel_percent, 0, 100, 75, 255);
and limit max and min values (just in case..):
fuel_PWM_out = constrain ( fuel_PWM_out, 0, 255);
Ok, couple of issues.
First I just want to make sure that I do not have to have all 3 fuel gauges connected to test the system...right now I am using a single spare and connecting up to pin 5 for test purposes.
The flaps work fine, but the fuel gauge does not move at all.
I have checked the link2fs monitor, and it seems to be giving the output to the x,y,z axis.
I have checked the gauge and the wiring is all sound...using a 1.5 battery following disconnect form the board I confirmed that the harness is allowing to receive power., (small needle movement).
I opened the Arduino and downloaded the program a second time..no issues with the upload.
I opened the serial monitor port and typed in <X088 and the gauge did not move...I tried the other axis as well.
Just to confirm the monitor was working..i typed in <G020 and the flaps work fine.
The com port is good...it is selected to comm port 4 with everything in the green.
will do a bit more troubleshooting unless you see something obvious here.
thanks!
jim
Hello Arturo..i when i sent my last message...and we were both sending at the same time, so i just saw what you wrote.
Do you think the change in code as you suggested may have something to do with my current issue?
Also...is there another selection I must make in Link2fs other than checking the boxes for X, Y and Z?
Jim
Quote from: _alioth_ on August 23, 2023, 06:47:14 AMIf 100% full is 9200lbs I think it should be:
fuel_PWM_out = ( 1.8 * 100/9200 ) * fuel_lbs + 75;
or just:
fuel_PWM_out = 0.01956522 * fuel_lbs + 75;
But why not use the percent read, and map function?
fuel_PWM_out = map ( fuel_percent, 0, 100, 75, 255);
and limit max and min values:
fuel_PWM_out = constrain ( fuel_PWM_out, 0, 255);
I don't agree. 100% of the tank is 9200 lbs, but 100% of the
gauge is 100 x100 lbs. So, if the tank is 100% full the gauge should be driven with less than 255 PWM, so that the needle points to 92.
For the current configuration the simulator won't allow the tank to be 100% "full" and caps the percentage at 88%, representing 8120 lbs, thus the needle should point to 81.
QuoteI don't agree. 100% of the tank is 9200 lbs, but 100% of the gauge is 100 x100 lbs.
Sorry, I thought gauge showed 100%, and not 100x100lbs.
Thanks Ame.
Hey guys...anything in the code that would stop this gauge from moving?....it appears that (as per the link2fs monitor) outputs are being sent...but for some reason the gauge (fuel) does not move.
Have triple checked all the connections...the com port 4 shows green...all the necessary boxes have been ticked off.
Ill do some additional troubleshooting...just seeing if anything obvious stands out in the code.
Jim
So some additional troubleshooting..as I am looking at this assuming the code is correct.
I replaced both the flap and fuel gauges with LEDz.
The flap out put from the arfuino serial monitor works fine with flaps..
<G020
But nothing happens when testing the fuel outputs
<X088
<Y088
<Z088
And like I said in previous post..with Link2fs connected and fs9/qw146 up and running..the monitor shoes the correct outputs for fuel..but no life at the gauge..flaps work fine with this code.
Morning in New Zealand. Sorry, I have a very busy day. I will get onto it as soon as I can. Probably something very simple. Sorry.
Working on it. Confirmed it doesn't behave as expected when I simulate the code. Probably a thinko (it's like a typo, but it happens when you're thinking).
I can not test now, but it could be related to definitions inside the Case:
case 'G': //Found the second identifier ("G" Flaps position)
// Next three characters should be numeric
flaps = "";
flaps += getChar();
flaps += getChar();
flaps += getChar();
// convert 3-character numeric string to a float
// Expected range is 000 to 033
float flaps_degrees = flaps.toFloat();
// Convert degrees to PWM 0-255.
// 33 degrees is full scale, so multiplier is 255/33=7.727
int PWM_out = flaps_degrees*7.727;
...
I remember I have had problems with this in the past.
Try global definitions. Just in case.
I have tested in tinkercad simulator (no arduino here now) and it says some error related to definitions inside the case.
I have tested this code and seems to work as it should (but tinkercad is not the same as arduino so... ). I have added some Serial.prints inside the case just to test:
Quote/*
This code is in the public domain
For use with "Link2fs_Multi"
Jimspage.co.nz (via archive.org)
*/
int CodeIn;// used on all serial reads
String flaps;
String fuel; // Re-use this variable for all fuel gauges as we only do one at a time
// PWM pins for gauges. Must be one of 3, 5, 6, 9, 10, or 11 for Arduino Uno
// Flaps
int flaps_PWM_out_pin = 3;
// Fuel
int fuel_L_PWM_out_pin = 5; // Left fuel gauge
int fuel_C_PWM_out_pin = 6; // Centre fuel gauge
int fuel_R_PWM_out_pin = 9; // Right fuel gauge
// Variables for fuel gauges
// Can be reused for each gauge as we do one at a time.
int fuel_PWM_out;
float fuel_percent;
float fuel_lbs;
float flaps_degrees = 0;
int PWM_out = 0;
// Variables to support incremental update of gauges
unsigned long currentMillis; // store the current time
unsigned long previousMillis;
unsigned long period = 100; // 100millis = 0.1s, 10 updates per second
// Variables for flaps gauge
const int flaps_max_PWM_per_slot = 1; // Maximum amount we can move in 0.1s
int flaps_PWM_target; // Target PWM value, based on last flaps degrees
int flaps_PWM_current; // Current PWM value, can only move slowly
bool first_flaps_PWM_value; // Flag to see if we should go directly to target
void setup()
{
Serial.begin(115200);
// Set up PWM pins.
pinMode(flaps_PWM_out_pin, OUTPUT);
pinMode(fuel_L_PWM_out_pin, OUTPUT);
pinMode(fuel_C_PWM_out_pin, OUTPUT);
pinMode(fuel_R_PWM_out_pin, OUTPUT);
// Set PWM values to zero.
analogWrite(flaps_PWM_out_pin, 0);
analogWrite(fuel_L_PWM_out_pin, 0);
analogWrite(fuel_C_PWM_out_pin, 0);
analogWrite(fuel_R_PWM_out_pin, 0);
flaps_PWM_target = 0;
flaps_PWM_current = 0;
first_flaps_PWM_value = true;
}
void loop() {
// Deal with incoming data from link2fs
if (Serial.available()) {
CodeIn = getChar();
if (CodeIn == '=') {
EQUALS(); // The first identifier is "="
}
if (CodeIn == '<') {
LESSTHAN(); // The first identifier is "<"
}
if (CodeIn == '?') {
QUESTION(); // The first identifier is "?"
}
if (CodeIn == '/') {
SLASH(); // The first identifier is "/" (Annunciators)
}
}
// Other tasks
// Currently we have to smooth the flaps output.
// Fuel gauges don't need smoothing.
currentMillis = millis(); // store the current time
if (currentMillis - previousMillis >= period) { // check if 100ms passed
// We're on a 100ms boundary
previousMillis = currentMillis; // update the time we were here
if (flaps_PWM_target > flaps_PWM_current) {
flaps_PWM_current += flaps_max_PWM_per_slot;
if (flaps_PWM_current > flaps_PWM_target) flaps_PWM_current = flaps_PWM_target;
}
else if (flaps_PWM_target < flaps_PWM_current) {
flaps_PWM_current -= flaps_max_PWM_per_slot;
if (flaps_PWM_current < flaps_PWM_target) flaps_PWM_current = flaps_PWM_target;
}
else {
// target and current are equal. Nothing to do.
}
analogWrite(flaps_PWM_out_pin, flaps_PWM_current);
}
}
char getChar()// Get a character from the serial buffer
{
while (Serial.available() == 0); // wait for data
return ((char)Serial.read()); // Thanks Doug
}
void EQUALS() { // The first identifier was "="
CodeIn = getChar(); // Get another character
switch (CodeIn) { // Now lets find what to do with it
case 'A'://Found the second identifier
//Do something
break;
case 'B':
//Do something
break;
case 'C':
//Do something
break;
}
}
void LESSTHAN() { // The first identifier was "<"
CodeIn = getChar(); // Get another character
switch (CodeIn) { // Now lets find what to do with it
case 'A'://Found the second identifier
//Do something
break;
case 'B':
//Do something
break;
case 'G': //Found the second identifier ("G" Flaps position)
// Next three characters should be numeric
flaps = "";
flaps += getChar();
flaps += getChar();
flaps += getChar();
// convert 3-character numeric string to a float
// Expected range is 000 to 033
flaps_degrees = flaps.toFloat();
// Convert degrees to PWM 0-255.
// 33 degrees is full scale, so multiplier is 255/33=7.727
PWM_out = flaps_degrees * 7.727;
// Clip output to maximum if (for some reason) it's >255
if (PWM_out > 255) PWM_out = 255;
// New flaps PWM is calculated. Copy to other variables to
// be handled by main loop on next 100ms boundary
flaps_PWM_target = PWM_out;
// If this is the first value we have received, go directly there.
if (first_flaps_PWM_value) {
flaps_PWM_current = flaps_PWM_target;
first_flaps_PWM_value = false;
}
Serial.print("G");
Serial.println (PWM_out);
break;
case 'X': // "X" left fuel gauge
// Next three characters should be numeric
fuel = "";
fuel += getChar();
fuel += getChar();
fuel += getChar();
// convert 3-character numeric string to a float
// It's a percentage of full, where full is 9200 lbs (left)
// Expected range is 000 to 100
fuel_percent = fuel.toFloat();
fuel_lbs = fuel_percent * 9200;
// Convert lbs to PWM 0-255.
// 0 lbs on gauge is PWM 75
// 10,000 lbs on gauge is 255
// So PWM is (1.8 x (lbs/100)) + 75
fuel_PWM_out = ((fuel_lbs * 1.8) / 10000) + 75.0;
// Clip output to maximum if (for some reason) it's >255
if (fuel_PWM_out > 255) fuel_PWM_out = 255;
// Drive the gauge
analogWrite(fuel_L_PWM_out_pin, fuel_PWM_out);
Serial.print("X");
Serial.println (fuel_lbs);
break;
case 'Y': // "Y" centre fuel gauge
// Next three characters should be numeric
fuel = "";
fuel += getChar();
fuel += getChar();
fuel += getChar();
// convert 3-character numeric string to a float
// It's a percentage of full, where full is 4400 lbs (centre)
// Expected range is 000 to 100
fuel_percent = fuel.toFloat();
fuel_lbs = fuel_percent * 4400;
// Convert lbs to PWM 0-255.
// 0 lbs on gauge is PWM 75
// 10,000 lbs on gauge is 255
// So PWM is (1.8 x (lbs/100)) + 75
fuel_PWM_out = ((fuel_lbs * 1.8) / 10000) + 75.0;
// Clip output to maximum if (for some reason) it's >255
if (fuel_PWM_out > 255) fuel_PWM_out = 255;
// Drive the gauge
analogWrite(fuel_C_PWM_out_pin, fuel_PWM_out);
Serial.print("Y");
Serial.println (fuel_PWM_out);
break;
case 'Z': // "Z" right fuel gauge
// Next three characters should be numeric
fuel = "";
fuel += getChar();
fuel += getChar();
fuel += getChar();
// convert 3-character numeric string to a float
// It's a percentage of full, where full is 9200 lbs (left)
// Expected range is 000 to 100
fuel_percent = fuel.toFloat();
fuel_lbs = fuel_percent * 9200;
// Convert lbs to PWM 0-255.
// 0 lbs on gauge is PWM 75
// 10,000 lbs on gauge is 255
// So PWM is (1.8 x (lbs/100)) + 75
fuel_PWM_out = ((fuel_lbs * 1.8) / 10000) + 75.0;
// Clip output to maximum if (for some reason) it's >255
if (fuel_PWM_out > 255) fuel_PWM_out = 255;
// Drive the gauge
analogWrite(fuel_R_PWM_out_pin, fuel_PWM_out);
Serial.print("Z");
Serial.println (fuel_PWM_out);
break;
}
}
void QUESTION() { // The first identifier was "?"
CodeIn = getChar(); // Get another character
switch (CodeIn) { // Now lets find what to do with it
case 'A'://Found the second identifier
//Do something
break;
case 'B':
//Do something
break;
case 'C':
//Do something
break;
}
}
void SLASH() { // The first identifier was "/" (Annunciator)
//Do something
}
Well, how about that?
I concur. I put a bunch of print statements in, to see what was happening: nothing.
Then I moved the variable definitions out: success!
This is why we test code before we post it to the internet. :-[
Thanks Arturo.
And here's why:
https://stackoverflow.com/questions/92396/why-cant-variables-be-declared-in-a-switch-statement
I've been doing this a while and I've never written anything that happened to cause that problem. I'll try not to do it again (I prefer making new mistakes).
new mistakes are always funnier, Ame! :)
I would like to code some cleaner and efficient way to read the link2fs data.
But I would need to know if:
- ticking the box "include CR/LF" there is always a return at the end of each command.
- ticking the box "include comma's between" sends always a "," at the end of each command.
First one, then the other. Not both at the same time, if posible.
Can you help me with this Mach7? you can see it in link2fs "to card" window or put some screenshots.
Thanks
Hello guys, the program works perfectly!!
Thank you!!!!!!!!!!..
@Arturo...I thought I knew what you were talking about with respect to the fuel quantity indication and battery bus power...now seeing it it makes perfect sense to me what you were trying to tell me. Still not an issue for me in this application, but now I understand what you were saying..thanks.
I will put up some screen shots up today.
Also...and not a really big deal...but is there anyway to have the fuel needle(s) move a bit slower to there requested positions?
I notice that it may be beneficial, (to the instrument life itself) to have the needle move slowly to the requested fuel levels...that is to say in transient states the needle will move very fast, epecially when it returns to zero from a high fuel state..the needle "bounces" off its stops.
This may not be too big of an issue...just thinking that anything that moves a bit slower may increase the life of the instrument itself.
Quote from: _alioth_ on August 24, 2023, 02:18:50 AMnew mistakes are always funnier, Ame! :)
I would like to code some cleaner and efficient way to read the link2fs data.
But I would need to know if:
- ticking the box "include CR/LF" there is always a return at the end of each command.
- ticking the box "include comma's between" sends always a "," at the end of each command.
First one, then the other. Not both at the same time, if posible.
Can you help me with this Mach7? you can see it in link2fs "to card" window or put some screenshots.
Thanks
I see where you're coming from, but nobody uses link2fs anymore, and the website is dead. Link2fs is based on FSConnect, from here:
https://www.dirks-software.ca/
One day FSConnect.dll will die too. However, I thought about using Python to access FSConnect.dll directly, then put a Python wrapper around it. Then it would be no longer necessary to use link2fs.
Furthermore, all the processing could be done in Python, thus leaving the Arduino to output a PWM value to a pin only.
Quote from: Mach7 on August 24, 2023, 02:39:41 AMHello guys, the program works perfectly!!
Thank you!!!!!!!!!!..
@Arturo...I thought I knew what you were talking about with respect to the fuel quantity indication and battery bus power...now seeing it it makes perfect sense to me what you were trying to tell me. Still not an issue for me in this application, but now I understand what you were saying..thanks.
I will put up some screen shots up today.
Also...and not a really big deal...but is there anyway to have the fuel needle(s) move a bit slower to there requested positions?
I notice that it may be beneficial, (to the instrument life itself) to have the needle move slowly to the requested fuel levels...that is to say in transient states the needle will move very fast, epecially when it returns to zero from a high fuel state..the needle "bounces" off its stops.
This may not be too big of an issue...just thinking that anything that moves a bit slower may increase the life of the instrument itself.
Excellent. Glad it's working. Sorry about the rookie mistake.
Regarding damping the needles, a very common technique is to filter the target position with a simple running average:
new_position = (current_ position+target_position)/2
I'll code something up later (now it's bedtime in New Zealand), but that's what I'd do.
Thanks again ame
And many thanks to both of you guys!!
Once I have it all connected up I will post a video!
Jim
Any thoughts of using mobiflight as your interface instead of link2fs? Actively supported with multiple flavors of arduinos and works really well.
Quote from: Jason L on August 24, 2023, 01:15:52 PMAny thoughts of using mobiflight as your interface instead of link2fs? Actively supported with multiple flavors of arduinos and works really well.
Does it support FS9?
Since it's all working now there's probably not much sense in reimplementing it.
Hello guys, as promised a short video and a pic of the Arduino board setup...i still have to clean some wires up and situate the board...but for testing it is good for now.
Thanks again ame and Arturo for all the help.
It's nice to get away from those clunky OpenCockpit controlled dc servo motors..
As far as Mobiflight is concered...I looked into that, but as far as I can see there is no support for FS9.
https://www.youtube.com/watch?v=khojFlD_xV4
Jim
Nice!
Next step is the flaps input, right?
Only half-kidding. You said it was a linear pot hooked up to the flaps lever. Arduino has an analogue to digital converter (ADC) so can detect the position of the pot. Link2fs allows you to send commands back in to the simulator.
Would need to prototype it entirely before removing the current system you have which works, but I think it should be possible.
Ok. I've improved the filtering on the flaps, so it should be less jerky. I've also added some smoothing to the fuel gauge so they don't jump at startup, but general movement won't be affected because the fuel gauges move so slowly.
Take a copy of the working code that you are happy with in case this code doesn't work, then you can go back to it if you need to. I did test it this time, but that is no guarantee...
Quote/*
This code is in the public domain
For use with "Link2fs_Multi"
Jimspage.co.nz (via archive.org)
*/
int CodeIn;// used on all serial reads
String flaps;
String fuel; // Re-use this variable for all fuel gauges as we only do one at a time
// PWM pins for gauges. Must be one of 3, 5, 6, 9, 10, or 11 for Arduino Uno
// Flaps
int flaps_PWM_out_pin = 3;
// Fuel
int fuel_L_PWM_out_pin = 5; // Left fuel gauge
int fuel_C_PWM_out_pin = 6; // Centre fuel gauge
int fuel_R_PWM_out_pin = 9; // Right fuel gauge
// Variables for fuel gauges
int fuel_L_PWM_out;
int fuel_C_PWM_out;
int fuel_R_PWM_out;
int fuel_PWM_out;
// Record last needle position for damping
int last_fuel_L_PWM_out;
int last_fuel_C_PWM_out;
int last_fuel_R_PWM_out;
// Can be reused for each gauge as we do one at a time.
float fuel_percent;
float fuel_lbs;
// Variables for flaps
float flaps_degrees;
float filtered_flaps_degrees;
int flaps_PWM_out;
// Variables to support incremental update of gauges
unsigned long currentMillis; // store the current time
unsigned long previousMillis;
unsigned long period = 100; // 100millis = 0.1s, 10 updates per second
// Variables for flaps gauge
// The gauge on the simulator travels from 0 to 33 degrees in about 35 seconds
// We should introduce fractional degrees for the physical gauge so that it
// moves smoothly between integer degree positions.
const float flaps_max_degrees_per_period=0.0943; // Maximum amount we can move in 0.1s
int flaps_PWM_target; // Target PWM value, based on last flaps degrees
int flaps_PWM_current; // Current PWM value, can only move slowly
bool first_flaps_value; // Flag to see if we should go directly to target
void setup()
{
Serial.begin(115200);
// Set up PWM pins.
pinMode(flaps_PWM_out_pin, OUTPUT);
pinMode(fuel_L_PWM_out_pin, OUTPUT);
pinMode(fuel_C_PWM_out_pin, OUTPUT);
pinMode(fuel_R_PWM_out_pin, OUTPUT);
// Set PWM values to zero.
analogWrite(flaps_PWM_out_pin, 0);
analogWrite(fuel_L_PWM_out_pin, 0);
analogWrite(fuel_C_PWM_out_pin, 0);
analogWrite(fuel_R_PWM_out_pin, 0);
first_flaps_value=true;
last_fuel_L_PWM_out=0;
last_fuel_C_PWM_out=0;
last_fuel_R_PWM_out=0;
}
void loop() {
// Deal with incoming data from link2fs
if (Serial.available()) {
CodeIn = getChar();
if (CodeIn == '=') {EQUALS();} // The first identifier is "="
if (CodeIn == '<') {LESSTHAN();}// The first identifier is "<"
if (CodeIn == '?') {QUESTION();}// The first identifier is "?"
if (CodeIn == '/') {SLASH();}// The first identifier is "/" (Annunciators)
}
// Other tasks
// Smooth the needle output.
// For flaps, we calculate intermediate flaps positions and then move the needle.
// For fuel, we calculate the PWM output, and apply a running average filter.
currentMillis = millis(); // store the current time
if (currentMillis - previousMillis >= period) { // check if 100ms passed
// We're on a 100ms boundary
previousMillis = currentMillis; // update the time we were here
// flaps_degrees is updated elsewhere when new data arrives.
// Filter the gauge needle position slowly over time.
if (flaps_degrees > filtered_flaps_degrees) {
filtered_flaps_degrees += flaps_max_degrees_per_period;
if (filtered_flaps_degrees > flaps_degrees) filtered_flaps_degrees=flaps_degrees;
}
else if (flaps_degrees < filtered_flaps_degrees) {
filtered_flaps_degrees -= flaps_max_degrees_per_period;
if (filtered_flaps_degrees < flaps_degrees) filtered_flaps_degrees=flaps_degrees;
}
else {
// target and current are equal. Nothing to do.
}
// Convert degrees to PWM 0-255.
// 33 degrees is full scale, so multiplier is 255/33=7.727
// If this is the first value we have received, go directly there.
if (first_flaps_value) {
filtered_flaps_degrees=flaps_degrees;
first_flaps_value=false;
}
flaps_PWM_out = filtered_flaps_degrees*7.727;
analogWrite(flaps_PWM_out_pin, flaps_PWM_out);
// Now update the fuel gauges. Just a simple digital filter.
// Yes, this should be done as an array...
fuel_PWM_out = ((3.0*last_fuel_L_PWM_out) + fuel_L_PWM_out)/4.0;
last_fuel_L_PWM_out = fuel_PWM_out;
analogWrite(fuel_L_PWM_out_pin, fuel_PWM_out);
// Lighter filter on centre gauge
fuel_PWM_out = ((2.0*last_fuel_C_PWM_out) + fuel_C_PWM_out)/3.0;
last_fuel_C_PWM_out = fuel_PWM_out;
analogWrite(fuel_C_PWM_out_pin, fuel_PWM_out);
fuel_PWM_out = ((3.0*last_fuel_R_PWM_out) + fuel_R_PWM_out)/4.0;
last_fuel_R_PWM_out = fuel_PWM_out;
analogWrite(fuel_R_PWM_out_pin, fuel_PWM_out);
}
}
char getChar()// Get a character from the serial buffer
{
while(Serial.available() == 0);// wait for data
return((char)Serial.read());// Thanks Doug
}
void EQUALS(){ // The first identifier was "="
CodeIn = getChar(); // Get another character
switch(CodeIn) {// Now lets find what to do with it
case 'A'://Found the second identifier
//Do something
break;
case 'B':
//Do something
break;
case 'C':
//Do something
break;
}
}
void LESSTHAN(){ // The first identifier was "<"
CodeIn = getChar(); // Get another character
switch(CodeIn) {// Now lets find what to do with it
case 'A'://Found the second identifier
//Do something
break;
case 'B':
//Do something
break;
case 'G': //Found the second identifier ("G" Flaps position)
// Next three characters should be numeric
flaps = "";
flaps += getChar();
flaps += getChar();
flaps += getChar();
// convert 3-character numeric string to a float
// Expected range is 000 to 033
flaps_degrees = flaps.toFloat();
// Moving the needle will be done in the main loop.
break;
case 'X': // "X" left fuel gauge
// Next three characters should be numeric
fuel = "";
fuel += getChar();
fuel += getChar();
fuel += getChar();
// convert 3-character numeric string to a float
// It's a percentage of full, where full is 9200 lbs (left)
// Expected range is 000 to 100
fuel_percent = fuel.toFloat();
fuel_lbs = fuel_percent * 9200;
// Convert lbs to PWM 0-255.
// 0 lbs on gauge is PWM 75
// 10,000 lbs on gauge is 255
// So PWM is (1.8 x (lbs/100)) + 75
fuel_L_PWM_out = ((fuel_lbs * 1.8)/10000.0)+75.0;
// Clip output to maximum if (for some reason) it's >255
if(fuel_L_PWM_out > 255) fuel_L_PWM_out=255;
// Moving the needle will be done in the main loop.
break;
case 'Y': // "Y" centre fuel gauge
// Next three characters should be numeric
fuel = "";
fuel += getChar();
fuel += getChar();
fuel += getChar();
// convert 3-character numeric string to a float
// It's a percentage of full, where full is 4400 lbs (centre)
// Expected range is 000 to 100
fuel_percent = fuel.toFloat();
fuel_lbs = fuel_percent * 4400;
// Convert lbs to PWM 0-255.
// 0 lbs on gauge is PWM 75
// 10,000 lbs on gauge is 255
// So PWM is (1.8 x (lbs/100)) + 75
fuel_C_PWM_out = ((fuel_lbs * 1.8)/10000.0)+75.0;
// Clip output to maximum if (for some reason) it's >255
if(fuel_C_PWM_out > 255) fuel_C_PWM_out=255;
// Moving the needle will be done in the main loop.
break;
case 'Z': // "Z" right fuel gauge
// Next three characters should be numeric
fuel = "";
fuel += getChar();
fuel += getChar();
fuel += getChar();
// convert 3-character numeric string to a float
// It's a percentage of full, where full is 9200 lbs (left)
// Expected range is 000 to 100
fuel_percent = fuel.toFloat();
fuel_lbs = fuel_percent * 9200;
// Convert lbs to PWM 0-255.
// 0 lbs on gauge is PWM 75
// 10,000 lbs on gauge is 255
// So PWM is (1.8 x (lbs/100)) + 75
fuel_R_PWM_out = ((fuel_lbs * 1.8)/10000.0)+75.0;
// Clip output to maximum if (for some reason) it's >255
if(fuel_R_PWM_out > 255) fuel_R_PWM_out=255;
// Moving the needle will be done in the main loop.
break;
}
}
void QUESTION(){ // The first identifier was "?"
CodeIn = getChar(); // Get another character
switch(CodeIn) {// Now lets find what to do with it
case 'A'://Found the second identifier
//Do something
break;
case 'B':
//Do something
break;
case 'C':
//Do something
break;
}
}
void SLASH(){ // The first identifier was "/" (Annunciator)
//Do something
}
Incidentally, I am testing with this:
https://wokwi.com/
You can simulate the Arduino, which means you can compile code and edit it in the browser, and you can simulate serial input and output for testing.
Saves having something hooked up on the bench.
Thanks for the updated code ame!
I will upload it when I get back from work..i will be on the road for 4 days starting tomorrow, so will be able to update you on Monday.
Again...I really appreciate your time, knowledge and commitment.
Thank you!!
Jim
Quote from: Jason L on August 24, 2023, 01:15:52 PMAny thoughts of using mobiflight as your interface instead of link2fs? Actively supported with multiple flavors of arduinos and works really well.
On a related note, how can we encourage more people to build things? This is "cockpitbuilders.com" after all. Or is everyone on the mobiflight site these days?
I have enjoyed this little foray into link2fs, and in some ways I'm disappointed that it's gone. MSFS now has "Simconnect", which can be utilised in a number of ways, but that's no good for FS9.
Quote from: ame on August 24, 2023, 08:09:54 PMQuote from: Jason L on August 24, 2023, 01:15:52 PMAny thoughts of using mobiflight as your interface instead of link2fs? Actively supported with multiple flavors of arduinos and works really well.
On a related note, how can we encourage more people to build things? This is "cockpitbuilders.com" after all. Or is everyone on the mobiflight site these days?
I have enjoyed this little foray into link2fs, and in some ways I'm disappointed that it's gone. MSFS now has "Simconnect", which can be utilised in a number of ways, but that's no good for FS9.
Yes... and I the freedom you have using custom arduino code is unlimited. The only limit is your imagination.
You can not interface real complex things with mobiflight.
I really like the arduino/teensy code size. My problem was always the comunication with p3d.
Xplane is great with teensy, because teensy has native support to share variables with xplane:
https://www.pjrc.com/teensy/td_flightsim.html (https://www.pjrc.com/teensy/td_flightsim.html)
I would rellay like to have something similar in p3d/msfs.
I know simconnect, but I never find the strength, and I don't even know if I would have the skills to program c++ plugins to do the communication with arduino.
So, I am using lua scripts with FSUIPC.
The Lua script in fsuipc talks with simconnect. So you read variables and send values to arduino and the reverse.
The advantage over link2fs is you can control poll rate, read Lvars, and take control over variables.
For example, level gauge has only 100 steps in link2fs, but with the script I can read the lbs and send from 0 to 1000, or the lbs, or whatever I want.
But I would like to have something more "comercial grade", a plugin, dll, exe... not editable por third parties.
Arturo.
Will try not to read too much into your comment but the assumption that if you use MobiFlight you aren't building a cockpit seems a bit of a stretch. It is by no means plug and play. One could ask the same of Prosim then too, one should be just building everything from scratch? I've got a combination of OEM and vendor-built parts in my 737, fully interfaced OEM ACP's using MobiFlight with FSUIPC and Prosim. Written scripts in SIOC for some of my OpenCockpits stuff. You can make your own firmware for MobiFlight to support more advanced features of the arduino. It's all open source and there is a large community to help support your endeavors. To me, that is cockpit building.
I like this site and the historical information that it provides, but it isn't a significantly active source for new information anymore. Many have turned to places like, yes, as you mentioned MobiFlight's discord server, Prosim's forums, whatsapp groups etc.
Off my soap box now.
Quote from: ame on August 24, 2023, 08:09:54 PMQuote from: Jason L on August 24, 2023, 01:15:52 PMAny thoughts of using mobiflight as your interface instead of link2fs? Actively supported with multiple flavors of arduinos and works really well.
On a related note, how can we encourage more people to build things? This is "cockpitbuilders.com" after all. Or is everyone on the mobiflight site these days?
I have enjoyed this little foray into link2fs, and in some ways I'm disappointed that it's gone. MSFS now has "Simconnect", which can be utilised in a number of ways, but that's no good for FS9.
You can get the registered copy of FSUIPC for FS9 for free now, with that, yes mobiflight will work. You can use it strictly with FSUIPC offsets then.
Quote from: ame on August 24, 2023, 01:26:08 PMQuote from: Jason L on August 24, 2023, 01:15:52 PMAny thoughts of using mobiflight as your interface instead of link2fs? Actively supported with multiple flavors of arduinos and works really well.
Does it support FS9?
Since it's all working now there's probably not much sense in reimplementing it.
Quote from: Jason L on August 25, 2023, 05:49:10 AMWill try not to read too much into your comment but the assumption that if you use MobiFlight you aren't building a cockpit seems a bit of a stretch.
Ah, sorry, that was not my intention at all. I meant "where are all the cockpit builders?". We've been helping Mach7 here, but there are no other similar threads (building something) on this site. So, where else are people doing it and writing about it?
Hello guys...back from work and will try the new code out and get back to you!!!!
I hope it works, but keep the old code around just in case.
Sorry @ame, had some issues logging on last nite
The flaps work perfectly!! Absoulutley smooth as glass, with zero stutter.
Is there a line in the code I can change to make the fuel gauges move even slower to there requested values? they could actually move as slow as the flaps.
Thank you again!!
Jim
I'm glad to hear the improvement to flaps actually works. I wasn't sure how it would look.
I used two different damping techniques. One for flaps, one for fuel. So there's not really anything you can change that will make them act the same way. Sorry.
What I can do is rewrite the code so that I am using the same technique for both.
You can see in the code there is the routine that gets new data from link2fs coming in via the serial port. This updates the target value that the gauge will point to. Then there is some other code that does something every tenth of a second.
For flaps there is a limit for how far the needle can move in a tenth of a second. It is set so that the needle can only move the equivalent of reaching the 33 degree position in 35 seconds.
For fuel you said that they jumped up to the target position too quickly. I took that to mean if you had 8000 lbs of fuel and you started the simulator the needle would jump straight to 80. What I did here is to have a running average filter so that the needle is only allowed to jump one quarter of the way every tenth of a second.
So, at 0.1s it jumps to 20 (which is quarter of 80). At 0.2s it jumps to 35 (the remaining distance is 60, so a quarter is 15). At 0.3s it jumps to 46. At 0.4s it jumps to 55, and so on. The idea being that it slows down as it reaches the target. The needle will take about one second to hit the target, instead of jumping straight there.
But, if a real fuel gauge moves from zero to 80 very linearly, and very slowly, I can do that. If you want it to move in the same manner as the flaps gauge, I can do it.
Hello ame...yes...Slowing the gauge movement would be a perfect example or what they would indicate whilst pressure re fuelling, they would move about as fast as the flap gauge moves now...that would actually be a plus because it would simulate a real scenario.
Thank you again
Jim
You probably got a notification of a new message, although maybe not because it's not working for me.
Anyway, I've been a bit busy, sorry, but I will do this, and soon.
Just wanted to drop a note to say so.
No problem ame...actually just sending a note to thank you for all your work and effort on this project. It is so nice to have functional..real time fuel gauges in the sim!!
I will post some video's soon.
Jim
Ok. Try this.
Quote/*
This code is in the public domain
For use with "Link2fs_Multi"
Jimspage.co.nz (via archive.org)
*/
int CodeIn;// used on all serial reads
String flaps;
String fuel; // Re-use this variable for all fuel gauges as we only do one at a time
// PWM pins for gauges.
// Must be one of 3, 5, 6, 9, 10, or 11 for Arduino Uno
// Flaps
int flaps_PWM_out_pin = 3;
// Fuel
int fuel_L_PWM_out_pin = 5; // Left fuel gauge
int fuel_C_PWM_out_pin = 6; // Centre fuel gauge
int fuel_R_PWM_out_pin = 9; // Right fuel gauge
// Variables for fuel gauges
float fuel_L_lbs;
float fuel_C_lbs;
float fuel_R_lbs;
// Record last needle position for damping
float filtered_fuel_L_lbs;
float filtered_fuel_C_lbs;
float filtered_fuel_R_lbs;
// Can be reused for each gauge as we do one at a time.
float fuel_percent;
int fuel_PWM_out;
// Variables for flaps
float flaps_degrees;
float filtered_flaps_degrees;
int flaps_PWM_out;
// Variables to support incremental update of gauges
unsigned long currentMillis;
unsigned long previousMillis;
unsigned long period = 100; // 100millis = 0.1s, 10 updates per second
// Variables for damping gauges
// The gauge on the simulator travels from 0 to 33 degrees in about 35 seconds
// But the simulator only reports integer degrees.
// Introduce fractional degrees for the physical gauge so that it
// moves smoothly between integer degree positions.
// Similarly, the simulator reports integer percentage of tank full.
// We convert to lbs, and allow the lbsx100 gauge to move at limited speed.
const float flaps_max_degrees_per_period = 0.0943; // Maximum amount we can move in 0.1s
const float fuel_max_lbs_per_period = 3000; // Maximum amount we can move in 0.1s
void setup()
{
Serial.begin(115200);
// Set up PWM pins.
pinMode(flaps_PWM_out_pin, OUTPUT);
pinMode(fuel_L_PWM_out_pin, OUTPUT);
pinMode(fuel_C_PWM_out_pin, OUTPUT);
pinMode(fuel_R_PWM_out_pin, OUTPUT);
// Set PWM values to zero.
analogWrite(flaps_PWM_out_pin, 0);
analogWrite(fuel_L_PWM_out_pin, 0);
analogWrite(fuel_C_PWM_out_pin, 0);
analogWrite(fuel_R_PWM_out_pin, 0);
// Start all filtered values at zero.
// If the simulator is already running, or the initial value
// reported is not zero then it will take a while for the
// gauges to match reality.
filtered_flaps_degrees = 0;
filtered_fuel_L_lbs = 0;
filtered_fuel_C_lbs = 0;
filtered_fuel_R_lbs = 0;
}
void loop() {
// Deal with incoming data from link2fs
if (Serial.available()) {
CodeIn = getChar();
if (CodeIn == '=') {EQUALS();} // The first identifier is "="
if (CodeIn == '<') {LESSTHAN();}// The first identifier is "<"
if (CodeIn == '?') {QUESTION();}// The first identifier is "?"
if (CodeIn == '/') {SLASH();}// The first identifier is "/" (Annunciators)
}
// Other tasks
// Smooth the needle output.
currentMillis = millis(); // store the current time
if (currentMillis - previousMillis >= period) { // check if 100ms passed
// We're on a 100ms boundary
previousMillis = currentMillis; // update the time we were here
// flaps_degrees is updated elsewhere when new data arrives.
// Filter the gauge needle position slowly over time.
if (flaps_degrees > filtered_flaps_degrees) {
filtered_flaps_degrees += flaps_max_degrees_per_period;
if (filtered_flaps_degrees > flaps_degrees) filtered_flaps_degrees=flaps_degrees;
}
else if (flaps_degrees < filtered_flaps_degrees) {
filtered_flaps_degrees -= flaps_max_degrees_per_period;
if (filtered_flaps_degrees < flaps_degrees) filtered_flaps_degrees = flaps_degrees;
}
else {
// target and current are equal. Nothing to do.
}
// Convert degrees to PWM 0-255.
// 33 degrees is full scale, so multiplier is 255/33=7.727
flaps_PWM_out = filtered_flaps_degrees*7.727;
analogWrite(flaps_PWM_out_pin, flaps_PWM_out);
// Now update the fuel gauges.
// Yes, this should be done as an array...
// Left
if (fuel_L_lbs > filtered_fuel_L_lbs) {
filtered_fuel_L_lbs += fuel_max_lbs_per_period;
if (filtered_fuel_L_lbs > fuel_L_lbs) filtered_fuel_L_lbs = fuel_L_lbs;
}
else if (fuel_L_lbs < filtered_fuel_L_lbs) {
filtered_fuel_L_lbs -= fuel_max_lbs_per_period;
if (filtered_fuel_L_lbs < fuel_L_lbs) filtered_fuel_L_lbs = fuel_L_lbs;
}
else {
// target and current are equal. Nothing to do.
}
// Centre
if (fuel_C_lbs > filtered_fuel_C_lbs) {
filtered_fuel_C_lbs += fuel_max_lbs_per_period;
if (filtered_fuel_C_lbs > fuel_L_lbs) filtered_fuel_C_lbs = fuel_C_lbs;
}
else if (fuel_C_lbs < filtered_fuel_C_lbs) {
filtered_fuel_C_lbs -= fuel_max_lbs_per_period;
if (filtered_fuel_C_lbs < fuel_C_lbs) filtered_fuel_C_lbs = fuel_C_lbs;
}
else {
// target and current are equal. Nothing to do.
}
// Right
if (fuel_R_lbs > filtered_fuel_R_lbs) {
filtered_fuel_R_lbs += fuel_max_lbs_per_period;
if (filtered_fuel_R_lbs > fuel_R_lbs) filtered_fuel_R_lbs = fuel_R_lbs;
}
else if (fuel_R_lbs < filtered_fuel_R_lbs) {
filtered_fuel_R_lbs -= fuel_max_lbs_per_period;
if (filtered_fuel_R_lbs < fuel_R_lbs) filtered_fuel_R_lbs = fuel_R_lbs;
}
else {
// target and current are equal. Nothing to do.
}
fuel_PWM_out = ((filtered_fuel_L_lbs * 1.8) / 10000.0) + 75.0;
if(fuel_PWM_out > 255) fuel_PWM_out = 255;
analogWrite(fuel_L_PWM_out_pin, fuel_PWM_out);
fuel_PWM_out = ((filtered_fuel_C_lbs * 1.8) / 10000.0) + 75.0;
if(fuel_PWM_out > 255) fuel_PWM_out = 255;
analogWrite(fuel_C_PWM_out_pin, fuel_PWM_out);
fuel_PWM_out = ((filtered_fuel_R_lbs * 1.8) / 10000.0) + 75.0;
if(fuel_PWM_out > 255) fuel_PWM_out = 255;
analogWrite(fuel_R_PWM_out_pin, fuel_PWM_out);
}
}
char getChar()// Get a character from the serial buffer
{
while(Serial.available() == 0);// wait for data
return((char)Serial.read());// Thanks Doug
}
void EQUALS(){ // The first identifier was "="
CodeIn = getChar(); // Get another character
switch(CodeIn) {// Now lets find what to do with it
case 'A'://Found the second identifier
//Do something
break;
case 'B':
//Do something
break;
case 'C':
//Do something
break;
}
}
void LESSTHAN(){ // The first identifier was "<"
CodeIn = getChar(); // Get another character
switch(CodeIn) {// Now lets find what to do with it
case 'A'://Found the second identifier
//Do something
break;
case 'B':
//Do something
break;
case 'G': //Found the second identifier ("G" Flaps position)
// Next three characters should be numeric
flaps = "";
flaps += getChar();
flaps += getChar();
flaps += getChar();
// convert 3-character numeric string to a float
// Expected range is 000 to 033
flaps_degrees = flaps.toFloat();
// Moving the needle will be done in the main loop.
break;
case 'X': // "X" left fuel gauge
// Next three characters should be numeric
fuel = "";
fuel += getChar();
fuel += getChar();
fuel += getChar();
// convert 3-character numeric string to a float
// It's a percentage of full, where full is 9200 lbs (left)
// Expected range is 000 to 100
fuel_percent = fuel.toFloat();
fuel_L_lbs = fuel_percent * 9200;
// Moving the needle will be done in the main loop.
break;
case 'Y': // "Y" centre fuel gauge
// Next three characters should be numeric
fuel = "";
fuel += getChar();
fuel += getChar();
fuel += getChar();
// convert 3-character numeric string to a float
// It's a percentage of full, where full is 4400 lbs (centre)
// Expected range is 000 to 100
fuel_percent = fuel.toFloat();
fuel_C_lbs = fuel_percent * 4400;
// Moving the needle will be done in the main loop.
break;
case 'Z': // "Z" right fuel gauge
// Next three characters should be numeric
fuel = "";
fuel += getChar();
fuel += getChar();
fuel += getChar();
// convert 3-character numeric string to a float
// It's a percentage of full, where full is 9200 lbs (left)
// Expected range is 000 to 100
fuel_percent = fuel.toFloat();
fuel_R_lbs = fuel_percent * 9200;
// Moving the needle will be done in the main loop.
break;
}
}
void QUESTION(){ // The first identifier was "?"
CodeIn = getChar(); // Get another character
switch(CodeIn) {// Now lets find what to do with it
case 'A'://Found the second identifier
//Do something
break;
case 'B':
//Do something
break;
case 'C':
//Do something
break;
}
}
void SLASH(){ // The first identifier was "/" (Annunciator)
//Do something
}
Thank you ame!!!
I will upload and test it out when I get home on Sat.. on another 4 day rotation:(
No worries. I checked that it compiles and does something...
@ame, thank you again for the code...it works perfectly, of course!
I have included a video...it starts off slow because I needed time to get back to the instructors panel and enter the fuel particulars.
https://www.youtube.com/watch?v=Fs60OvaKla4
Thank you again!!
Jim
Excellent. I changed a couple of things, but the end result is what's important, so if you're happy then it's done!
This line can be altered to allow the needles to move faster:
const float fuel_max_lbs_per_period = 3000; // Maximum amount we can move in 0.1s
Do you want to do analog input for the flaps lever, or is the project done now?
ame,
I think we can call this project complete! Everything works perfectly..thank you again!.