Modern Interfacing solutions

[RayS]

The bad news is that the results are inconsistent. I don't know if the switches are bad (when they are $11 each normally and $1 each from China you have to wonder...) or if the design is incompatible with the HT16K33.

...

It's quite clever, but the switching event is very brief. It is literally a pulse. The HT16K33 has debouncing code inside, and I think it massages away a genuine switch closure as if it were a bounce.
 

You might try attaching an interrupt in your Arduino code to the pins the switch is connected to.

https://www.arduino.cc/reference/en/language/functions/external-interrupts/attachinterrupt/

Do this so that no matter what your Arduino is doing, the interrupt will cause the Arduino to literally drop everything and service the interrupt.

Note this thread has been moved from the 'What have you done for you simulator thread' to keep it on topic

[ame]

The bad news is that the results are inconsistent. I don't know if the switches are bad (when they are $11 each normally and $1 each from China you have to wonder...) or if the design is incompatible with the HT16K33.

...

It's quite clever, but the switching event is very brief. It is literally a pulse. The HT16K33 has debouncing code inside, and I think it massages away a genuine switch closure as if it were a bounce.
 

You might try attaching an interrupt in your Arduino code to the pins the switch is connected to.

https://www.arduino.cc/reference/en/language/functions/external-interrupts/attachinterrupt/

Do this so that no matter what your Arduino is doing, the interrupt will cause the Arduino to literally drop everything and service the interrupt.

True, and thank you for the suggestion, however, I'm not using an Arduino. The switches are connected to the HT16K33, and it does all the work. By nature the HT16K33 has to poll the switches, it can't use interrupts, since it interleaves the switch polling with the LED matrix driving.

The host (whatever is driving the I2C bus that the HT16K33 is attached to, which in my case is a Raspberry Pi) can then poll the chip to get the switch state, or there is an interrupt line from the chip that the host could detect. However, the interrupt only fires when the HT16K33 has detected a keypress via its own internal polling.

I might hook up one of the switches to an Arduino anyway, to see if I can reliably detect the short switch closures with interrupts, but I'm not that interested. If I have to have an Arduino I might as well use rotary encoders.

I think using Arduino in flight sims is old hat, and there must be something better. Hanging a bunch of I2C devices off a two-wire bus is so much more modern. General cockpit devices such as LEDs and switches are handled easily by the HT16K33, but rotary encoders aren't. I thought I had a viable solution with pulse switches, but perhaps not. Back to the drawing board. Probably an MCP23017, but then it would be separate from the LED driver.

[Joe Lavery]

I think possibly the cost and technical experience will be a factor in the use of Arduino's with FS.
For instance a Micro Arduino Mega 256 and some MAX7219 chips is a very economic and well supported method of setting up radios, or MCP's.
Of course I realise that this may be limiting for some advanced users, working on specific projects. But for those like myself who have limited knowledge and virtually no programming experience, the (old hat) methods work just fine.
A new Raspberry Pi costs £54 whereas a Mini Mega Arduino is £5.00. You can run a complete 737 overhead with just 4 or 5 Arduinos.

Just my 2 Cents of course.

Joe.

[BushPilotSimmer]

How about two monostable timers to debounce and extend the pulse per switch. 556 timer or Arduino Pro Mini - the Swiss Army Knife of electronics.

[ame]

How about two monostable timers to debounce and extend the pulse per switch. 556 timer or Arduino Pro Mini - the Swiss Army Knife of electronics.

Hi there,

Normally this would be a viable option, but as I said, the HT16K33 interleaves the switch polling with the LED driving, so the switch is not "in circuit" all the time. Anything more complex than a piece of wire that is connected to another piece of wire or not isn't going to work, sadly.

[ame]

I think possibly the cost and technical experience will be a factor in the use of Arduino's with FS.
For instance a Micro Arduino Mega 256 and some MAX7219 chips is a very economic and well supported method of setting up radios, or MCP's.
Of course I realise that this may be limiting for some advanced users, working on specific projects. But for those like myself who have limited knowledge and virtually no programming experience, the (old hat) methods work just fine.
A new Raspberry Pi costs £54 whereas a Mini Mega Arduino is £5.00. You can run a complete 737 overhead with just 4 or 5 Arduinos.

Just my 2 Cents of course.

Joe.

You are absolutely right. But I think it's time for something better.

You're onto it with the MAX7219- a custom chip for a specific purpose. The chip is driven by an Arduino, but it could easily be driven by a Pi. If we ignore the switch input then the HT16K33 is functionally identical but operates over I2C.

Consider the MCP23017 port expander. I2C to 16 GPIO pins.

ADS1115 I2C analog input

MCP4725 I2C DAC

PCA9685 I2C PWM

etc.

These are the chips I am experimenting with. And I think I2C is a versatile way to physically distribute the signals around the cockpit. Yes, you can plonk down an Arduino anywhere, but then you have to hook it up to the host (via USB), hope you have a spare USB port, and the serial port changes each time you plug it in.

[Trevor Hale]

I think possibly the cost and technical experience will be a factor in the use of Arduino's with FS.
For instance a Micro Arduino Mega 256 and some MAX7219 chips is a very economic and well supported method of setting up radios, or MCP's.
Of course I realise that this may be limiting for some advanced users, working on specific projects. But for those like myself who have limited knowledge and virtually no programming experience, the (old hat) methods work just fine.
A new Raspberry Pi costs £54 whereas a Mini Mega Arduino is £5.00. You can run a complete 737 overhead with just 4 or 5 Arduinos.

Just my 2 Cents of course.

Joe.

You are absolutely right. But I think it's time for something better.

You're onto it with the MAX7219- a custom chip for a specific purpose. The chip is driven by an Arduino, but it could easily be driven by a Pi. If we ignore the switch input then the HT16K33 is functionally identical but operates over I2C.

Consider the MCP23017 port expander. I2C to 16 GPIO pins.

ADS1115 I2C analog input

MCP4725 I2C DAC

PCA9685 I2C PWM

etc.

These are the chips I am experimenting with. And I think I2C is a versatile way to physically distribute the signals around the cockpit. Yes, you can plonk down an Arduino anywhere, but then you have to hook it up to the host (via USB), hope you have a spare USB port, and the serial port changes each time you plug it in.

I will agree to disagree. I have replaced a hodge podge of interfaces for Mega's and had zero issues. All of which are centralized at the FS Pc. 

if your Arduinos are changing ports on you every time you plug them in you have other issues. That shouldn't happen

I will also stick with the old stuff if it's old.  I don't have any need for a data bus to run inside my cockpit at this time. 

trev

[KyleH]

Ame, you're on the right track with your thinking for a flexible properly engineered solution.

I2C is not an appropriate solution for use throughout the cockpit though. It is meant for inter chip communication within a circuit board or assembly. In the cockpit environment with longer wire runs you want to use a CAN BUS or RS485 type protocol that is more noise immune.

This is the way I have my sim setup. On my flight sim PC I have a single USB connection to and RS485 converter. Then each panel in the sim has a microcontroller on it that looks after that panels functions, and communicates on the RS485 bus.

For the pulsed switches/encoders in your case, a cheap microcontroller can be programmed to use an interrupt and send the data out over your I2C bus.

[Joe Lavery]

Ame, I think you're missing my point somewhat and your list of custom chips is a perfect illustration of it.
Because I for one have no idea what devices these numbers refer to, or what they are capable of.
I'm sure there are many on the forum that are familiar with them, and able to write the programs necessary to interface them. But many others are not, and for us the arduino is a brilliant little (cheap) device that is easy to work with.
However I fully agree that USB is not an ideal interface, but once they are installed you rarely need to unplug them, except perhaps for maintenance. 

I also appreciate that some of us cling on to the electronics and more basic programming that the arduino provides. Yet I still applaud folk like yourself who push the boundaries; even if you drag us screaming and kicking into the future of our hobby. 

Joe

[RayS]

I'm with Kyle on this. I'm currently working on converting my sim inter-communications over to CANBUS. This will allow me to free up 19 USB ports on my main sim system and use maybe 1 or 2 Teensy 3.5 as the Master controller with the rest of the microcontrollers all slaved to the CANBUS.

The added benefit is this approach will let me easily (Relatively speaking) convert the sim over to MSFS2020 when the time comes without having to replace all 20 microcontrollers.

[ame]

Ame, I think you're missing my point somewhat and your list of custom chips is a perfect illustration of it.
Because I for one have no idea what devices these numbers refer to, or what they are capable of.
I'm sure there are many on the forum that are familiar with them, and able to write the programs necessary to interface them. But many others are not, and for us the arduino is a brilliant little (cheap) device that is easy to work with.
However I fully agree that USB is not an ideal interface, but once they are installed you rarely need to unplug them, except perhaps for maintenance. 

I also appreciate that some of us cling on to the electronics and more basic programming that the arduino provides. Yet I still applaud folk like yourself who push the boundaries; even if you drag us screaming and kicking into the future of our hobby. 

Joe

Let's just say the state of the art of the hobby is a bit behind the curve. There's nothing wrong with that, especially if something works, however there are a lot of new ways to achieve the same thing much easier.

I had a friend who was building a sim. He was bemoaning the state of cockpit hardware, so I started designing and building some stuff. It's been a lot of fun, and I will publish my designs as open source when they are ready. I will also publish the code for any driving software or firmware.

Which leads me on to the fact that there is no good Open Source cockpit system around right now (correct me if I'm wrong- I'd love to see it, and contribute).

[ame]

I'm with Kyle on this. I'm currently working on converting my sim inter-communications over to CANBUS. This will allow me to free up 19 USB ports on my main sim system and use maybe 1 or 2 Teensy 3.5 as the Master controller with the rest of the microcontrollers all slaved to the CANBUS.

The added benefit is this approach will let me easily (Relatively speaking) convert the sim over to MSFS2020 when the time comes without having to replace all 20 microcontrollers.

Using CAN is not a terrible idea, but it's not really popular for hobbyist stuff. RS485 would be a great solution too, probably better because it's simpler. The point is that nobody is using it. I2C is a great solution- cheap, abundant, versatile modules, popular with hobbyists, etc., but nobody is using that either.

Except these guys:
wiki.flightgear.org/FG_Interface

...but then I don't know how popular FlightGear is.

[KyleH]

There is one company using a CAN bus for their interfacing.

As I said I2C is for short distance, intra-board communication. It is not suitable for the distances and noise levels in a simulated cockpit environment. This is a good reason you don't see it.
You may get lucky with it, but I would not engineer a solution based on I2C sending data from a switch all the way back to a PC(pi or other).

I think if you have a good look at the demographic of those building flight simulators, the large majority of them are not electronics engineers. More it's aviation enthusiasts (and some software developers) that are looking for easy solutions and not necessarily tinkering around with various electronic components or properly engineering a solutions. There's nothing wrong with that, and if it works for most so be it. Its better for the owner of the sim to understand how it's working and sometimes the 20 USB cables back to the FS PC is better for them.

For me sometimes I have to pull out a scope to troubleshoot:


For us in the minority, we can continue working on more elegant solutions.
Opencockpits is the closest we have to an opensource for cockpit building.

If the opensouce project you're looking for isn't there....someone will have to start it.

[RayS]

Using CAN is not a terrible idea, but it's not really popular for hobbyist stuff. RS485 would be a great solution too, probably better because it's simpler.

This is a great discussion!

The main reason I decided to convert to CANBUS is because a good friend is building a helicopter sim and some of the instruments use CANBUS. Other instruments use a serial protocol with a smattering of instruments that use both. His collection came out of a de-commissioned Sikorsky S-76.

He had asked me to help him figure it all out and in the process, I became interested in CANBUS. With the upcoming FS2020 release on the horizon I saw it as a simple way to convert the sim to an entirely new platform while also retaining backward compatibility to the old sim.

CANBUS Protocol Specification:
https://www.aviationtoday.com/2009/05/01/can-bus-in-aviation/

CANAerospace CANBUS Specifications, including NodeID ranges and priorities:
https://www.stockflightsystems.com/tl_files/downloads/canaerospace/canas_17.pdf

[ame]

This is indeed a great discussion.

Ray, I can see why you went down the CAN bus route. It might work out, but it's a huge leap from Arduino + LEDs.

Kyle, i2c will work to a metre or more. Various web discussions will extend or reduce that range. But, don't forget, that is the range of the bus itself. So, if I have a chip driving an LED then the distance from the i2c master to the i2c slave (the chip) might be limited to a metre or so, but the LED could be another metre away on the end of a bit of wire. Same for a switch. I think these limits are not a hindrance because if I have a master in the the centre pedestal then it's a metre to the pilot's side and a metre to the co-pilot's side.

And there are i2c extender chips.

Anyway, based on my friend's frustrations I have been trying to come up with something simple enough for hobbyists that is also easy to build and not expensive.

Opencockpits is a private company developing proprietary solutions. Unless I'm missing something it's not open source.

Another popular solution is SimVim, but that's closed-source too.

[RayS]

It might work out, but it's a huge leap from Arduino + LEDs.

Way back in my beer-drinking days, a very wise electronics engineer and my mentor who taught me analog/digital theory and applications once told me: "Everything is hard until you know how to do it"

True words.

Initially the CANBUS route was daunting and frustrating. But a few knowledgeable friends on this board pointed me in the right direction.

It's actually quite simple, and not too far a leap from Arduino + LEDs. Even for this old hack. :-) 

[ame]

So what are you using for your CAN nodes? Are you using a controller (like MCP2515) hooked up to another micro, or a micro with CAN built in (like T89C51CC01)?

A long time ago I wrote code for the T89C51CC01 (I think, before it got eaten by Microchip). We intended to use the built-in CAN interface to communicate with other devices on a vehicle. Never got very far because it was too expensive to install more than just one thing in the vehicle. Hooking up wires to talk to another device in each of an 80-vehicle fleet turned out to be pricey (who knew?).

[Joe Lavery]

There's another option called MobiFlight that is similar to SimVim but takes a rather different approach.
It's very easy to use and works with mainly off the shelf components. And once again it's based around the Arduino Mega. It's ideal for those with less knowledge of electronics, has a great (and helpful) forum. In addition the software comes with a huge list of presets for us cockpit builders. Both Airline and GA types.

[RayS]

So what are you using for your CAN nodes? Are you using a controller (like MCP2515) hooked up to another micro, or a micro with CAN built in (like T89C51CC01)?

I'm using the MCP2562 chip, which interfaces directly with any Microcontroller that supports the CANBUS protocol (Arduino, Teensy 3.2 and 3.5 in my case)

The controllers are using the Collins80 CANBUS library: https://github.com/collin80/FlexCAN_Library

[ame]

Progress.

Of sorts.

I have written some code for a microcontroller that takes quadrature signals from a rotary encoder and outputs one of two signals for 'up' or 'down'.

Currently the two output signals are hooked up to LEDs. However, I can turn the rotary encoder one way and see the 'UP' LED flash (one flash per click of the rotary encoder), and turn it the other way and see the 'DOWN' LED flash.

There is a small buffer in the code so that if you turn the encoder quickly the output pulses are still a fixed width. The purpose of this experiment is that I'm hoping this will allow me to connect a rotary encoder to the HT16K33.

The pulse switches were a bust because the contacts close very briefly for each click, plus they are a little more expensive and harder to come by than rotary encoders. The short contact time meant that the HT16K33 would debounce the switch closure out of existence. By making fixed-width pulses (set in software) I can guarantee that the 'switch' remains closed for long enough to be detected reliably.

I did find a couple of logic circuits that would convert the quadrature signal into 'up' and 'down' pulses, but I was concerned that the decoded pulses would be too short, especially if the encoder was turned quickly. One microcontroller is smaller than two logic chips however, and I should be able to handle four encoders on a single micro.

The next step is to hook up some 4066 analogue switches across the HT16K33 key matrix. Then the Arduino can fake a keypress for 'up' or 'down' which will be detected and reported by the HT16K33.

The end goal is to have a single device (HT16K33) capable of driving up to 128 LEDs and up to 39 switches via a simple I2C interface. Up to 8 of these can be hung off a single I2C bus.

I currently have that working with regular switches (toggles, latching buttons, rotary switches), because they move slowly. I want to do rotary encoders through the same interface, but it's tricky.