Character Display possible issue.

[Keith Baxter]

The caps made all the difference in our case, and for others as well. It's recommendable to have at least 10uF on each display.

Hi,

Might be beneficial to put a note in the API to that effect.

Keith

[jph]

Just to be controversial...I have been away from flight simming and developing AM hardware instruments for almost a year, having packed everything away for moving house in March last year.

The first instrument(s) I developed when I started making AM hardware, in 2020 was a Nav/Com unit. I had four daisy-chained pairs of MAX7219 displays running off a single Arduino Mega back then. This was using v3. Having set this up now with v4 the second displays don't function. I have tried a different Arduino and different displays and no joy.

The only thing that has changed in this setup is the software so I challenge the claim by AM that it is not a software issue.

Interesting results and nice to see some testing and observations from various parties Tom.
Do you, perchance, have an image, or can get one, of any of the boards in use - the rear of the PCB preferably ?. I also have found no issues with Arduino and daisy chaining although I do not have a large enough supply in stock at the moment to do extensive testing but that is soon to be remedied.
I am awaiting 10 units that I ordered specifically for testing for this issue - that do not have the cap installed - as 99% of ones you can now buy do not, and will be testing them and looking at the signal waveform progression through the displays with the scope and a logic analyser. I will publish the results with various configurations and LEDControl Lib for the arduino as a standard reference. These devices should run up to 10Mhz CLK although it highly unlikely for that to be in use. Running at 1Kz clock - if I understand @Ralph correctly with the 1ms timing ? can hide a multitude of sins in both hardware and software but at least has helped in the testing Ralph has done. There ideally SHOULD certainly be smoothing and adding capacitance on the power line main input - especially with shit supplies - is standard but on practically all of these boards the location of the 10uF cap is too far away from the IC. It used to be fitted but was removed around 3 years ago when the display modules became soldered to the board as opposed to being plugged into headers as the cap was on the header side of the board (which was horrendous for the contacts and missing or corrupt characters due to changes in temperature and the header connection). The results will be objective and documented and at various clock rates. I 'think' that the AM implementation is bit banged but should still be repeatable. I have many chained 8x8 matrix units using 7219s without the 10uF cap that work absolutely perfectly with Arduino and fast hardware SPI. it is interesting to note that the 'netiverse' / 'emptynet' is not full of reports of issues - however - it is impossible to know the amount of chaining that is used compared to the - probably - 10s of millions of units sold - without the on board electrolytic cap.
Any issue with the display is almost 100% certain to be CLK related as in deterioration of signal through board chaining progression or timing of / from the source. It is HIGHLY unlikely to be data throughput as the Din / Dout is fully buffered internally on each IC. These are the most basic cheap board design but... Any capacitance added is for smoothing power supply (IC) surges due to the MUX power fluctuations. (as documented in data info from the manufacturer). When chaining, it is quite possible that the smoothing could be accomplished - if needed, with a single 1000uF cap for the chain, or other methods that may be far far simpler such as a loop back of the CLK line from the final display. Whatever the results, I will publish them. Like you, I have not had any issues in the past, but I always tend to add suitable filtering to the PSU inputs on any hardware, and also - usually- a small amount of decoupling - even if it is a single electrolytic cap for the chain - usually working on the basis of 1000uF per Amp. I have always done this.
This is a very interesting topic and I look forward to receiving these units and actually testing them and looking at the data progression and integrity with and from various sources and with various hardware configurations.
If the solution is adding the cap to EACH board and is repeatable in Arduino standard libs then I will hold my hand up. However that does not appear to be the case for others. I think there is, perhaps, a combination of various aspects occurring and no silver bullet. Again, I would expect the flight sim hardware forums to be inundated with issues - but they are not. I look forward to getting it all on the bench.
ALL results, or lack of, or changes in what does and does not work are informative.
Joe

[tomlithgow]

I'm not sure I see why one display works, and daisy chaining doesn't....unless you add capacitors to the setup. That said, I've ordered some capacitors.

[jph]

I'm not sure I see why one display works, and daisy chaining doesn't....unless you add capacitors to the setup. That said, I've ordered some capacitors.

Hi Tom, it would most likely be due to timing of the input signal (as in glitches) as the display address data for the display to be used to be processed is contained in the DataStream.
Adding smoothing caps will certainly address glitches due to surges if that is the issue - but, why then did it work before ? unless AM used a lower clock rate for the data in earlier versions which would mask issues in hardware.

A possibly very simple solution at virtually no cost or real effort may be -
For now, if you can get to things easily. Try simply connecting the 'CLK' pin from the last display in the chain directly to the CLK pin on the very first display with a single wire. (leave everything else in place - just loop the final CLK pin back to the first CLK pin). Also, if not improved, try the same with the GND. ie : take the GND from the final display with an external cable / wire and link this back to the first display GND. Try the CLK first. That may cure your issues and also tell us a lot of useful info. You cannot hurt anything at all by doing this. Do not do this for any other pin.
This may well solve your issues. I also note the 7219 data in AM has been updated as of yesterday to - nr_displays Number Number of chained displays. You can have up to 4 MAX7219 devices in one daisy chain.
The simple loop of the last CLK to the first CLK may well solve the issue as it should reduce any CLK signal degradation in a very simple way.
Adding a link from last GND to first GND can also assist for reasons I can go into if you like but it is far simpler to try.
Joe.

[Corjan]

Hi,


The software has changed quite a bit between V3 and V4. Nothing that should effect signal integrity though.

In V3, data from AM was pushed to the MAX chip directly. With V4, characters are stored in RAM on the Arduino.
That allows to combine mulitple character changes in one swoop, where all (up to 4) displays can be updated in one go.


This might have some side effects. But the actual signal generation never changed,

Corjan

[jph]

Hi,


The software has changed quite a bit between V3 and V4. Nothing that should effect signal integrity though.

In V3, data from AM was pushed to the MAX chip directly. With V4, characters are stored in RAM on the Arduino.
That allows to combine mulitple character changes in one swoop, where all (up to 4) displays can be updated in one go.


This might have some side effects. But the actual signal generation never changed,

Corjan

Hi @Corjan Many thanks for the info.
I will take all this on board during testing as I find this absolutely fascinating (geek mode on ) - and it gives me chance to dig out the scope and logic analyser
If the data is pushed directly in the previous version, would I be correct in saying that the clock rate was fixed - but, if the data is then buffered in ram prior to stream then the CLK may / could be higher due to the source coming from ram ? - o,r is the CLK rate the same either way ? -
Also, when you made the change did you alter the decode mode on the 7219 ?. - it would seem unlikely as you allowed for custom characters so probably used the decode mode off - or did this change also from earlier versions as you added the custom characters where you use decode mode on with the built in characters ?
Don't get me wrong, I am sure (well, I KNOW!) the hardware is not a good design at all ! - most definitely. I am simply trying to look at all options and EASY way to fix things rather than have - perhaps - novice users solder electrolytic polarity sensitive caps onto small footprint areas on each display that I am aware that some users, even AFTER that - when daisy chaining - have still found issues - albeit with >4.
Also, out of interest, why limit the chain to 4 ? - is that purely because 4 was what you had to test ? or is it simply a (usually) unnecessary load due to most folks using 5 or less per arduino ?
Again - MOST DEFINTELY - I am not saying it is a software issue per se, I still think it is a timing issue most probably caused by hardware that is now being highlighted.
It would also be a very interesting test to use the same modified hardware you have with, say, six or 8 displays.
Thanks again. It is very much appreciated to see an insight.
Joe

[Keith Baxter]

Hi,

There are peeps driving 5 MAX7219 with the cap added. However they mod their boards to drive ONE 3 digit GREEN led.
This is mainly for the electrical panel on the 737 overhead,

So unless @Corjan changed something since beta (29) then 5 displays seem to work OK.
Suppose SI are playing safe when they say only 4 can be daisy chained. Understandable as the most popular instrument is the NAV/COM radio.

Keith

[jph]

Hi,

There are peeps driving 5 MAX7219 with the cap added. However they mod their boards to drive ONE 3 digit GREEN led.
This is mainly for the electrical panel on the 737 overhead,

So unless @Corjan changed something since beta (29) then 5 displays seem to work OK.
Suppose SI are playing safe when they say only 4 can be daisy chained. Understandable as the most popular instrument is the NAV/COM radio.

Keith

Hi Keith, I am absolutely fine with that. I just want to know WHY and what the variables are. Testing a suitably long chain with these 'cheap' - sold in their millions - boards and the right test equipment should give us some useful answers.
Joe

[Corjan]

Hi,


Since the Arduino now has to buffer all characters internally, I decided to limit it to 4. There is not much RAM to play with on some microcontrollers, every byte count.
Also, the protocol becomes slower and slower with the number of MAX chips you use. If you want to reach the last chip, you have to push dummy data though all in the chain.

You can create mulitple chains (there is no restriction there), so that would be the way to drive a many MAX chips.


Corjan

[Keith Baxter]

Hi,


Since the Arduino now has to buffer all characters internally, I decided to limit it to 4. There is not much RAM to play with on some microcontrollers, every byte count.
Also, the protocol becomes slower and slower with the number of MAX chips you use. If you want to reach the last chip, you have to push dummy data though all in the chain.

You can create mulitple chains (there is no restriction there), so that would be the way to drive a many MAX chips.


Corjan

Hi,

Cool understood. Thank you for that info Corjan.

Is that why the character library has not been extended?

Keith