MobiFlight Community Support

Forgive me if there's a different place we should put feature requests and/or suggestions.

In designing my PCB's to use with MobiFlight, I'm struck by the number of outputs required to drive LEDs. Having used WS2812's (sometimes known as "NeoPixels") for several other large electronics projects, it seems that they'd be a perfect fit here. Daisy-chaining addressable LED's would drastically reduce the number of required output pins, much like we already can do with the MAX7219 7-segment displays, and provide a lot of flexibility with respect to bulb color. Similar to adding an LED module, we'd simply need to specify the data pin and the number of WS2812 LEDs (likely as a numeric input, not a dropdown since WS2812's can support very long chains). We could then create output mappings by defining the index of the LED in the chain we want to control, and setting the RGB values for that LED as 0-255 for each R, G, B channel.

Thoughts? I'm happy to provide more context if it helps, or assist with adding this capability

Hi N131MG,

Welcome to Mobiflight!

Thanks for pointing out / wanting to make Mobiflight more effective with WS2812 by designing simulator (LED) displays similar to MAX7219.

When looking at the data sheet, it is noticeable that the WS2812 requires an operating voltage (Vcc and Vdd) of 6 - 7V, +/- 0.5V. The limits are therefore in the range of 5.5 to 7.5V.

The power supply of a MEGA is in the range of 4.5 to 5.5V (see datasheet ATMEL for 8 bit microcontroller V-2560, chapter 35.4, page 410).

According to the specification of the USB interface, the voltage is allowed in the range of 4.75 to 5.25V (USB 2.0) and 4.45 and 5.25V (USB 3.0 / 3.1). See Wikipedia.

Since Mobiflight is operated with the specifications of the USB interfaces, this is the upper limit of the operating voltage of the MEGA and the lower range of the operating voltage for the WS2812.

Based on the fact that the USB interfaces are invariably operated around the 5V, this voltage is already below the allowable operating voltage for the WS2812.

The operation is therefore very borderline and is outside the range specified by the manufacturer and guarantees proper operation.

Another point is the number of RGB LEDs according to the data sheet:
"When the refreshrate is 30fps, low speed model cascade numbers are not less than 512 points, high speed mode not less than 1024 points."

In other words, at least 512 RGB LEDs must be installed. That seems a bit much to me. So many LEDs are not needed in a cockpit.

Have you already gained experience with the WS2812 in connection with the MEGA and can you provide us with the necessary documents to test it?

In what form did you do something with the WS2812?

Stephan,

I've frequently used these (https://www.sparkfun.com/products/12986 and https://www.ebay.com/itm/100pcs-WS2812B-5050-RGB-LED-black-PCB-Board-1-LED-Module-Pixel-Light-5v/321903931710?epid=1548597175&hash=item4af2f8313e:g:bl4AAOSwo0JWLsF-&frcectupt=true) in a number of Arduino/Particle Photon powered projects. Operating voltage is 4.5-6V. I have a Particle Photon (Arduino based) word clock that uses 121 of these and haven't had any issues with power provided a decent power supply is used. It certainly wouldn't work without a powered USB hub. You also have options to wire them off of an external power supply so they're not actually powered by the USB bus. If you had a significant number of these, you could provide external 5v/2000mA power to them and simply include a logic converter in your circuit to handle any voltage differences/fluctuations between the Arduino Mega and the external power supply.

Sparkfun has a pretty comprehensive hookup guide that covers how they're wired and controlled (https://learn.sparkfun.com/tutorials/ws2812-breakout-hookup-guide?_ga=2.232320927.1201604185.1554215734-88629730.1553110042#addressable-through-hole-led) if that helps as a primer. I've always used the Adafruit Neopixel library for Arduino when controlling them. When using that library, you're simply calling a setPixelColor command, and specifying the index of the LED, and the RGB values. Admittadly, I haven't dug into the MobiFlight code yet, so I'm not sure how the serial interface is wired up. I suspect we'll need to look at the actual Neopixel library and replicate the communication methods in C#.

My word clock for reference: https://www.instagram.com/p/BkWFiQ-FVI1/

Edited to make links clickable.

Conceptually, wiring would look something like this if using an external 5V power supply to drive the LED power. Only a single data pin required for any number of LEDs. Providing the input power is 5V, no logic converter would be required, but if the voltage differed between the Arduino and external power source, you'd want a logic converter between the data pin and the resistor.

Hi Michael,

electrically, the circuit is easy to understand. I have a problem with the color design, which also does not solve your clock for me: can all LEDs in a chain always have the same color or can every single LED with an individual color shine? Can the light intensity be set individually or via software via the resistance of each LED?

Interestingly, I could imagine that for Mobiflight only if you can answer both previous questions with YES.

In principle, Mobiflight works in such a way that a config is pushed over a switch, behind which lies a simulator input based on an EventID. If this affects an LED, this is indicated by a simulator output, which in turn is based on an offset. It is usually usually required for a switch an individual LED for display. Switch off, LED off, switch on, LED on. Is that possible with the WS2812 when there are 20, 30 or 50 LEDs in a chain? Then almost every LED in a chain would have to be offset.

On the other hand, I can imagine that you can use Mobiflight to control the backlight, even if the brightness can be dimmed.

I can not say if and how this is possible in Mobiflight - I am not a developer.
However, it is conceivable for me that the complete control must be implemented from the corresponding library in Mobiflight.

The idea itself has something in it. I would be interested to know what other users think about it. This is certainly an aspect, how can a chain be extended, a LED can be built in between, just the imponderables that a user does not consider from the outset.

An advantage would certainly be in not having to buy the right LED color, but only to use the RGB value. Also, where multi-lane LEDs are used, one can use one that is assigned a different RGB value.
I'm looking forward to the response, but also to the answers to my questions.

Let me try and answer your questions...

LEDs in the chain are individually controlled, both in color, brightness, and their state. Say you had 5 LEDs connected per the following model (taking something like a 777 as an example):

LED 1 - Master Warning
LED 2 - Master Caution
LED 3 - AP Master
LED 4 - LNAV Button
LED 5 - VNAV Button

In the case of master warning, you'd issue a command to set the LED with index 1 to 255,0,0 (RGB for Red)
In the case of a master caution sim event, you'd issue a command to set the LED with index 2 to 255,255,0 (RGB value of Yellow)
On press/activation of LNAV, you'd issue a command to set the LED with index 4 to 0,255,0 (RGB for Green)

Likewise, when any of those conditions cleared, you'd also have to issue a 0,0,0 command to the appropriate LED to turn it off again.

Those commands affect only the LED with the index specified, and has no effect on the other LEDs in the chain or any other states of those other LEDs. This same model can be used for setting brightness/intensity, as the 0-255 range per color can be used not only for color mixing, but also for dimming, ie 255,0,0 is full intensity red, while 127,0,0 is 50% intensity red. This means that you could conceptually measure the level of say glare shield backlight, and appropriately set any number of LEDs in the chain to match intensity for brightness of the backlight.

In principle, I don't see complications with dealing with the offset of each LED simply because we already do that to a degree with the MAX7219's (setting which character(s) of the display we want to use). Creating a rule that says "on sim event set LED n to XXX,YYY,ZZZ" isn't really all that different (though certainly requires us builders to take pretty good notes of where LEDs are). In the event that we'd want to set say backlight, we'd likely need to key multiple LEDs for a given rule... so backlight intensity could be pushed to LED 1-6,10,12,15-20 as an example.

So as I understand your question, both answers are Yes.

As for the actual MobiFlight code, I'm not sure if commands are actually being issued from the Arduino (allowing any existing Arduino code I have to be useful), or if the Arduino is merely acting as a serial interface and all of the commands are being sent from the connector app. That said, there's already some sort of digital logic and communications bus implemented to support the MAX7219's, so I suspect it'd just be a matter of replicating the necessary methods to issue the digital commands, and create the appropriate screens for setting up the device. I'm hoping to have a look into the code this weekend to better understand it.

Hi Michael,

that sounds very interesting! Do you have a source or a link where I can download the libraries and or a sketch to simulate the described steps?

Sparkfun's hookup guide is pretty comprehensive and covers power and the Arduino sketch (https://learn.sparkfun.com/tutorials/ws2812-breakout-hookup-guide?_ga=2.232320927.1201604185.1554215734-88629730.1553110042#introduction). There's also the Adafruit NeoPixel Uberguide (https://learn.adafruit.com/adafruit-neopixel-uberguide/the-magic-of-neopixels), which expands a bit on topics like power distribution, but also covers things like RGBW matrix which are likely irrelevant for our uses.

Perfect, thank you!

Sure thing, let me know if you have questions!

Hi Michael,

not in the moment.

We will put the WS2812 on the agenda for our next meeting with Sebastian. The features must be considered by a developer and this must be discussed for and against. I can not say anything about the result at the moment.

Personally, I think the WS2812 quite interesting, but would have to rebuild my previous hardware. So it can only be an additional feature for future construction projects.
The result of the meeting, we will certainly publish here in the forum. If there are questions we can not answer, we will certainly approach you.

I spent some time today working on an attempt to implement the functionality. I'm making good progress, but it'll take a little more time to fully implement and vet. Certainly curious as to what Sebastian's feedback is, and if I get it working I can certainly provide my code.

I believe I have the Arduino methods correctly implemented, but at the moment am just working through the Connector side of things. I'll update if I make any breakthroughs!

Hi Michael.

At first "thanks" for your work. I like also to comment your suggestion.

Usage:
Basicly the tool is "usefull". Handling a high number of LED with only one PIN is a good idea. If the system is simmular easy like the current technic then i absolutly agree.

The Color Feature i personlay think is not needed. I only now a verry small number of LED in a cockpit that have multiple colors ( for example the AFDS in a B737 with Red/Yellow status) ..... But 99% of LED are simple UNI Color..... Whatever we need Green, Red, Blue, Yellow and White LED.... All of these not need to have different colors..... So the Anounciator that need a red LED is always red and not need to be green for example.... So we can simply use a red LED directly and not need a RGB LED here.... Cause its static!

For Dimming i see a Usage if a Anounciator can have a FULL and DIMMED Status. Here we currently need 2 LED.... With your System this can be done with ONE Led.
But for Backlighting we have technical problems. Here i think the Logic of Mobiflight not is comaptible and we need a "bigger" change in Logic and Grafic UI .
Here is the simple question..... Is this usefull ? Backlights not need to be implement in the Sim Logic. So the Sim not must be "know" if my backlight is on.... And also my backlight must not show the status of the "virtual" Backlight in the Sim.
Summary i think here a EXTERNAL Solution is more easy and more usefull. ( We can talk private if you like to discuss that)

*****
Technical Side:

In case we need a Mobiflight that work already for older versions this system must be additional to the normal LED System and should NOT remove it.
So i think the WS2812 must be a new "Device Typ"
I think we should have in Mobiflightboards/Devicesettings a new "Typ" like "WS2812 LED Chain" . Here we define the PIN that is in use AND the number of LED in the Chain.
In Configs we use instead of "LED OUTPUT" then optional the Device Typ "WS2812 LED Chain" .
Here we choose in a Dropdown the "LED Chain" we like to use (Specialy if more then 1 chain exist) AND we say here WHAT specific LED (Number in Chain) we like to controll.
Then we Can Choose 3 Values (RGB ) and define the color and Brightness for TWO Situations ( TRUE and FALSE)
So if Indicator is True (For example a BoolOffset is 1) we choose for example 255/255/255 (full white) and for FALSE ( Bool is Zero) we choose 0/0/0 (complete dark)

THIIS should be possible and relative easy to implement !

(Again i will not comment the "Dimming in case of a Offset" ....I think this is a to much deep change... But we can also discuss if you like in a personal way like email... Maby you got a good idea)

Possible problems.

A Fact that is a bit "confusing" me is the data rate we need here. Every LED need a 3 Byte Value for Controll. It is chained.... so for 50 LED we need 150Byte that must be send.
If last LED must be chanched then all 49 in front also need to get a value.
I think it must be tested ( with Mobiflight loop logic) how long a LED Strip can be before we "feel" signeficant delays. Also it must be tested if a Max7219 or LED Segment on Same board is affected if MEGA CPU need to work 100 times more like at the moment to handle your LED System.
(I finaly not understabnd if this LED Chain must send values ALL THE TIME or only if a LED in the Chain change Status (like a Max7219) )

A other negative argument is that the Chipset is not available for lots of LED.. Stephan still said his LED normaly have a Brightness of 8000 and more. The LED i found on a google search with that WS2812 System are pretty much lower. Is Brightness enough for the usage of a Homecockpit ?

****************
Summary:
With my personal Rating System this request got a 7-8 ( out of 10) . So this is a clear recommendation. I can not garantee if Sebastian loves it and if this gets into Mobiflight finaly. But i will vote for it ( Whatever NOT for a Backlight DIMMED logic at the moment ) .

Last Note: If you can scripting PLEASE get in contact to Sebastian. Every Developer who like to get into the team is welcome. But i recommend to talk to him ! It make no sense if you invest lots of time if HE like it another way. So working together is the Key !

THANK YOU

All good feedback, I think we're on the same page. In my attempt at implementing it, I did create a new device type (which I called "RGB LED Strip"). You can have multiple LED Strips defined as devices (by setting the output pin and number of LEDs in the strip when adding the Device Type). That part I believe I have working in my own local environment.

I've started implementing that into the Arduino library by using the Adafruit NeoPixel library. In the Arduino firmware I've added a method called "OnSetRGBLedPixelColor", which takes the LED Strip device, the number of the LED in the strip we want to control, and a value for R, G, and B (0-255). I like your idea of a full vs dimmed state, but also think a brightness slider may make more sense (and provide greater control). I hadn't intended to take it quite this far, but instead of having 0-255 inputs for R, G, and B we could also potentially show some sort of a color picker so users don't have to calculate the R, G and B values on their own. Personally, I'm fine with just having R, G and B, with no slider and no dim vs. full since I know I can use 127,0,0 for half intensity red or 255,0,0 for full intensity red--but I can absolutely support the idea of making it easier for other people.

The way the NeoPixel library works (and this will answer one of your other questions), is that you call a "show" method anytime you make a change to a state of one of the LEDs in the strip. That state is then persisted until the next time show() is called, so they do not require constant data, only when a state is changed.

Code:

void OnSetRGBLedPixelColor()
{
  int ledStrip = cmdMessenger.readIntArg();
  int led = cmdMessenger.readIntArg();
  int red = cmdMessenger.readIntArg();
  int green = cmdMessenger.readIntArg();
  int blue = cmdMessenger.readIntArg();
  if (ledStrip >= rgbLEDStripsRegistered) return;
  rgbLEDStrips[ledStrip].setPixelColor(led, red, green, blue);
  rgbLEDStrips[ledStrip].show();
  lastCommand = millis();
}

The above is largely mirrored by the existing OnSetModule() method in the MobiFlight firmware, and you can see we're calling the NeoPixel setPixelColor method, followed by the show method to commit the change to the strip.

To add a little more context to the user story here. I'm actually attempting to build somewhat of a universal MCP and FMC (purely for personal use). That makes my scenario is a little different, since I'm not building for a specific aircraft type, and thus actually desire to reuse LEDs across multiple types where colors may not be consistent.

All this said, I'm more of a maker/tinkerer, and less of a professional developer, so while I have found my way thought the MobiFlight codebase, I really slowed down trying to implement all of the forms and panels for the new device. It may very well be that Sebastian can do some of this way quicker than me, but I'm happy (and willing) to support however I can. Is there a private message feature here? What's the best way to converse?

Hi Again.

I´m sorry but my knowledge of code is a bit poor. I understand the syntax of the script baiscly but i can not see what "internal" in the library happen.

For example a 10 LED Strip... If you like to change the 7th LED ( beginnning by 0 this is number 6 pretty sure) then you send this single ".show" command for LED#6.
Question is.... What happend now. Does the System (Library) send ONE "pack" that is transmitted over LED 0-5 und reach LED 6 to do the change.... OR Is the Programm Transmitt basicly 7 Blocks (Like a Max7219) to "push" the real information through the first 6 LED Registers ? In that case are the first 6 Blocks "empty" so the LED know they are not "involved" and they can hold there current status..... OR Inlcude the 6 Blocks the current informations for LED 0-5 also ? So a change of LED#6 technical also write LED1-5 again.
Finaly maby there can be also a "Over All" logic.... That a change of any LED will simply send a block for the full Stripe ( So change of first LED #0 will also result in a sending of 30 Bytes (whatever LED 1-9 basicly not need informations here)

I hope you understand me.... I just like to understand the internal process to estimate the "recource needness" of this system.

**********
About your wonderfull suggestions.
YES. A Dropdown or clickspot for a couple of preselected Status is more profitable ! .... Like Red, Blue, Yellow, Green, Magenta, White .... thats better like input 3 Values.
Maby we can also leave of the "FALSE" Status... So LED show selected Status if Value is >0 and is simply set to OFF (00-00-00) if Value of Config is Zero ( Like a standard LED at the moment)

Same About Dimming. i 100% agree that a slider is more usefull .... Technical no Problem.... (Not realy stepless .... internal a 10 step bright will be more easy to programm maby)
But again. In That Case we define a fixed Brightness for the ON Status of THIS Config. Thats wonderfull and i think thats needed and possible.

As i said i not looking forward for a Dimmed Backlight i mean something different.....
I thought you like to make a permanent "observation" to a offset, that set Brightness "stepless" in case of a Offset Value.
For example we Readout Offset XY that show "Simulator Dimm Status of Backlight" With e.g. Value 0 = Off Value 100 is full bright.
And now Mobiflight Code should say.... Controll Dimm of A LED or a full Stripe in case of that offset.... So Offset Valie 1 for example send 2 2 2 .... Offset 10 send 20 20 20 .... Offset 50 send 128 128 128 .... and so on.

In easy words.... I support a system where we can define ONE State for a single LED (Or a Couple maby) with Brightness and Color of our Choice in ONE Config.
But i not agree in a system that set brightness variable all the time in case of a Offset. ( Maby i will change my Opinion if i see a working example and its easy and logical)

**********
To Contact Seb.

This forum have no PM function !

I not know if i´m allowed to share personal contact Data (Apollogy for that) ... So i can give you just the official mail adress ..... info@mobiflight.de
He is located in the US (Chicago Illinois) . I contact him normaly via WhatsApp, Mail or finaly via "Teamviewer" to have Video/Voice and Shared Desktop .
Please contact him primary via Email.... Pretty sure he give you then adittional personal contact informations. (Reply Time normaly 12-24 hrs.)

MY support adress is pizman@freenet.de . We can also create a more comfortable base e.g. via WhatsApp if you like !