DCS-BIOS Discussion Thread

[hannibal]

Ian;2464192']To make this work for all aircraft' date=' you'd need to add airspeed to the CommonData export module. As mentioned above, pull requests are welcome (or remind me in a few months when my exams are over and I'll have moved into a new place).[/quote']

 

thank you!

ima get an arduino uno...

[Nasty76]

Idea when computer usb is full and you have raspberry pi.

install example minibian , connect 1 , 2 arduino via usb , look /dev/which tty arduinos has and make some nice sh script

#!/bin/bash

chmod 666 /dev/ttyACM0

 

stty -F /dev/ttyACM0 500000

stty -F /dev/ttyACM0 raw

socat udp-sendto:192.168.1.80:7778 /dev/ttyACM0&

 

 

chmod 666 /dev/ttyACM1

 

stty -F /dev/ttyACM1 500000

stty -F /dev/ttyACM1 raw

socat udp-sendto:192.168.1.80:7778 /dev/ttyACM1

where ttyxxxx is your arduino com port , and adjust ip where your dcs game running and vola u are cleared hot. now raspberry pi collect usb data in your home cockpit and sent them to game. easy as walking in park , not sure if this feature is documented somewhere.

then run script ./yourscript name.

i self have crontab -e

@reboot /path/to/your/sript.sh so every time pi start that load ur cockpit to ready.

i have make sd card read only so i can take power off raspberry without worry to sdcard messed up

[flashtom]

Hi,Ian

 

I met an issue on 74hc595.

 

before i use 74hc595, i can easily define an arduino pin X in DCS-BIOS program,

 

such as : "DcsBios::Switch2Pos cmspArw1("CMSP_ARW1", X);"

 

But in order to extend arduino's i/o interface, i try to use 74HC595,

 

there is no more specific pin number,

 

if i use only one 74hc595, how can i define the pin number in DCS-BIOS's program?

 

thanks.

[FSFIan]

if i use only one 74hc595, how can i define the pin number in DCS-BIOS's program?

 

You can't. You have to write your own modified version of the Switch2 class that knows how to read the data from your shift register. (The next version, which I hope to release this year, will make this a bit easier and allow you to override the pinMode, digitalWrite, and digitalRead functions that a class instance will use, but you'll still have to write those.)

 

Supporting things like shift registers and I/O expanders in a generic way is not really possible, except in a very inefficient way where having five switches would result in the entire state being read five times instead of once, so it will always require custom code.

 

See also this issue for an example LED class which works with a MCP23017 (but I think this is the inefficient way of reading the complete state over I2C every time you need a single bit of data). It would be more efficient to read the state once in loop(), save it in a variable and read it from there in the LED class.

[Gadroc]

I've been working on a new arduino library to go with DCS-BIOS. It works very similar to Ian's excellent work. It adds a set of hardware abstraction classes, support for stepper motors, RS-485 support. It also uses accelerated IO functions. I currently have the library running over RS-485 polling 32 boards 10 times a second each while sustaining the 30fps data updates from DCS-BIOS.

 

Base Library: dcs-bios-arduino

MCP23018/23017 Extension:dcs-bios-arduino-mcp

Servo Extension:dcs-bios-arduino-servo

 

Documentation is stil a bit thin but will be updating over the next few weeks. What is available is at the dcs-bios-arduino wiki. You can also see the sketches I've made for the panels I've converted here.

 

To support a 74HC595 you would model it off the MCP23017. Except instead of using I2C to read the expander your shift in through bit banging.

[Gadroc]

Just took a quick look and the 74HC595 is an output shift register, so it would be modeled after the MCP23018 code not the MCP23017. The 74HC595 is a serial to parallel shift register which takes serial in from 3 pins and turns it into 8 outputs. You can't really go the other way with that chip. For inputs you'll want a chip that does the opposite, like a CD4021B.

 

I've gone with the MCP23017 and MCP23018 which use I2C so I can use the same two pins for both Input and Output expanders. If you do a bit more code you can split the inputs and outputs on the MCP chips to support 8 in and 8 out on the same chip.

 

If using the 74HC595 pay attention to the current limits on the IC. If you're using it to drive LEDs at 20ma you'll only really be able to drive one at a time with out exceeding the chips current limit.

[Warhog]

I've been working on a new arduino library to go with DCS-BIOS. It works very similar to Ian's excellent work. It adds a set of hardware abstraction classes, support for stepper motors, RS-485 support. It also uses accelerated IO functions. I currently have the library running over RS-485 polling 32 boards 10 times a second each while sustaining the 30fps data updates from DCS-BIOS.

 

Base Library: dcs-bios-arduino

MCP23018/23017 Extension:dcs-bios-arduino-mcp

Servo Extension:dcs-bios-arduino-servo

 

Documentation is stil a bit thin but will be updating over the next few weeks. What is available is at the dcs-bios-arduino wiki. You can also see the sketches I've made for the panels I've converted here.

 

To support a 74HC595 you would model it off the MCP23017. Except instead of using I2C to read the expander your shift in through bit banging.

 

This looks to be rather exciting. I was wondering if you had tested the stepper motor code with actual motors yet. From looking at the ino file it appears your assuming the user will be employing driver boards with step and direction pins. I don't know if your familiar with the Vid series of motors. They are a very popular 4 pin motor used for gauges and can run directly from an Arduino board without creating an over current situation or needing a driver board . But they will require 4 pins and different code. Is this something you could include?

 

As much as acceleration has been included in your code, you can actually remove it as it's not necessary . I had some discussions with the author of the Accel Library and the designer of the Easy Driver board and it was agreed that acceleration is not necessary in our application. We are not moving any kind of large mass up to a specific speed. In fact, all we are doing is mimicking the movement of a pointer which exists in a virtual setting that already has "the appearance" of what acceleration actually does. Acceleration is necessary for CNC but when we just want to create a gauge for a cockpit, which is basically just a Repeater, we do not need acceleration . An added benefit of removing acceleration is that the code will run even more efficiently.:)

 

I was wondering how you were intending to zero the stepper motor in the sketch of the VVI and Altimeter. I didn't see any reference to setting zero, or the start point in your examples. Could you elaborate on this please.

 

Gadroc, could talk a little about the wiring needed for th RS-485 and what is required so I can do some testing.

 

And one final comment, I would like thank you for your time and effort in this project. What Ian and yourself have contributed to this community has made it possible for so many to take their cockpits to a level that only a few have ever been able to achieve. I commend you both for your contributions.

 

John

[Tekkx]

In fact, all we are doing is mimicking the movement of a pointer which exists in a virtual setting that already has "the appearance" of what acceleration actually does.

 

This is exactly what I've been thinking. (Without knowing so much about coding)

 

But this doesn't affect Ians and Gadrocs great work. Thank you.

 

Acceleration could become interesting, if someone build a "moving" Cockpit. Like real Sims does. There are great masses to move (some of us more, other less ;) ).

 

So don't Shift-Delete your code. :)

[Warhog]

From what I understand, acceleration takes up a good bit of time to implement so leaving it in the code when it won't enhance the quality of a gauges movement is not really justifiable. If someone decides to build a full on motion simulator I think they will be using a much different code (a robust code) for DCS-BIOS to run the motion controls. (especially if it's me in the cockpit):music_whistling: :lol:

 

But one thing I learned over the past few weeks about using stepper motors is that the Arduino boards are just barely powerful enough to run three or four motors simultaneously and do it accurately and without any lag. Now understand that I am not speaking from experience here. But I have been doing a lot of research to try and diagnose why Adrians Altimeter was loosing steps when he was in a full dive http://forums.eagle.ru/showthread.php?t=145193. To that end I consulted with Mike McCauley, the author of the Accel Library and Brian Schmalz who designed the Easy Driver board as they have both done a lot of work with stepper motors and various MCU's. They both stated that the Arduino board has limitations in driving stepper motors. Now maybe if you use one Arduino board for two gauges it will not be an issue but there are over 40 stepper motors needed for a full cockpit so that becomes a bit of a problem.

 

But my point here is that any code related to driving stepper motors should always be tweaked to the point of maximum performance. Removing acceleration is just one step (pun):music_whistling: closer toward that goal.:)

[Gadroc]

I'll do some testing with and without acceleration this weekend. I have three gauges setup right now VVI, Altimeter and IAS using steppers. Each have different movements. IAS has the wheel and needle, VVI is straight to the needle and Altimeter has needle + the drum counters. The acceleration may also make the movement smoother as the steppers have a tendency to snap to their half steps strongly shaking the low mass needles. I've already implemented a threshold so the motor doesn't move unless it has a minimum number of steps to allow for smoother movement. The acceleration can just be set really high if you don't need it so the code will probably remain the same.

 

Right now my setup sends the steppers back to zero position when you shutdown the cockpit. Not all the gauges have a clear zero position. For example my alitmeter has to reset till the drum counter is at zero not just a 360 degree needle position. Intent is to add a zero position to my VVI. It will be a simple matter of during setup picking a direction to move and rotating until a digital input pin is triggered. The stepper code will be getting some enhancements so you can increment it / decrement it and re-zero.

 

I'll have to order a few of the VID steppers and driver chips. I'm debating between them and servos for my engine instruments. I also have some really tiny 6mm stepper motors I want to try.

[Gadroc]

From what I understand, acceleration takes up a good bit of time to implement so leaving it in the code when it won't enhance the quality of a gauges movement is not really justifiable. If someone decides to build a full on motion simulator I think they will be using a much different code (a robust code) for DCS-BIOS to run the motion controls. (especially if it's me in the cockpit):music_whistling: :lol:

 

But one thing I learned over the past few weeks about using stepper motors is that the Arduino boards are just barely powerful enough to run three or four motors simultaneously and do it accurately and without any lag. Now understand that I am not speaking from experience here. But I have been doing a lot of research to try and diagnose why Adrians Altimeter was loosing steps when he was in a full dive http://forums.eagle.ru/showthread.php?t=145193. To that end I consulted with Mike McCauley, the author of the Accel Library and Brian Schmalz who designed the Easy Driver board as they have both done a lot of work with stepper motors and various MCU's. They both stated that the Arduino board has limitations in driving stepper motors. Now maybe if you use one Arduino board for two gauges it will not be an issue but there are over 40 stepper motors needed for a full cockpit so that becomes a bit of a problem.

 

But my point here is that any code related to driving stepper motors should always be tweaked to the point of maximum performance. Removing acceleration is just one step (pun):music_whistling: closer toward that goal.:)

 

This is important to understand. An ATMEGA chip only has enough juice to drive one maybe two steppers. Thankfully you can get a Arduino mini pro for $3.99. That being said the EOS code could outdrive my 0.9 degree steppers. I used to have to drive them with an interrupt but the current code runs fine without lag.

[Warhog]

I'll do some testing with and without acceleration this weekend. I have three gauges setup right now VVI, Altimeter and IAS using steppers. Each have different movements. IAS has the wheel and needle, VVI is straight to the needle and Altimeter has needle + the drum counters. The acceleration may also make the movement smoother as the steppers have a tendency to snap to their half steps strongly shaking the low mass needles. I've already implemented a threshold so the motor doesn't move unless it has a minimum number of steps to allow for smoother movement. The acceleration can just be set really high if you don't need it so the code will probably remain the same.

 

Right now my setup sends the steppers back to zero position when you shutdown the cockpit. Not all the gauges have a clear zero position. For example my altimeter has to reset till the drum counter is at zero not just a 360 degree needle position. Intent is to add a zero position to my VVI. It will be a simple matter of during setup picking a direction to move and rotating until a digital input pin is triggered. The stepper code will be getting some enhancements so you can increment it / decrement it and re-zero.

 

I'll have to order a few of the VID steppers and driver chips. I'm debating between them and servos for my engine instruments. I also have some really tiny 6mm stepper motors I want to try.

 

How are you handling the "going past 12 o'clock" situation with the altimeter? As you know, one 360 degree revolution is equal to the DCS export value of 65,535. Are you counting the number of full revolutions? On all my continuous rotation stepper motors I have a IR receiver/emitter setup that triggers a digital pin and sets zero at precisely the same location and then everything starts from that point.

 

I'll have to order a few of the VID steppers and driver chips. I'm debating between them and servos for my engine instruments.

 

The VID stepper motors are specifically designed for use in automobile gauges. They have very little, if any, shake and thats probably because they have approx. 945 steps/revolution . Imagine using micro stepping with these motors at 8 micro steps/full step. We would be talking about some very large numbers. So far I have found that micro stepping these little motors is not required but I have taken it up to 4 steps/full step on occasion. There is a lot of flexibility using these motors. I guess that is one reason they are so popular, especially among the racing enthusiasts.

 

So far I have the VVI, Air Speed, AOA and even part of my Standby ADI running the VID motors. In the photos below you can see the VID 60 motor with the integrated IR detector for zero setting. Its built right into it. And then there is the two shaft VID motor (just barely visible in the pic) running the dial face pointers. It works very well just in full steps so far.

 

 

I am now in the process of getting my EMI running. All the motors are installed and ready to calibrate.

 

 

Because this panel has so many gauges, I have decided on a different tact. I am going to be using 12 Easy Driver boards (btw, Chinese knockoffs are $1.50 ea) and a ChipKit UNO32 which runs at 80MHz. This way I can run all 12 motors with one board. All the other gauges will use the Pro Minis.

 

The acceleration may also make the movement smoother as the steppers have a tendency to snap to their half steps strongly shaking the low mass needles.

 

I have had the same issue with some of my NEMA motors. There are several ways to deal with the shake and one is to implement micro stepping. That is actually one of the major reasons I started using the Easy Driver boards because its so easy to control the size of the step. In fact I understand that you can actually change from micro stepping to full steps on the fly. I have no idea how to do that but it certainly would solve the issue of shake completely. You use full steps at high speed and as the motor slows down it goes into half step, then 1/4 step and ultimately micro steps at very slow speeds. Result...no shake. Unfortunately that is beyond my level of programming as are most things.:music_whistling:

 

The whole issue of getting gauges up and running, and running well, can be very problematic as I am finding. If there is anything I can help with or to brain storm or talk out a problem that I may have already dealt with, let me know. I have a fair number of gauges already built but not fully tested however I would be happy to do what I can to assist. :thumbup:

[toxaq]

two shaft VID motor

Where did you get these from? I've been trying to track them down. The X40 seems to be special order only. Amazing work BTW.

[Warhog]

Thank you Toxaq.

 

All the VID series motors I purchased are available on

http://www.aliexpress.com/item/Glorification-vid29-02-original-car-instrument-stepper-motor-changan-star-instrument-motor/1522916989.html

 

There also appears to be another knockoff on AliExpress. Prices can be as low as $1.50 each so it pays to check out a number of vendors before you put down money.

 

Btw, all these knockoffs are based on the original Switec Stepper motor. The price of Swtec is also quite low so it really doesn't matter what manufacturer made the motor as they are all exactly the same. The appearance may be a bit different.

 

The standard stepper is the VID29-05

Double shaft stepper is the VID28

Continuous rotation stepper is the VID60 (built in IR detection)

 

Gadroc, these particular motors only draw 20mA (max) so multiple motors on a single Arduino is not a concern from an over current perspective. This might be of assistance.

http://guy.carpenter.id.au/gaugette/resources/vid/20091026113525_VID29_manual_EN-080606.pdf

[Patriot]

Hi all!

Is it possible to get data for CDU from DSC-BIOS? Anyone can help to make a demo sketch?

 

It's fake data on display. Created only font for CDU and library for work this noname display.

[toxaq]

Thanks Warthog, great info. I've got some P-51 gauges going with some X27s but obviously want to get an altimeter sorted, even though it's technically 3 rotating elements. I'm still at the b&w print stuck to MDF stage :) Couldn't quite work out which motors were duals on aliexpress so thanks for confirming. The X40 is stacked through the back so much more compact than the VID28 you've pointed me to. Got a photo of that in situ per chance? I'm keen to give it a crack.

 

Gardoc, I used the driver from the gaugette link Warthog has given you. It's not configured for full rotation out of the box but the accel curves work well. You can also buy the VID6066 chips to drive multiple switec clones I believe. I've not tried.

 

Patriot you can access all the data in DCS-BIOS direct via the custom method access which is listed here In the drodown select the A10 and then select whichever value you're after. onDcsBiosWrite is where you're looking to access those values. If you've got the master caution example going, you should be good to go on customising what you need.

[FSFIan]

I am excited to see the progress that has been made over the last few days, even though I haven't done any significant work on DCS-BIOS for months now. I am looking forward to spending more time with DCS-BIOS development again now that I have finally moved into my new place.

 

Gadroc: I took a quick look at your new library. I like the hardware abstraction layer, it's a lot easier to use than what I had in mind. If I understand the protocol correctly, the only important difference between your protocol and that of my prototype is the address space of 32 vs. 127 devices. While I don't think that more than 32 devices on a bus is a good idea, it would be convenient if devices on different buses would still have distinct addresses. That would make it easy to plug a device into a different bus temporarily for troubleshooting.

 

I will continue working on my completely interrupt-driven implementation, but I will try to stay compatible to your developments where feasible.

 

The second piece of exciting news is that airtom has completed Ka-50 support. I wanted to merge it today, but unfortunately I am stuck with a high-latency 10 KB/s internet connection over 2.5G (GPRS/EDGE) right now. Yesterday, a package was supposed to arrive that contains an adapter needed to connect my cable modem in the new place. Online tracking shows "2nd delivery attempt will be made", which according to DHL means that the driver cancelled his tour due to traffic/accident/health reasons.

I temporarily switched to a 5 GB/month 3G plan on the SIM card in my laptop, but apparently it can take "up to 24 hours" for that to take effect. In 2015. Seriously, how hard is it to run your billing cron jobs once an hour instead of once a day?

 

In the long term, I want to finish v0.2 of the original Arduino library (before the end of the year if I can) and call that 1.0 after the bugs are ironed out. After that, I will either focus on mission scripting again (depends on what EDGE brings) or think about designing a DCS-BIOS 2.0 where every previous design choice is up for reconsideration. I'd like to include the developers of other software (Helios, HawgTouch, iControl DCS, ...) in the planning phase. The ideal outcome would be a DCS-BIOS 2.0 where adding an aircraft to DCS-BIOS would make it available in Helios and HawgTouch with minimal extra effort, and less effort to build simpits that are suited to more than one aircraft.

[Gadroc]

@Warhog

Yea just did some testing and the acceleration is definitely necessary in some scenarios. For example the nema 11 I have to use to fit in my altimeter needs acceleration to be able to drive all the gearing in the real altimeter. My VVI which is directly connected to the needle runs fine with out it... although the pointer is more "vibraty". All of my steppers are run using the EasyDriver board at 8 microsteps. Debating about cutting circuit boards that house pololu driver boards as then we can get up to 32 microsteps.

 

When I was talking about juice I was meaning clock speed (poor choice of words considering the topic). I would never run motors directly off the arduino. I was intending on using VID66-06 driver chips for the VID steppers. It can run 4 VIDs.

 

@Ian

Yes the address space would be nice. Keep in mind we are dealing with very tight timings here though. The bus driver will have to be smart and stop polling addresses which are not responding or otherwise your update rate from each board will be to slow. You want each board to be able to send it's outputs at least 4 times per second to feel real time. I'll look to add this to mine later today.

 

Which piece are you looking to be interrupt driven? Based on my current timings even running steppers seems to work fine without interrupts. The only thing that has caused problems is the LiquidCrystal library that comes with Arduino, but if you use a faster replacement for it it works fine. It's on my todo list to include native support for it in the library using my accelerator for digital IO.

[Gadroc]

@Warhog

Also I pushed up a version of the library which allows disabling of the acceleration. If set to 65535 the code will go straight to run mode with very little overhead vs non-accelerated code. Give it a try if you want.

[FSFIan]

Yes the address space would be nice. Keep in mind we are dealing with very tight timings here though. The bus driver will have to be smart and stop polling addresses which are not responding or otherwise your update rate from each board will be to slow. You want each board to be able to send it's outputs at least 4 times per second to feel real time. I'll look to add this to mine later today.

 

Which piece are you looking to be interrupt driven? Based on my current timings even running steppers seems to work fine without interrupts. The only thing that has caused problems is the LiquidCrystal library that comes with Arduino, but if you use a faster replacement for it it works fine. It's on my todo list to include native support for it in the library using my accelerator for digital IO.

 

The bus driver is smart enough to do that. Since I plan to dedicate a Mega to run the bus driver code, I have plenty of memory so allocating 128 bytes to store which addresses are present does not hurt. Every poll cycle, one of the "known absent" devices will be polled. This allows hotplugging of new devices / resetting a device independently of the rest and also ensures that we regularly run into a timeout condition, which new devices can wait for to synchronize to the data stream (i.e. don't try to parse anything until there has been no communication for 1 ms).

 

The goal is to make all communication interrupt driven. That has two advantages: (1) people will no longer use <insert slow library of your choice here>, get garbage data, and file a bug against DCS-BIOS and (2) we can poll devices a lot faster. Think "polling 100 devices 30 times a second while still sending the export data over the same bus" (rough estimate, but my first tests show that this might actually be possible). In theory, you could run the entire cockpit off a single RS-485 bus. In practice, you still want two or three, because shorter buses leave more wiggle room for interference and faulty wiring, the above poll rate is only for the usual case where none of the devices have anything to say, and it is great to switch to a different bus to find out if an issue is with your device or the bus wiring.

[Warhog]

Yea just did some testing and the acceleration is definitely necessary in some scenarios. For example the nema 11 I have to use to fit in my altimeter needs acceleration to be able to drive all the gearing in the real altimeter.

 

In situations where you are driving a mass, such as the gearing you mentioned, acceleration is a must. I was being rather general by saying that acceleration is not necessary as I was assuming most gauges would consist of just a pointer attached to a shaft. Your solution to have choice in the code to either use acceleration or not is perfect. I must admit that when I consider some of my other projects, such as my real 5" ADI which will be retro fitted with steppers, I will be driving a substantial mass. In that case I will need acceleration.

 

 

My VVI which is directly connected to the needle runs fine with out it... although the pointer is more "vibraty". All of my steppers are run using the EasyDriver board at 8 microsteps.

 

Did you try adjusting the current with the built in pot on the Easy Driver board. I had some terrible movement in some of my testing. Adjusting for the correct current made a huge difference. When you do it on the fly, you can hear the change it makes.

 

 

Debating about cutting circuit boards that house pololu driver boards as then we can get up to 32 microsteps.

 

As long as you recognize the potential issues going that high. For instance your slow speed is ultra smooth but as you increase speed you loose torque and now your tiny pointer weighs 2 lbs. One of the other problems using 32 micro steps is the number of steps per revolution that are generated. At at higher speeds they will become unmanageable especially with a 16mhz Arduino.

 

I think the solution to getting smooth operation throughout all the possible speeds a gauge may be subject to is by using a transmission so to speak...like an automobile transmission. (Holly shit this guys is nuts):crazy: as in a transmission that changes gears with speed. I don't know how this would be accomplished in code but you would change step rates as the speed changes. At high speeds full steps are perfect, at low speeds 1/8 steps are perfect and then something proportional in between the 2 extremes.

 

I know from experience that some gauges can be run with VID29-05 motors and need nothing else at all. My AOA gauge is only using Stepper.h as the library and it runs beautifully right from an Arduino board. I ran it for six hours as a test. But I will, in fact, switch it over to the Easy Driver to save pins and also to be consistent.

 

When I was talking about juice I was meaning clock speed (poor choice of words considering the topic). I would never run motors directly off the arduino. I was intending on using VID66-06 driver chips for the VID steppers. It can run 4 VIDs.

 

I have seen several people run four VID motors from a Mega. Total current draw is less than 20mA/motor so we are only at 80mA. I believe you can safely take it up to 200mA total devices per board without fear of damage. But that's a terribly inefficient as you need four pins per motor which is a waste when pins are always at a premium.

 

I have 4 VID 6606 chips and I tried to drive the VID motors with one and then another but no success. I will have another go at it when I get some time but so far I am pleased with the Easy Driver boards

 

I'll download your changes to the code and see what we get. We'll talk more in the very near future.

 

Thanks again Gadroc for spending time on this.

 

John

[Gadroc]

How are you handling the "going past 12 o'clock" situation with the altimeter? As you know, one 360 degree revolution is equal to the DCS export value of 65,535. Are you counting the number of full revolutions? On all my continuous rotation stepper motors I have a IR receiver/emitter setup that triggers a digital pin and sets zero at precisely the same location and then everything starts from that point.

 

Sorry meant to answer this yesterday. I simply keep track of stepper position as a long. This allows for 671,000 rotations in either direction when using a 0.9degree stepper driven at 8 microsteps. No need for anything more fancy. You just need a function in your pit to return all steppers to zero before powering down. In addition due to the real drum counters on my altimeter I have to do it this way. My HSI has two rotary encoders and a push button to allow for menus to re-calibrate steppers if necessary.

 

The second piece to this is actually extracting the information for DCS-BIOS to do this. Here is how I extract altititude:

IntegerListener altNeedlePosition(0x107e, 0xffff, 0);
IntegerListener alt1000FtPosition(0x1082, 0xffff, 0);
IntegerListener alt10000FtPosition(0x1080, 0xffff, 0);

void onDcsBiosFrameSync() {
   unsigned long alt = ((alt10000FtPosition.getData() / 6553) * 10000) + 
                       ((alt1000FtPosition.getData() / 6553) * 1000) + 
                       (altNeedlePosition.getData() / 65);
   needleOutput.setTargetPosition(alt * 1.6);
}

 

Craig

[FSFIan]

I did a quick test in the 1.5 open beta and it looks like everything works without modification. If you find something that works in 1.2.x but is broken in 1.5, please file a bug report.

[hannibal]

Ian;2500275']I did a quick test in the 1.5 open beta and it looks like everything works without modification. If you find something that works in 1.2.x but is broken in 1.5' date=' please file a bug report.[/quote']

 

awesome.. now i can continue with my lua, DCS-BIOS and arduino studies

[pappavis]

Potentiometer in MiG-21bis

 

hi!

 

I've connetced a potentiometer to set MiG-21bis' "TGT_SIZE"-parameter.

It crashesh the serial transfer between DCS-Arduino.

 

Something weird happens;

1. When I put my hands closeby :joystick: to the potentiometer the serial output would go wild reporting TGT_SIZE like this:

TGT_SIZE 0
TGT_SIZE 64
TGT_SIZE 0
TGT_SIZE 192
TGT_SIZE 0
TGT_SIZE 64
TGT_SIZE 0
TGT_SIZE 64
TGT_SIZE 0

 

2. When I turn the potentiometerknob from 0 position, to something more, it would really go WILD.. increasing the TGT_SIZE to 5893, This rapid increase happens with me just barely turning the meterknob. Then, withing like 1 second, then the serial output stops. The pushbutton for engine start then also stops responding.

 

> 2015/10/07 16:59:56.403753  length=62 from=101148 to=101209

UUUU....21....+.
.....:"....."..]I..\b..?.wi......"............< 2015/10/07 16:59:56.409254  length=1890 from=71939 to=73828
TGT_SIZE 2562
... etc etc
TGT_SIZE 5957
TGT_SIZE 5893
TGT_SIZE 5957
TGT_SIZE 5893
TGT_SIZE 58> 2015/10/07 16:59:58.517070  length=50 from=102084 to=102133
UUUU....Bi....Lv..*"......."..EI."\b.Gw............> 2015/10/07 16:59:58.521068  length=54 from=102134 to=102187
UUUU\b...s.....+.
......"......."..DI."\b.Jw............

 

DCS Version=1.2.16

DCS-BIOS version=0.4.0

potentiometer setup, left=GND, right=5V, middle=A0

 

What am i doing wrong?

 

 

here is my sketch;

#include <DcsBios.h>
#include <Servo.h>

int pot_a0 = A0;
int pot_midway = int(1023/2);
int led_intern = 13;

/* Instantiate a ProtocolParser object to parse the DCS-BIOS export stream */
DcsBios::ProtocolParser parser;

// ****** DCS: MiG-21bis ******
DcsBios::Potentiometer tgtSize("TGT_SIZE", pot_a0);

void setup() {  
 Serial.begin(500000);  
}

void loop() {   
 // DCS-bios. feed incoming data to the parser  
 while (Serial.available())
 {
     // Read the pot and set the LED. --> https://arduino-board.com/tutorials/potentiometer
     if (analogRead(pot_a0) > pot_midway)
     {
       digitalWrite(led_intern, HIGH);
     }
     else
     {
       digitalWrite(led_intern, LOW);
     }
     
     parser.processChar(Serial.read());
 }

 // poll inputs
 DcsBios::PollingInput::pollInputs();
}

 

potentiometer setup, left=GND, right=5V, middle=A0

 

 

regards,

159th_pappavis

Edited October 7, 2015 by pappavis