DCS-BIOS Discussion Thread

So, this is what it should be like then?

Guess we need to do some stress and performance tests with an Mega and some mini/nano's so we have any good facts about three slave boards.

If in reality it only works well with two slaves, it is quite a waste compared to use the Mega alone - when it comes to number of I/O's.

Perhaps it is necessary for performance if you have a lot of things going on (like servos)?

I have my MAX chips waiting, just need some time...

Great schematic!

Note that it's not a question of two or three slave devices but of two or three RS-485 buses. You can connect 32 "unit loads" to each bus. Each transceiver chip is one unit load, so that means 31 slave devices and one transceiver for the master on each bus.

There are also transceiver chips that have less than one unit load. The MAX487 that I recommended a while ago has 1/4 unit load, so you can connect up to 128 transceivers to one bus.

If you use biasing and termination resistors, this will affect the number of allowed devices, but because the MAX487 has slew rate limiting, you can probably get away without it as long as the length of the bus wire stays below about 10 meters.

In any case, with the right transceiver, a single Mega acting as a hub should be enough for the whole cockpit, regardless of whether it can support two or three buses.

Ian;2638948']Great schematic!

 

Note that it's not a question of two or three slave devices but of two or three RS-485 buses. You can connect 32 "unit loads" to each bus. Each transceiver chip is one unit load, so that means 31 slave devices and one transceiver for the master on each bus.

 

There are also transceiver chips that have less than one unit load. The MAX487 that I recommended a while ago has 1/4 unit load, so you can connect up to 128 transceivers to one bus.

 

If you use biasing and termination resistors, this will affect the number of allowed devices, but because the MAX487 has slew rate limiting, you can probably get away without it as long as the length of the bus wire stays below about 10 meters.

 

In any case, with the right transceiver, a single Mega acting as a hub should be enough for the whole cockpit, regardless of whether it can support two or three buses.

Aah... my bad. Shouldn't be doing two things at the same time.

No gain with a bus system if the bus isn't used properly ;) Here's an updated version.

126 (or 2 * 126) devices should be enough for most of us.

Just for information,

You can get free samples on the maxim website. the only one condition is to be registered on their website.

i have just ordered for 15x MAX487ECPA+. for free (20 doesn't accepted).

;)

Ian;2638948']In any case' date=' with the right transceiver, a single Mega acting as a hub should be enough for the whole cockpit, regardless of whether it can support two or three buses.[/quote']

 

I'm not sure that's true. While it can theoretically connect them, you don't want to poll a child board less than 4 times a second. If you poll less than 4 times a second per board inputs on that board will have a noticeable lag between activating the switch / control.

 

Running a 250k baud buss (which is really the max of the ability of atmega chips to process at the volume of data we are talking about), you're only going to about 24 children per bus. Once you've exceeded that you just can't cycle around fast enough. While a mega has more memory and IO pins, it's the same speed as the uno/leonardo/nanos. You will get some overlapping efficiency with multiple UARTS on the mega, I'm not sure it's enough to overcome the micro-controller speed bottle neck. Some output / input operations like reading and ADC or updating an text display often have a board which is slower to respond, so make sure your leave some headroom on your buses to accommodate them as well.

 

This is all based on me running about 5 instruments / panels on a test bus using a scope and protocol analyzer to verify timings. I then extrapolated out those timings to max number of boards before polling drops to unacceptable levels.

 

You've got roughly 10-14 panels/instruments per console so you're going to need at least 2 buses. I'd recommend 3 one for each console (right, center, left). This also gives you head room to have multiple children per panel, which is sometimes necessary or easier (ex: polling things the 12 analog inputs for the intercom board). I'd have a leonardo or mega per bus to interface with the computer. I'm sure a due could handle polling all three buses at once, but be careful in RS-485 driver selection as the due is 3.3v not 5v.

Ian;2636130']

• The DCS-BIOS Arduino library is now configured with #defines before including DcsBios.h. See the example sketches to see how this is done.
  

This is bad practice and will lead to problems. I realize some of the libraries distributed with arduino do this, but it's still bad practice.

The arduino IDE may not recompile the library if you change your defines in a sketch. It has no way of knowing the last compile of the library was invalidated by your change to your sketch. So it may not recompile the library and use a already compiled version with different define settings. You should treat libraries as DLL which are compiled once and distributed, not as code snipets which are included in a sketch build.

The only thing that defines can be used like this are changes in board / processor. The arduino IDE / build chain will properly keep track and recompile all libraries when you switch to a different target board.

Some more explanation here.

Some of the reasons it looks like you did this (bypass native serial stack) are not necessary anymore. With 1.5+ of the libraries they switched to bytes instead of ints, and fixed flush so you can properly implement a fast RS-485 using them. You can look at my arduino library for examples.

Thanks for the input Gadroc.

So, board prices aside, what would be the ultimate setup?

Let's say we have the right, center and left as the design principle. If they are all fed from one Mega, how much data will there be before the one serial connection to the PC gets choked?

If you have three serial connections to three Mega's, would that cause any performance loss on the PC?

If you have three serial connections, does it still have to be Mega boards, or could some other model be sufficient (assuming that you will have only one RS-485 bus per board).

Sending text, is that the most demanding task (besides doing some gfx stuff)? I guess update frequency/poll intervall is also an important factor. Is it then the servos that are most demanding or analog inputs?

I assume that an analog input doesn't need as high priority as an instrument etc.

Trying to figure out here what would be the best solution, and there are many variables to consider.

How can the RS-845 save me from Kabelsalat? I dont really get it :book:.

Gadrock suggested 3x buses. Does that mean one needs only 3x Nano's + 1x Mega to drive like total >=200 buttons, switches, pot-meters??

ATM i have 1x Arduino Uno for this;

This is bad practice and will lead to problems. I realize some of the libraries distributed with arduino do this, but it's still bad practice.

Would the problem be solved by using a separate include file for each mode (e.g. DcsBiosRS485Slave.h, DcsBiosRS485Master.h, DcsBiosDefaultSerial.h, DcsBiosIRQSerial.h) and using global variables or global inline functions in the DcsBios namespace to tell the library about the slave address and TX pins?

Some of the reasons it looks like you did this (bypass native serial stack) are not necessary anymore. With 1.5+ of the libraries they switched to bytes instead of ints, and fixed flush so you can properly implement a fast RS-485 using them. You can look at my arduino library for examples.

Did they fix serialEvent so it is acually called from an ISR?

I'm not sure that's true. While it can theoretically connect them, you don't want to poll a child board less than 4 times a second.

Running a 250k baud buss (which is really the max of the ability of atmega chips to process at the volume of data we are talking about), you're only going to about 24 children per bus. Once you've exceeded that you just can't cycle around fast enough.

I have attached a scope screenshot of 126 devices being polled (well, one device programmed to react to addresses 1 through 126). This shows that as long as the typical case is that no device has anything to say (yeah, I know I have to fix potentiometers to get there), we should be able to do about 20 polls a second for 126 devices on a bus.

Ian;2639509']I have attached a scope screenshot of 126 devices being polled (well' date=' one device programmed to react to addresses 1 through 126). This shows that as long as the typical case is that no device has anything to say (yeah, I know I have to fix potentiometers to get there), we should be able to do about 20 polls a second for 126 devices on a bus.[/quote']

 

Your math doesn't work out there, and it looks like your testing with a perfect dummy load. Polling 126 devices 20 times a second only gives you 396us per poll. That's only time to send 9 bytes at 250k baud and 36us processing overhead. This is absolute mathematical best case scenario here. Also you have to give some amount of timeout delay before moving to the next device, or you'll have problems with bus collisions as soon as you have devices responding a little late.

 

At 250k baud a 64 bytes packet is 2.5ms which is a common case. 32-64 byte packets will be a fairly common case. It happens 30 times a second with DCS-Bios updates, but also packets from panels are fairly large. Count how many text bytes are in a response from the panel. Example quickly switching a three position switch through it's positions easy climbs over 32 bytes (I know cause I had to increase my buffers to account for this.)

 

I allow for about 5ms per board for the polling loop with a 2ms timeout waiting for response. I'm assuming an average below max 64 byte packet size but with some response overhead time baked in. This gives a decent margin of error for slow boards or other anomalies but still allows for fast stream of sim output data. That would allow us to get to only 50 devices polled each second at 4 times a second. I take a conservative approach on that as well which is why I halve it to 24-32 devices. Predictability is much more important that absolute speed here. I'm being a little pessimistic on my estimates but your way over on the other side.

How can the RS-845 save me from Kabelsalat? I dont really get it :book:.]

You really have two options for running your cockpit.

Home Run Wiring

In this scenario you have large IO boards with 100s of inputs each. You run a large cable to each panel with enough wires for every switch on the panel. Here are some pictures of the kinds of cable harness you'll end up creating.

Pros

• Simple to understand as you're getting started
  
• Fewer IO boards and less complicated electronics
  
• Many examples (Bodnar boards, EPIC, etc...) most pits have been done this way in the past as the micro-controllers where complicated / expensive.
  

Cons

• Inflexible. If you later want to enable more functions on a panel you have modify cable harness at both connection to IO board and connection to panel. Changes make mapping harder later.
  
• Mapping IO board inputs becomes complicated, unless you plan really well up front and don't have a panel with inputs all over the place
  
• Hard to trouble shoot, requiring careful diagramming and labeling. Documentation will be key and keeping it up to date is crucial
  
• Often requires you to design "break out" pcbs to make wiring easier (often removing cost advantage)
  

Distribute IO Boards

Have a micro-controller at each panel / instrument and run a network (I2C, RS-485, Ethernet, USB, etc..) of them to the PC.

Pros

• Cabling is much reduced. Wires to each switch terminate at the panel itself and only power and network cables come out of the panel.
  
• Cabling is standardized and interchangeable making it easier to troubleshoot. (Power is always power and all network cables are the same)
  
• Flexibility. Upgrading a panel does not affect any of the other panels at all. If I add more switches or an led it only has to be wired in that panel.
  

Cons

• Higher up front cost for micro-controller and circuit boards at each panel. (although bigger pits it will come out in the wash as they require so many break out boards and expensive high pin count connectors)
  
• More complicated electronics. You need to be willing to learn at least a little about programming micro-controllers to make it cost effective.
  

Thanks for the input Gadroc.

 

So, board prices aside, what would be the ultimate setup?

Let's say we have the right, center and left as the design principle. If they are all fed from one Mega, how much data will there be before the one serial connection to the PC gets choked?

If you have three serial connections to three Mega's, would that cause any performance loss on the PC?

If you have three serial connections, does it still have to be Mega boards, or could some other model be sufficient (assuming that you will have only one RS-485 bus per board).

 

Sending text, is that the most demanding task (besides doing some gfx stuff)? I guess update frequency/poll intervall is also an important factor. Is it then the servos that are most demanding or analog inputs?

I assume that an analog input doesn't need as high priority as an instrument etc.

 

Trying to figure out here what would be the best solution, and there are many variables to consider.

See my reply to IAN. I recommend no more than 32 devices on a 250k baud RS-485 bus (an arduino can not keep up with anything faster, so this is the limit unless you move to ARM based arduinos). Leave yourself head room for errors and slow devices. For me it's easiest to think of the cockpit as three different USB devices that can be plugged and unplugged independently.

I suspect a arduino mega will have problems running 3 buses at once, but I haven't tested it. I have one here and intend on doing it, just haven't had the time. The 32 devices per bus I've definitively tested and have the math to back up.

There is some overhead in the computer proxying DCS-Bios to 3 serial ports, but I don't think it will be significant. You can always put another cheap computer (raspberry pi) which listens on the network for DCS-Bios and runs the serial ports. I happen to have a raspberry pi in my pit already displaying the HSI on 5" monitor so it handles the serial ports so the sim computer is not burdened.

It is important to note a few things about my comments:

1) my testing is all with my arduino library not IAN's new one, but most of the timings are based on defensive design and bus timings not the code.

2) I'm approaching this from the perspective of a full cockpit with several hundreds to thousands of IO lines. Ignore most of my concerns if you are wiring up a handful of devices. Most of this stuff is tremendously easy at small scale, but bites you in the ass at large scale.

Yes, it's a perfect dummy load. It's the absolute best case. But IMO it has enough reserves to work under more realistic conditions.

If it's enough to poll a device 10 times a second instead of 20, the 43 millisecond span I marked in the screenshot is allowed to expand to 100 ms. That's enough extra time to transmit about 1400 bytes (not accounting for delays in between, so let's halve that to 700), which should be plenty for any messages the panels want to send. If that's not enough, the maximum message size can be reduced to less than 10 bytes by switching to a binary export protocol, although I'd like to defer that to DCS-BIOS 2.0 where I want to change a bunch of other design decisions at the same time.

My biggest assumption here is that a panel will stay quiet on the RS-485 bus as long as the pilot doesn't touch it, and that the pilot will have at least one hand on the throttle and stick at all times (I know I do), so two panels wanting to send data at the same time is the exception rather than the rule. Otherwise it wouldn't make sense to connect more than one RS-485 bus to one serial connection to the PC running at the same speed.

You allow for a 2 millisecond timeout waiting for a response for each poll. That's way too pessimistic. The only way the "reaction time" of a board is going to increase is when interrupts are blocked for too long. And that won't happen longer than about 40 microseconds (the time it takes to transmit one character at 250000 bps), otherwise you are missing RX bytes and have bigger problems.

The number of devices is also unrealistically large at 126. Let's assume the Mega supports two buses, and we need 100 devices for the simpit (I think you estimated a total of 60 once), then 50 devices per bus sounds more realistic and can still support a full simpit. You can also design some slave devices as "output only", then they won't need an address on the bus, because all they do is listen.

I have seen three buses (with one device each) work, but the timing looks uncomfortably close on a logic analyzer, so it wouldn't surprise me to see that have intermittent issues in real-world operation.

All that said, I don't have any real-world data. I don't even have a pit :music_whistling:

I am curious to see what problems this will develop under realistic conditions, but still remain optimistic that we can make a single Mega work. Of course, even if we can't, it's not too big a deal, as splitting a bus up is not too hard.

I have started to think about a small production run of RS-485 transceiver shields for Pro Minis, both for the learning experience and to get a proper test platform for DCS-BIOS. I feel that the inability to quickly test any code change (instead having to constantly reassemble and tear down things on a breadboard) was the second-most important reason (after general lack of time) for my failure as a project maintainer to review and merge any pull requests in a timely manner.

Ian;2639644']If it's enough to poll a device 10 times a second instead of 20' date=' the 43 millisecond span I marked in the screenshot is allowed to expand to 100 ms. That's enough extra time to transmit about 1400 bytes (not accounting for delays in between, so let's halve that to 700), which should be plenty for any messages the panels want to send. If that's not enough, the maximum message size can be reduced to less than 10 bytes by switching to a binary export protocol, although I'd like to defer that to DCS-BIOS 2.0 where I want to change a bunch of other design decisions at the same time.[/quote']

I thought about a binary protocol as well, but deferred for the same reason. Didn't want to have to duplicate things already done in DCS-Bios.

 

Ian;2639644']My biggest assumption here is that a panel will stay quiet on the RS-485 bus as long as the pilot doesn't touch it' date=' and that the pilot will have at least one hand on the throttle and stick at all times (I know I do), so two panels wanting to send data at the same time is the exception rather than the rule. Otherwise it wouldn't make sense to connect more than one RS-485 bus to one serial connection to the PC running at the same speed.[/quote']

This is a bandwidth vs latency conversation. The bus has plenty of bandwidth, but putting more devices creates latency. You want < 250ms between the time you flip a switch and the sim is acting on it. Anything more than that and you notice it.

 

Ian;2639644']You allow for a 2 millisecond timeout waiting for a response for each poll. That's way too pessimistic. The only way the "reaction time" of a board is going to increase is when interrupts are blocked for too long. And that won't happen longer than about 40 microseconds (the time it takes to transmit one character at 250000 bps)' date=' otherwise you are missing RX bytes and have bigger problems.[/quote']

Add a device that updates a HD44780 style display and see how long you think 2ms is. You have to allow the child boards enough time to act on display information in addition to responding. These are not multi-threaded computers. Things like analogRead() take 100us on their own. Expecting <1ms response time while doing other things is going to be tricky. (Mind you I think it's doable, but you'll probably have to go bare metal and not use arduino libraries/runtime.) I hit figure of 2ms that from hooking up CMSP, Landing Gear panel and a few instruments.

 

Ian;2639644']The number of devices is also unrealistically large at 126. Let's assume the Mega supports two buses, and we need 100 devices for the simpit (I think you estimated a total of 60 once), then 50 devices per bus sounds more realistic and can still support a full simpit. You can also design some slave devices as "output only", then they won't need an address on the bus, because all they do is listen.

 

I have seen three buses (with one device each) work, but the timing looks uncomfortably close on a logic analyzer, so it wouldn't surprise me to see that have intermittent issues in real-world operation.

 

All that said, I don't have any real-world data. I don't even have a pit :music_whistling:

I am curious to see what problems this will develop under realistic conditions, but still remain optimistic that we can make a single Mega work. Of course, even if we can't, it's not too big a deal, as splitting a bus up is not too hard.

 

I have started to think about a small production run of RS-485 transceiver shields for Pro Minis, both for the learning experience and to get a proper test platform for DCS-BIOS. I feel that the inability to quickly test any code change (instead having to constantly reassemble and tear down things on a breadboard) was the second-most important reason (after general lack of time) for my failure as a project maintainer to review and merge any pull requests in a timely manner.

All true. It's also on my list to redesign my panel control board to have the pro mini's plug into it.

Things like analogRead() take 100us on their own. Expecting <1ms response time while doing other things is going to be tricky. (Mind you I think it's doable, but you'll probably have to go bare metal and not use arduino libraries/runtime.)

That's exactly what I am doing. Any code that doesn't disable interrupts for too long (which the LiquidCrystal library and analogRead() don't do at all AFAIK) won't interfere with RS-485 communication.

I have successfully tested with a 16x2 LCD showing the CMSP, the pin 13 LED hooked up to a random indicator light and a push button mapped to the signal lamp test button. I also added a delay(1000) to the loop() function for testing purposes, and the setup still worked correctly (with a lot of lag of course).

The new implementation of StringBuffer uses double buffering, so even driving a 320x240 TFT with an ATMega328 to display the CDU should work correctly, albeit slowly.

The list of ExportStreamListeners is kept in sorted order now, so the amortized complexity (I might be misusing that word here -- I learned about this stuff over two years ago) of traversing that list during one data update is reduced from quadratic to linear. The new receive buffer only has to compensate for the time spent traversing that list once and storing a copy of the data if an ExportStreamListener is interested.

Processing that data (i.e. emptying the receive buffer) is also prioritized over the main program, but it is still done with interrupts enabled, so it can be interrupted by other things (e.g. the timer interrupt to increment the counter behind Arduino's millis() and micros(), or storing another received byte in the buffer).

Here's the list of priorities from most important to least important:

- RS-485 communication, other interrupts (stock Arduino timer interrupt)

- parsing incoming data from DCS and storing the bits that are interesting to this panel

- everything else is called from loop(): reacting to data that has changed (changing GPIO pins, writing to displays, etc), checking to see if any switch or other input has changed and preparing a message to DCS

I still have no idea how many ExportStreamListeners are too much (although we can certainly handle a lot more than before). Without having any data to back this up, I'd say you are probably fine on a Pro Mini with its ~17 usable GPIO pins. You might be able to break it if you max out a Mega with outputs only, and it's likely going to break if you throw in enough I/O expanders or shift registers.

How can the RS-845 save me from Kabelsalat? I dont really get it :book:.

This is a very simplified picture of what Gadroc explained :)

You can always put another cheap computer (raspberry pi) which listens on the network for DCS-Bios and runs the serial ports. .

Hm... never considered that. I assume you have to add some stuff in export or is a network broadcast default?

What do I have to do on the Raspberry Pi - some kind of Python script listening and redirecting the data to the serial port(s)?

Sorry for disturbing.

I'm right now on designing some new boards (I try to make a SAS with MagSwitches). And before I do something stupid is there an important question: (it's a noob's question)

Is PIN13 of the NANO (designated as Digital) able to control the MAX487?

I love it compact and so I ran out of pins and it became a little bit tide at the PCB :)

Edit: Oh. I forgot. Ian: Congratulations. I'm so glad you made it.

Is PIN13 of the NANO (designated as Digital) able to control the MAX487?

You can use Pin 13 for the TX_ENABLE signal. The built-in LED will turn on whenever the TX_ENABLE signal is on, so you should get an activity indicator as a bonus.

The only problem I see is that the LED (and thus the TX_ENABLE signal) will turn on briefly when the Arduino is powered on, which would cause the RS-485 transceiver to drive the bus and disrupt any other communication. It's not ideal, but should not have any long-term ill effects; the software should recover from this (the RS-485 state machine resets whenever there has been nothing happening on the bus for 500 microseconds) and the internal current limiting and short-circuit protection in the MAX487 should prevent any physical damage.

In other words: test on a breadboard first, but if it works, you should be fine.

This is a very simplified picture of what Gadroc explained :)

My current kabelsalat has 2x Uno's for my MiG-21bis (still conntecyed to breadboard).

is the RS-845 sum sort of I2C IO-port multiplier?

does it mean, that only ONE COM-port would be needed for all arduino's?

like here below?

is the RS-845 sum sort of I2C IO-port multiplier?

Not quite. It's just a way for multiple Arduinos to communicate. (Also, it's RS-485, not 845).

idoes it mean, that only ONE COM-port would be needed for all arduino's?

Yes.

Sorry for disturbing.

I'm right now on designing some new boards (I try to make a SAS with MagSwitches). And before I do something stupid is there an important question: (it's a noob's question)

Is PIN13 of the NANO (designated as Digital) able to control the MAX487?

 

I love it compact and so I ran out of pins and it became a little bit tide at the PCB :)

 

Edit: Oh. I forgot. Ian: Congratulations. I'm so glad you made it.

Funny, I had the exact same idea yesterday night when I started to design a pcb because of the Nano pin configuration it would be very much more convenient to have the pin 13 used for communication :)

Meanwhile I found another solution: Suddenly I discovered a complete row of unused Analog Pins. Surprise!!!

So my situation has become relaxed :)

@Ian: Testing at a breadboard BEFORE etching a PCB is always a very good idea. But before that I have to persuade some chinese people to send me some :)

It is not that easy as I thought: There are so many different packages with different pinouts.

I ordered a few minutes ago some Max487esa at 10 Euros per 20 pcs. They will arrive mid of Feb :music_whistling:

Meanwhile I found another solution: Suddenly I discovered a complete row of unused Analog Pins. Surprise!!!

FYI: A6 and A7 cannot be used as digital I/O pins, they are analog input only. This has caused a lot of confusion for WarHog and me in the past before we finally took a closer look at the Arduino pin mapping and the ATMega328 datasheet :)

A0 through A5 can also be used as a digital I/O pin like you'd expect.

Meanwhile I did some progress in designing and understanding the RS485-DCS-BIOS Interface.

Anyway I'm a little confused about dimensions of Termination.

What I've learned is, it depends on the total length of the Bus.

To calculate this is beyond my horizon.

Experts (spread over the Internet) give different proposals:

They vary from 120 Ohms to 100 Kilos.

I can't imagine, that 120 Ohms are a good decission. I feel this close to a "short".

Could someone share his/hers experiences or knowledge?

Is there a table or a formula to calculate this?

Attached picture shows my actual situation. Terminator between A and B is on Layer 2 and so invisible.

Pin Rows belongs to the socket for NANO.

PS: To all None-Electronics: You see just the landing pads where IC and Resistors are to solder to :)