Major Announcement: New software to to connect panels to DCS

[Felm]

Ian;2319067']In my first experiment' date=' I used shift registers to read all nine encoders and did not have a problem. Unless you are building a motor controller or add some kind of gearing to turn the encoders really fast, I wouldn't worry about losing the occasional step.[/quote']

Great, that's what I was feeling too. I'll get to work.

 

Thanks Codetoad and Ian for your replies.

 

Ian, it's a good suggestion to have one Arduino per panel. Never thought of that. But I think some panels require many pins, and the pro mini does not seem to have enough inputs. In those cases I'd have to use a bigger board.

 

When you say pro mini clones, can you give a specific name as example, just in case I buy the wrong one.

 

You can also look at aliexpress. I usually compare prices between ebay/ali and get what's cheaper or higher rated etc.

 

For example you can get 10 minis for around 1.65usd each. free shipping for my country, if it's not for you then search again and tick the free ship button

 

I haven't ordered this so I can't vouch for it but it's the most ordered (I usually sort by "orders" but look around, there might be cheaper offers that are not the most ordered but still from legit sellers).

 

Don't forget that it's new year over there so everything slows down to a crawl...might be a while till you get your stuff, depending on your luck

Edited February 15, 2015 by Felm

[rocketeer]

Thanks Felm for the info about buying from aliexpress. I've bought clothes from there to US. I thought that's all they sell! lol

 

I'm aware it's chinese new year and everything comes to a standstill in china. Anyway I'm still doing research.

 

Given the number of total inputs needed for all panel exceed 300, even with Megas we'd need like 7 of those! So Ian's right, get a mini for each panel will be much cheaper given so many panels and inputs needed.

[rocketeer]

Given that there are 30+ panels on the A10C, is it really possible to daisy all 30+ panels via I2C without lag for just one USB to PC? Any external power supply required? More importantly is the I2C chaining 30+ panels fast enough?

[Felm]

I don't know about I2C limitations but I don't think you will have power issues if you are only doing inputs (the only draw will be the arduinos themselves which you will have to calculate).

 

If you need more inputs you can get port expanders or shift registers. However depending on your needs it might just be cheaper to get more boards. You will have to calculate the costs of expanders/ shift registers vs boards (there's also the other costs of building the circuit around the shift registers or expanders).

[FSFIan]

To connect the I2C bus, you need these connections:

• SDA to SDA
  
• SCL to SCL
  
• SDA via pull-up resistor to Vcc
  
• SCL via pull-up resistor to Vcc
  

 

There are a lot of tutorials on using I2C with Arduino on the internet that explain this in greater detail.

 

Yes, you need different code to make the boards talk -- that has been provided in the I2C master/slave template sketches.

 

On the chainduino: looks expensive. It would be cheaper to give each Arduino board its own USB connection to the PC (including the cost of additional USB hubs).

 

I have started a comparison on the Warthog Pit wiki.

[FSFIan]

Given that there are 30+ panels on the A10C, is it really possible to daisy all 30+ panels via I2C without lag for just one USB to PC? Any external power supply required? More importantly is the I2C chaining 30+ panels fast enough?

 

I2C with 30+ panels won't work because of the electrical limitations of I2C alone. I2C was originally designed to communicate between chips on the same circuit board.

 

I did some theoretical calculations once which said that you start out with 8 m of allowed wire length on your I2C bus and lose 0.3 meters for each device that you connect (assuming Cat5 cable). To guarantee reliable operation, you should stay way below that.

 

I think it may be possible to build a complete cockpit with three I2C buses (left console, front dash, right console), but I am not an electrical engineer. I am a software guy who doesn't even build his own simpit, so take everything hardware-related I say with a grain of salt or two.

 

The I2C transmission speed is pretty slow, but a human will only operate one control at a time anyway. The export data stream doesn't go over the I2C bus -- you simply connect the TX line from your USB-to-serial converter to several Arduino boards at once. That's also a source of possible signalling problems, especially over long wires (i.e. another reason why 30+ boards on a single bus won't work).

 

You will require external power for at least some of the panels (servos, backlighting, lots of indicator LEDs...). I recommend to use an old PC power supply -- even new they are cheap because they are mass-produced, and they provide you with lots of oomph at 3.3V, 5V and 12V.

[Gadroc]

There are approximately 36 panels which need circuits (including CP indicators and indexers as 1 panel). An Arduino Mini Pro has 20 input/output pins which can be used. According to my panel input spreadsheet this means 21 of the those panels can be managed by a single mini pro. The rest of the panels will require additional expansion chips or multiple Arduinos. Let's do a rough guess saying 4 of the panels will require two Arduinos that means just with panels we have 40 Arduinos.

 

In addition, assuming we are using an LCD for ADI/HSI, we still have 3 primary instruments (VVI, Altitude, IAS), about 6 secondaries (AoA, Clock, Oxygen etc...) and about 12 engine gauges. That's around another 18 Arduinos.

 

Grand total that's 58 Arduinos and if you count the I/O pins to drive seven segments your well into the 500-600 I/O lines. This is very different problem than just one board many are working on right now. I'm not sure we want to be trying to drive 58 individual serial buses all with the same data. It's not going to be manageable. While I love the DCS-BIOS export functions and network protocol, I don't think the arduino side scales properly to the protocol needed for running the entire cockpit.

 

Out of Band Commands / Configuration - Right now the protocol does not allow for sending commands to individual boards. It only allows for data from the simulation. In particular when we get to steppers you will need the ability periodically to re-zero them. This requires the ability of sending commands not just simulation data.

 

No Polling Capability - In order to fix the 58 individual serial buses, we will need some multi-drop support in the protocol. This requires the ability to pass a "talking stick" around the arduinos so each of them can speak it's input commands in turn without talking on top of each other.

 

Both are symptoms of not having a packet / addressing layer to the serial bus protocol. On the Ethernet side UDP does this for us. But we are currently just taking the contents of the UDP packets and sending them raw onto the serial bus instead of wrapping it in another packet format.

 

My current thought process is to divide the pit into 3 to 4 separate RS-485 buses. Right Console, Left Console and Center Console. Each of the buses would be controlled by a raspberry pi listening on Ethernet to the DCS-BIOS UDP stream. It would then map the DCS address space into an address space specific to that bus. This will narrow down the data needing to be sent each from on the serial bus to about 64-100 bytes per bus. Now I can loop sending those bytes to each board on the bus requesting any inputs they have. Each board responds and I move on to the next. This should allow 20 Arduinos per bus each being updated continuously and polled about 5 times per second.

 

That being said I could also subdivide it a little further where each console has two raspberrys. One for inner panels and the other for outer panels. This would have each pi managing about 10 usb serial ports. I'd still run into the command issue which will require some modification to the serial bus protocol. This is tempting from a power distribution standpoint as well.

[Gadroc]

Also for anyone using DCS-BIOS I have written a Java library to parse the UDP stream. I'm using it on a raspberry pi to render an HSI. You can find it here on my github (https://github.com/Gadroc/dcs-bios-reciever) account.

[Oldcooltronix]

Hello everybody,

 

I absolute beginner in things Inport / Export am I have a question.

 

Can I because the software with opencockpits cards (MasterCard, USBOutputs) use?

 

If so someone could help you set up?

 

Have since no real clear view ...

 

Thank you for your help and best regards

[FSFIan]

Grand total that's 58 Arduinos and if you count the I/O pins to drive seven segments your well into the 500-600 I/O lines. This is very different problem than just one board many are working on right now. I'm not sure we want to be trying to drive 58 individual serial buses all with the same data. It's not going to be manageable.

 

Why would that be a problem? In theory, you could take care of getting the export data to all of those panels with a single USB-to-serial converter (TX line connected to all boards in parallel). Now that converter chip obviously is not designed for a fan-out of 58 over long wires, but wouldn't a few non-inverting buffer ICs take care of that?

 

Out of Band Commands / Configuration - Right now the protocol does not allow for sending commands to individual boards. It only allows for data from the simulation. In particular when we get to steppers you will need the ability periodically to re-zero them. This requires the ability of sending commands not just simulation data.

The DCS-BIOS export data stream is just an efficient way to represent writes to a block of memory, so it lends itself to memory-mapped I/O. We can set aside some address space for "private use", so you can program your boards to change their configuration value(s) when data is written to a board-specific address. Would that fit your requirements?

 

No Polling Capability - In order to fix the 58 individual serial buses, we will need some multi-drop support in the protocol. This requires the ability to pass a "talking stick" around the arduinos so each of them can speak it's input commands in turn without talking on top of each other.

 

Wouldn't a multi-master-capable protocol that does collision detection (instead of collision avoidance by passing a token) be a better solution than polling? Collisions will be very rare because a pilot only has two hands, and most of the time one of those is on the flight controls. In the typical case, at most one Arduino will have anything to say at a given time. Of course this will require improving the current potentiometer handling code to reduce random jitter.

 

If I was designing a simpit professionally, I would probably just connect all boards to a single CAN bus (using a microcontroller with built-in CAN support to keep costs down) and be done with it.

 

Using Arduino boards, I think the way to get the job done with minimal resources is to use several USB connections to the host PC and connect small groups of boards with I2C to reduce the number of USB connections by a factor of three to five.

 

My current thought process is to divide the pit into 3 to 4 separate RS-485 buses. Right Console, Left Console and Center Console. Each of the buses would be controlled by a raspberry pi listening on Ethernet to the DCS-BIOS UDP stream. It would then map the DCS address space into an address space specific to that bus. This will narrow down the data needing to be sent each from on the serial bus to about 64-100 bytes per bus. Now I can loop sending those bytes to each board on the bus requesting any inputs they have. Each board responds and I move on to the next. This should allow 20 Arduinos per bus each being updated continuously and polled about 5 times per second.

 

That being said I could also subdivide it a little further where each console has two raspberrys. One for inner panels and the other for outer panels. This would have each pi managing about 10 usb serial ports. I'd still run into the command issue which will require some modification to the serial bus protocol. This is tempting from a power distribution standpoint as well.

When I read that, I see a lot of money being wasted on Raspberry Pis and RS-485 transceivers. That said, my brain is hardwired to think within the confines of a university student's budget, so maybe I'll see that differently in a few years.

[Mike Powell]

I strongly recommend the use of a robust signaling approach like RS-485/422. It may be overkill in many situations, but its use covers a multitude of sins. As the total system grows it becomes susceptible to all kinds of random problems. (Works great until the daughter uses her hair dryer/neighbor's garage door opener operates/etc.)

 

Any time you have a system with lots of wiring, uncertain grounding and shielding practices, multiple power supplies, residential AC power, etc. you will eventually be chasing intermittent problems that detract from the fun stuff.

 

Gadroc's ideas have merit.

[Puma]

Invert single pin & debounce

 

Loving DCS-BIOS so far.

 

2 questions:

 

1) Can I add a switch debouncer on an input pin? Seeing a little bounce on one of mine.

2) On my NSMP PTR switch, I have it "ON" in the "STOW" position, but this seems to be the opposite of the way you programmed it in single-pin mode. Can I invert the logic for it? I suspect I can use the 2 pin mode, but I tried with 0 as the second pin and that didn't work at all and I'd hate to waste a pin just for this.

 

Great work, great documentation. Thanks!

[Gadroc]

It's all about trade offs. Here are the signaling options I see at hand.

 

1 - Dedicated USB-TTL Each

In this case we will have to replicate the memory data to each individual serial bus. This will result in the computer doing a lot of lifting to replicate and transmit the same data 58 times. This is the simplest to do as there is no hardware design work. It is going to take a lot of USB hubs, but is roughly 15Mbs in data which should be no problem for High Speed USB 2. I would likely off load this from the main flight sim computer to be safe on performance.

 

Cost: $116 ($2 low end cable x 58 )

Cost: $125 ($25 10 port hubs w/ power adapter x 5)

Total: $241

 

2 - TTL Direct w/ I2C return

Just run cables between the serial tx/rx pins from many Arduinos. Theoretically this could work but is likely stretching the bounds. The cable will end up being several meters once daisy chained around the entire pit. This is likely going to pick up lots of noise form the PWM back-lights, stepper motors and servos. In addition that length of cable might cause problems with signal quality itself due to the capacitance of the wire. Some one really needs to do the math on this one before saying it's good. This may end up drawing more current from the drivers than they can handle. Or it may work just fine. One down side is it complicates using the I2C bus for other chips like IO Expanders.

 

Lastly what I'm really concerned here is the ground coupling across the boards. For the TTL signaling to work they all have to share the same ground reference. This means running ground wires between all the boards. I'd have to do some research on how to do that in a safe manner with out inducing unwanted current.

 

Cost: $6 ($2 low end cable x 3)

Total: $6 (but not sure it will even work at scale in the pit)

 

3 - Line Driver/Receiver

In this case you can select between RS-232, RS-422, RS-485, CAN and a few others. These drivers have clear specs on cable length and number of receivers which can be connected. CAN would require dedicated capabilities in the micro-controller as well as a transceiver. The atmega328 on the minis do not have CAN capability, which means a CAN controller IC, additional crystal and transceiver IC. This will cost $4-$6 in parts for just the can bus. In addition it will take a lot more space on a circuit board. RS-485 is a much better choice for the Arduino. I'm using the Texas Instruments SN75176B RS-485 driver. These can handle up to 32 transceivers on the bus and only cost $0.88 each at low volumes.

 

Cost: $51.04 ($0.88 per SN75176B x 58 )

Cost: $6 ($2 low end cable x 3)

Cost: $105 ($35 raspberry x 3)

Cost: $50 (twisted pair wire)

Total: $212.04

 

Plans 1 and 3 are with in spec of all the components and I have high confidence they'll work with little error. RS-485 is actually cheaper once you factor in the usb hubs. In addition you'll probably run into issue with windows on the $2 usb cables. They are almost guaranteed to be counterfeit Prolific or FTDI chips as the chips themselves inside the cables cost that much at volume. The latest drivers from those companies may not work with the counterfeit chips. Non-counterfeit cables cost $10-$15 each.

[agrasyuk]

When I read that, I see a lot of money being wasted on Raspberry Pis and RS-485 transceivers. That said, my brain is hardwired to think within the confines of a university student's budget, so maybe I'll see that differently in a few years.

 

why wasted? i wouldn't say that. with several USBs on board (additional joystic and HID controlers) that device makes really nice hub for DSC-BIOS. and then there is on board GPIO :)

 

 

and to add to that list i just came across ODROID.

http://www.hardkernel.com/main/products/prdt_info.php?g_code=G140610189490

http://www.hardkernel.com/main/products/prdt_info.php?g_code=G141578608433

 

so many cool computer/electronic stuff, so little time :)

[Gadroc]

Ian;2319849']The DCS-BIOS export data stream is just an efficient way to represent writes to a block of memory' date=' so it lends itself to memory-mapped I/O. We can set aside some address space for "private use", so you can program your boards to change their configuration value(s) when data is written to a board-specific address. Would that fit your requirements?[/quote']

That is possible, but has problems with the end of frame markers. Right now the protocol marks begin frame as 0x55 0x55 0x55 0x55 and the end is a write to address 0xFFFE. Then 0x55 0x55 0x55 0x55 doesn't come again for 33ms.

 

It might be better to merge some of the EOS protocol and DCS-BIOS for the serial bus protocol. Have an enveloping / command structure like EOS with three commands:

 

Command 1 - Begin Frame (Sent from PC when it gets 0x55 0x55 0x55 0x55)

Command 2 - Data Write

Command 3 - End Frame (Sent form PC after it detects write to 0xFFFE)

Command 4 - Poll (Sent when no frame data is coming from the simulation)

 

Now we can add additional commands to do other things with out mucking with the simulation memory space. PC makes sure each packet is 128 bytes or less and each command packet has a byte for the board who is allowed to reply. I would then continually loop through 1-20 response addresses and send out a command 1-4 depending on state and wait for up to 5ms for a response. Then go to the next.

 

Boards that have inputs would be assigned 1-20 address and boards which only have outputs dont have an assigned address.

[hegykc]

Hi there. I don't have time to go through the entire thread as I am neck deep into my projects, but what's the situation on stepper/servo control?

 

Can it control motors according to in-game outputs? Because in a few months my 30$ per instrument promise is coming true, possibly even way less then that. But I don't have time for coding and programing. I can provide basic logic for the motors, but someone would have to do the actual programing.

 

So, can dcs bios do steppers and servos with arduino?

[Gadroc]

Servos are easy and can be done out of the box. Although you need to be very careful about wiring and current to not blow your arduino.

 

Steppers are a different story they require a stepper driver module and more careful timing to work correctly. I have proper timer driven stepper code with acceleration done in EOS and I will be porting over.

[hegykc]

Thanks. Yes I know the basics about servos and steppers, but some of the gauges cannot be done by servos, like the altimeter. I did the calculations a year or two ago but if I remember correctly, after gear reduction each step of the servo would be 30 meters on the gauge? not much of a resolution.

 

Steppers however are limitless and with a driver module and an optical zero switch it can do wonders. So if you guys figure out the software side of things, I will provide hardware beyond your wildest dreams, at student prices too.

 

EDIT:

So servo's are ready to go? Can I make my A-10 engine cluster and send it to someone for testing

Edited February 16, 2015 by hegykc

[rocketeer]

I appreciate everyone's input so far, but now I'm kinda lost with the discussions. For someone new to Arduino, the discussion about the various techniques is getting too complex for me. I guess no one has yet to wire all panels using Arduino to tell us what works and what doesn't.

 

If we have two I2C buses for for each console, one for the inner and one for outer console, for the left and right consoles, and also two buses for front dash given many instruments, so total six I2C buses, 6 USB to PC. Is this good enough in terms of performance and is it doable?

[FSFIan]

The advantage of the I2C solution is that it's the cheapest and the code for it exists now. The huge disadvantage is that nobody knows for sure how reliable it will be (i.e. how many boards / how much wire length one I2C bus can take in practice). The reliability will also depend on the quality and type of wiring (shielded Cat5 recommended) and the amount of electrical interference.

 

A reliable solution that works right now is to use one USB connection per Arduino. Cost is about $3 per Arduino board (including the cost of cables and hubs).

 

The current discussion aims to come up with a solution that is easier to manage and less expensive than the USB one, but just as reliable. The half-duplex RS-485 bus is a good candidate because it has been around for decades and there are inexpensive transceiver chips available, but to use it, new software will need to be written. Because it uses differential signaling, RS-485 is a lot more robust in the presence of electrical interference and can operate reliably over bus length that are many times longer than what you would encounter in a simpit.

 

If you are new to the Arduino platform and programming, start out with one USB connection per Arduino board. Once someone comes up with an improved design for handling multiple panels, you can switch to that for new panels and possibly even adapt existing ones.

[rocketeer]

Ian, I noticed your double clicked on some command executable for each board in your youtube when each is linked to PC via USB, to make the boards talk to DCS. Gadroc counted 58 arduinos is needed to power all switches in the A10C cockpit. Does that mean one has to manually double click the exe for each board 58 times?

[rocketeer]

Also, would there be a limit to how many usbs can be connected to a PC, via hubs?

[rocketeer]

I noticed a mega clone is about $22. It has 54 pins vs mini pro's 14. So it'd cut down the number of usb cables by 4 times. If I have to go the usb route instead of i2c then i'd get a bunch of mega clones.

 

Having one board per panel is ideal, but if i2c chaining too many board is not good and using one usb per board is too many cables, then using mega is a compromise to reduce cable count and using mega clone to reduce cost instead of arduino brand.

[FSFIan]

Ian, I noticed your double clicked on some command executable for each board in your youtube when each is linked to PC via USB, to make the boards talk to DCS. Gadroc counted 58 arduinos is needed to power all switches in the A10C cockpit. Does that mean one has to manually double click the exe for each board 58 times?

 

The DCSBiosCOMHandler that ArturDCS made should take care of that.

 

Another solution would be to throw a Raspberry Pi into the mix (or any other Linux machine) and script it so that any USB-to-serial converter that is plugged in will automatically be connected to DCS-BIOS.

 

The maximum number of USB devices is 128 per USB controller (each hub also counts as a device). On a motherboard, I think there is typically one USB controller per one or two USB ports.

 

Don't think of the USB solution as the final design -- think of it as a stopgap measure that allows you to start building and learning while a RS-485 based solution is being developed.

[bnepethomas]

Ian;2320408']The DCSBiosCOMHandler that ArturDCS made should take care of that.

 

Another solution would be to throw a Raspberry Pi into the mix (or any other Linux machine) and script it so that any USB-to-serial converter that is plugged in will automatically be connected to DCS-BIOS.

 

The maximum number of USB devices is 128 per USB controller (each hub also counts as a device). On a motherboard, I think there is typically one USB controller per one or two USB ports.

 

Don't think of the USB solution as the final design -- think of it as a stopgap measure that allows you to start building and learning while a RS-485 based solution is being developed.

 

Something interesting is the Max number of USB devices, I hit the limit well below 30 devices, for an onboard controller. I hit when with a Simmeters gauges stack and a couple of Open Cockpits card. Had to install a second USB card to get to a happy place. I'm increasingly looking to using UDP as my output transport, whilst it does mean some address assignment and management, it does allow you to test stuff insituation from another computer if you so wish. It also is a little easier to debug, I did purchase some nice I2C troubleshooting tools/hardware, which definitely helps, but it still can be 'fun' to troubleshoot which something doesn't work as advertised.

 

Don't get me wrong this is an awesome project, but I thought its worth sharing some pain that I've run into with stuff I least expected to cause me pain.

 

Cheers

 

Peter