Gadroc

This would be great. It would help for anyone using bass shaker devices as you don't want radio chatter to vibrate your seat. I believe I've seen it as a request to the development team before, but that was a long time ago.

LOL! I'll add her to the list. I know of least two wives in town I've been warned never to meet.

I have one of those adafruit board sitting right here and a pile of micro servos. Was just about to start designing my EMI cluster.

You can find my method for backlighting here. It uses about 8-14 LEDs per panel, but gets a very nice light.

Looks good... I hope thats an arduino due w/ a ARM processor as I don't think you'll be able to smoothly run 14 steppers off an avrmega chip.

Since I'm using a virtual HSI (Raspberry Pi w/ 5" display) I added two rotary encoders and a button to it. I have a menu system in it which can zero gauges and send commands to the sim computer. I'll use an used button on the HOTAS to pause / recenter Track IR.

Looks great. Nice workmanship on the consoles!

I think you have over coupled DCS-BIOS extractor and the DCS-BIOS Arduino libraries. The extractor makes no assumptions about the hardware interface, it just supplies data. It also supplies all data as it makes no assumptions about the hardware interface. I agree with keeping it that simple as it removes burden from all down stream projects which use it (like mine, I don't want to have the "configure" DCS-BIOS every time I talk to it). All that being said it does mean DCS-BIOS will almost always be paired with a hardware controller component (like DCS Integrator, Helios or a custom one like my cockpit controller). Interceptor could still speak DCS-BIOS to DCS World and translate to your desired protocol model for the hardware integration. I actually have code that does that where I was following your same principle and only transmitting the data to each RS-485 bus needed for that bus. After getting the code stabilized and doing timings the effort wasn't worth the squeeze so I just started wrapping the DCS-BIOS data in RS-485 packets. This brought my code simplicity down significantly. It should be very possible to enhance DCS-BIOS to send the aircraft type as a few bytes at the beginning of each "frame". When the hardware controller component (DCS Integrator application) see this change it can re-initialize it's hardware configuration. The nice thing about this type of design is it moves most of the decision logic out of the flight simulation processing loop. I run the hardware controller software on a raspberry pi so the DCS rig has full CPU to do physics and graphics.

I went low level on EOS to remove some problems with the 1.0x Arduino serial libraries. The flush command did not wait for all UART data to be sent, so you could not implement the transmit pin drop to listen for responses. In addition the old serial libraries used ints for everything so where much slower and consumed significantly more ram. Also I was able to collapse to one buffer for serial reading and protocol parsing. 1.5+ Arduino libraries have fixed many of these problems, and since I've moved to a streaming protocol (DCS-BIOS) instead of a pure packet based protocol I don't need two buffers. So my newer DCS-BIOS based Arduino code just uses the existing Stream based Serial objects. I'll check some of my data tonight, but there are roughly 10-15 panels per console (center, right and left consoles). I believe there is somewhere on the order of 400 switch positions that need to be monitors, and 150 indicators lights, 50 indicator needles.

@Warhog It's not necessarily that developers like to work alone (on the contrary the best code happens from multiple developers collaborating and keeping each other from taking shortcuts). There are multiple issues when trying to co-ordinate a hobby project like this. First is schedules, for example Ian has school exams and moving recently which left him little time to work things like pull requests. With out being able to communicate closely it was easier for me to split the arduino code and work on my version of it. I'm more than happy to contribute it back. Second is we have different itches that we are trying to scratch. So i'm interested in enhancing the library in different ways. Given sufficient communications that actually is a good thing as we'll make progress in multiple areas at the same time. With out being able to do that we end up recreating work. @Oliver Looks good so far. It's pretty close to what I was doing with EOS. On your post I saw mention of bit banging a RS-485 bus. I'd do the math on timing, in order to keep up with the update rate of a cockpit I don't think it's feasible to run at those kind of baud rates (9600). If a button or switch takes over about 500ms it's noticeable when using the cockpit. Early test may look good, but I would definitely mock up the 10-20 boards it will take for a console before committing fully to an approach. Also make sure you do it with a few things that have a constant stream of data like gauges (VVI, IAS, etc...). I'd also keep a keen eye on memory consumption. You're putting a lot of dynamic things on the ATMEGAs which have very limited RAM. One my lessons from Helios is the "binding" approach is not clear for most users. For developers it's seems easier than code, but the concept is not as clear for most users. I had several power users who got it and made wonderful profiles, I was more inundated with my doesn't it just work questions when configuring profiles. While I'm sure GUI clean up could have helped, the tone of the questions ran deeper than that. It's an up hill battle to do the "make it easy" approach. Pick a target audience and stick to it.

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

@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.

@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.

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.

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.

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.

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.

For all intents and purposes that board is a USB connected arduino. It has a USB driver chip, a micro controller and two stepper driver chips. Think of it as an arduino + stepper shield all on one board. The micro controller takes input from the USB interface and translates it into a set of pulses going to the stepper drivers at the right timing along with a set of pulses to fire the laser. I run stepper motor based gauges on the same principle. I hook up pins of an arduino to a stepper driver IC. People usually use easy stepper or pololu compatible stepper daughterboards as they simplify some things in the circuit design and allow them to be replaced.

Ki, I'm interested.

Bandwidth is pretty important for RS-485 version that needs to poll 10-21 input boards. I've got it working well right now with timings of 3-5 polls per second, but that's with packet sizes of 31 bytes. The full text protocol is pretty heavy weight and separate push and release messages are over 31 bytes. I've bumped the packet size to 64 bytes, but that starts to eat a lot of memory on a 2k ram chip. It's bordering having to use my own serial routines to bypass their buffers, as dynamic memory space is getting really tight.

I have a suggestion for magnetically held switches. Currently magnetically held switch expose three inputs. { interface = "action", argument = "PUSH", description = "push and hold the switch in the ON position" }, { interface = "action", argument = "RELEASE", description = "release the switch" }, { interface = "action", argument = "OFF", description = "put the switch in the OFF position" } The separate PUSH/RELEASE are good for keyboard or button interactions, but if you have a real mag switch there is no trigger for the RELEASE. You can setup the device to send PUSH and RELEASE actions but that takes up valuable bandwidth with trying to manage 400+ inputs across the cockpit. I'd like to change it to the following: { interface = "action", argument = "PUSH", description = "push and release the switch from the ON position" }, { interface = "action", argument = "HOLD", description = "push and hold the switch in the ON position" }, { interface = "action", argument = "RELEASE", description = "release the switch from the ON position" }, { interface = "action", argument = "OFF", description = "put the switch in the OFF position" } This would allow setting up either a simulated or real switch with only one input definition in the arduino library. If people think it makes sense I'll submit a pull request for it.

I've found a bug in the CMSP on/off/menu switches. I have not looked further but the same problem probably exists in all switches with a momentary position. If you look at the lines from the clickabledata.lua file here is how they defines the CMSP MWS switches (all four are identical in definition outside of button ids and text). elements["PNT-TMB-CMSP-MWS"] = { class = {class_type.TUMB, class_type.BTN}, hint = _("Missile Warning System (MWS). Left mouse - ON/OFF, Right mouse - MENU (No Function)"), device = devices.CMSP, action = {device_commands.Button_10, device_commands.Button_11}, stop_action = {0, device_commands.Button_11}, arg = {360, 360}, stop_value = {nil,0.1}, arg_value = {0.1, 0.2}, arg_lim = {{0, 0.1}, {0.1, 0.2}}, use_release_message = {false, false} } Notice that class is actually listing two classes not one. The switch (type TUMB) sends button 10 with values of 0.0 when entered and 0.1 when exited. While the momentary position sends Button 11 with 0.2 when entered and 0.1 when exited. Currently DCS-BIOS defines the same line this way defineTumb("CMSP_MWS", 4, 3010, 360, 0.1, {0.0, 0.2}, nil, false, "CMSP", "Missile Warning System OFF - ON - (MENU)") It only sends Button 10 with all three values 0.0, 0.1 and 0.2. On initial testing this will seem to work, but will lead to some very weird behaviors of the CMSP in real world use. I made the same mistake early on with Helios as well. I'm still trying to fully grok the DCS-BIOS code for a proper fix to this.

You have to use a scanning matrix. If you use 8 row input pins and 8 column input pins you can scan 64 inputs. It takes little more planning and more complicated wiring but it's not to bad. A google search in "arduino input matrix" should turn up a few tutorials.

Thanks for the update. I already have an inverter but would have loved the filter/amp combo. It's not easy to find a decent cost working w/ pin out static inverter!

Mike - Excellent progress!! Depending on cost I may think about actually getting my HSI working. I just put it on the shelf after realizing it's 6-8 synchros to drive. Ian - The DS1054Z is an awesome scope for the money. I assume you've unlocked it to full capability. It's been essential for me debugging DCSBios / Arduino Library. Being able to trigger on a serial decode byte is awesome. Don't bother getting an old analog if you have it (have one sitting in the closet now).