Ka50 BS3 - DCSBIOS and Max7219 displays

[Jocman]

Hi all.

I'm currently checking my right consolle (Autopilot, ADF, etc etc), and I'm getting some strange behaviour with the displays (not only this, but by now I'm trying to understand and fix this one).

The full consolle is driven (RS485 network) by:

1 Mega:

- PVI800 keyboard + AP mode + DL mode

4 Nanos:

- 1: AP panel

- 2: Magnetic variation, Latitude deviation, SHKVAL scanrate panel, ADF panel

- 3: R828 radio panel, Signal flares panel + consolle backlight (I use 2 strips WS2812b addressable led driven by Cockpit panel lighting Switch (day), Night vision cockpit lighting Switch (night) and Lighting night vision cockpit Brightness Knob / Lighting cockpit panel Brightness Knob for the brightness)

-4: Only to drive the right consolle displays: PVI800 (2 lines), magnetic variation, latitude deviation, R828 channel

 

The issue is concerning the displays (the 4th nano). It drives a double max7219 chips board (PVI800 * 2 lines) + a single max7219 board (for the other displays). The 2 boards are daisy chained, meaning the 3 max7219 are daisy chained.

When powered up, the nano runs a display check (a scroll numbers routine) then waits for the DCS data to show.

This is what happens:

If I connect only the 4th nano to the RS485 network, it runs the check code correctly for all displays and, when DCS starts, it shows correctly all the displays data (PVI800 data, magnetic variation data, latitude deviation data, R828 channel)

But if I connect the other 3 arduinos (nanos and mega) to the RS485 this is what happens: the display check (the scroll numbers routine) runs only for the PVI800 displays, but for the other displays; and when DCS starts, only the PVI800 data are shown, but the others (the other displays stay off)

I don't understand why.

Initially, I used the mega to drive the displays too, then I decided (due this issue) to use a dedicated nano only for the display and for the WS2812 but nothing changed; to be honest, the WS2812 didn't work on this board, and, thinking that the nano could be overloaded by monitoring the displays and the WS2812, i decided to move the WS2812 to the current board (and it works fine), and use the nano only for the displays.

Any idea / suggestion / opinion / solution / etc etc .....?

[Vinc_Vega]

Did you give all your slaves unique DCSBIOS_RS485_SLAVE IDs?

Regards, Vinc

[No1sonuk]

Have you made sure there's no clash in RS485 addresses?

Try it without the Mega connected - IIRC there are/were some issues with Megas as RS485 slave devices.

[Jocman]

Yes, every board has its ID (there are no duplicates).

I'll try (as soon I'll back home) without connecting the Mega and see what happens

[Jocman]

Ok I tried to disconnect the mega, but nothing changed.

If the nano with max7219 is the only one connected, everything works fine.

As I connect even just a second board, the problem comes back.

I tried even some combination (maybe it was only one board problematic) but nothing to do.

I don't think  it could be a power problem, as the nanos/mega are powered by 12V, and the max7219 directly by 5V (i'm using a Nilox 600W PC power supply). Then, if everything could work, my cockpit will use about 30 nanos and a lot of LEDs. Well, I hope the PSU will be powerful enough, but in any case I've a second one (same brand and type).

I tried another way: 2 nanos for the displays.

1 nano drives the dual max7219 board

1 nano drives the single max7219 board

I know, it's really stupid waste 2 nanos when normally a single nano could drive 8 max7219 daisychained, but.....

In any case, don't worry: things didn't change...... when only these 2 nanos are connected all the displays work fine. As I connect the other boards sh*t happens......

[No1sonuk]

Hmm.
I think we're at the point of asking you to post the code for each device.

[Jocman]

Yep, I've been thinking the same.....

The code is quite.....articulated (and very long...), coding is not my best.

Maybe the best solution could be to attach the .ino files directly.

When back home I'll post them; but do you mean only the nano's code driving the displays, or all the boards involved in the problem?

Edited July 4, 2024 by Jocman

[No1sonuk]

.ino files of all of them, please.

It might be something in one, but it could be in more.

[Jocman]

Ok.

Here attached you find the 5 files

22_Right_Consolle_Displays.ino 23_Right_Consolle_03.ino 21_Right_Consolle_02_and_lights.ino 13_Right_Consolle_01.ino 5_Right_Consolle_PVI800.ino

[No1sonuk]

Looking.  Can't see anything major yet.
BUT, I think I found an error in 22_Right_Consolle_Displays.ino
This part starts at line 210 (under "MAGNETIC DECLINATION"):

    if ((newValue>=0) && (newValue<6750)){
      lc1.setDigit(2,0, 0,false);                  // No1sonuk - Is there an error in this line?
      if ((newValue>=2700) && (newValue<4050)){
        lc1.setDigit(2,2, 0,true);
      }
    }

Comment added by me - Should that second line be: 

lc1.setDigit(2,2, 0,false);

I can't think how that could be the issue, but it's an apparent error.

EDIT:  BTW, have you tried connecting those 4 by USB to see if the RS485 link is the problem?

Edited July 4, 2024 by No1sonuk

[Jocman]

About the line 210, yes, you're right, there's an error (thanks for reporting it, I'll fix it).

BTW, I agree it isn't probably causing the issue.

About testing directly via USB, I didn't, the problem is I don't have enough USB cables......I'll try to find them....

[No1sonuk]

I'd try the display one separately on USB, with the others on RS485 first.

Also, with them all on RS485, try renumbering them so the display one has a lower number.

[Jocman]

Ok, i'll try the 2 ways you suggest.

Unfortunately,this weekend i've people at home,but next week i'll do it and let you know.

BTW, i ordered some spare USB cables and a new USB hub, so to connect more devices to USB (like in this occasion) and perform some test.

[No1sonuk]

Another thing to add to the list is to try the Display one on the loaded RS485 bus with all but one of the displays disabled (just comment out the calling lines), then change which one is commented out to see if they'll all work on their own.

Thinking more about this, it might be the RS485 code interfering with the MAX7219 and WS2812 data protocols because the device is getting interrupted in the middle of a timing-critical software-generated protocol.

[Jocman]

I just made the first tries:

1) displays on USB, the other cards on RS485. Initially it seems  to work. All the displays are in sync. But after a couple of changes (switching radio channels, changing mag variation, switching waypoints) all the displays freeze..... All the other board (RS485) keep working, but the displays on USB.

2) All the boards on RS485, display with lowest ID (1). No change compared to the behaviour already reported (the 3rd MAX doesn't show anything)

 

About your last post, I'm trying to figure out (sorry, my poor english).

Quote

to try the Display one on the loaded RS485 bus with all but one of the displays disabled (just comment out the calling lines), then change which one is commented out to see if they'll all work on their own.

do you mean: all the boards on RS485, then comment out the code driving the 3rd MAX (the single MAX board) and see if the other displays (the double MAX board) works correctly, then comment out the double MAX board and see if the single MAX board works correctly. Is that correct?

Quote

it might be the RS485 code interfering with the MAX7219 and WS2812 data protocols

Do you suggest to comment out the WS2812 code and see what happens?

[No1sonuk]

1 hour ago, Jocman said:

About your last post, I'm trying to figure out (sorry, my poor english).

do you mean: all the boards on RS485, then comment out the code driving the 3rd MAX (the single MAX board) and see if the other displays (the double MAX board) works correctly, then comment out the double MAX board and see if the single MAX board works correctly. Is that correct?

Do you suggest to comment out the WS2812 code and see what happens?

Yes. 
I'm wondering if you've got too much on the one device.
Those devices all use "software serial" connections - the code makes all the signals, rather than something like I2C where the code sends/receives data from a hardware interface.  Software serial is FAR more processor-intensive than hardware.

[Jocman]

20 hours ago, No1sonuk said:

Yes. 
I'm wondering if you've got too much on the one device.

That was my fears (as I said in my first post). But I tried even to split the display code on 2 separate nanos (post #5) but things didn't changed. I hoped that splitting the code on 2 nanos won't overload the nano processor. And the light management is on another nano (with some switches), and it works very fine (as said, the only problem are the displays). And if the problem is the lights management, when I tried by disconnecting one a time every boards to check if some of them could be problematic, when I disconnected the WS2812 one, in teory things should be working, but it wasn't...

As I always admitted, I'm almost really ignorant about coding (besides some simple, basic things...)

I'll try to load one a time the 2 separate display codes (I still have them) on one nano and see....Ok I already did it, but both nanos were connected; this time I'll connect to RS485 one a time.

Talking about the I2C protocol (but I'm sure I'm misunderstanding your words), I was thinking about replace the MAX system with some I2C oled display. Could be a solution? my first feeling is "no, it isn't the solution", because I'll keep sending data to displays via software.....

I won't like use oled displays (first 'cause isn't matching the "real" instruments - the MAX neither, but it was a good compromised-, second 'cause that case I'll have to make them fit my panels.....), but if, despite my feelings, this could be the solution.....

[No1sonuk]

About the I2C thing:
Microcontrollers, such as Arduinos, have 2 ways to send/receive serial data:  Hardware and software.
In a hardware systrem, the arduino puts the data into a register or buffer (basically memory locations) and a part of the electronics called a UART sends that data on its own, without needing the main processor to do anything.  Similarly, when receiving data, the UART puts the received data in a buffer and sets a flag so that the main processor can see there's received data to deal with, then your code retrieves the data.  This means the main processor has very little to do with the data transfer, so it can be doing other things when this happens.  The problem with this that the data protocol used is restricted by the type of UART you have. e.g. the Nano's Atmega328 processor's UART can't do USB comms on its own, it needs an external interface - the CH340 is often used on clones.
However, the Pro Micro's 32u4 processor's UART CAN do USB, which is why thay can be used for keyboards/joysticks, etc.
Hardware systems are also limited in which pins they can use on any given device.

In a software system, the processor has total control over the serial communications.
This means the pin locations, timing, everything is controlled by the processor.  This is both good and bad.
The advantage is you have total control over how the data is transferred.
The problem with this is that it's very processor-intensive - While sending or receiving serial data, the processor can't do much else.

So why is this relevant?
If you have to tell the protocol which pin numbers to use, as you do for the MAX7219 and WS2812, it's a software serial setup.
I2C is handled by hardware in Arduinos.
The difference is the type of data.  If it's a numeric, or character display, it'll be quite quick.  If it's a graphics display, it'll be much slower.

RS485 is a variation of a basic RS232-style serial communication.  RS485 uses a different driver interface to the communication wires, but the data transmission method is basically the same as used by the standard UART, so RS485 can be handled by hardware.

Some more random facts:
Unos and Nanos only have one hardware UART - on pins 0 an 1.  If you're using USB, those pins are still used for the communication because they connect the processor to the USB interface chip.  If you're using RS485, those pins are connected to the MAX487, bypassing the USB interface.  This is why you can't use those two I/O pins with USB or DCS-BIOS devices. 

The Mega has 4 hardware UARTs, and that's why it's used as the RS485 master.  UART0 on pins 0 and 1 handle the USB interface, and another UART connects to the RS485 bus.

As for OLEDs not matching the "real" instruments:
The magnetic variation display could be made with realistic-looking scrolling digits, rather than fixed numbers.  BUT, that would take a lot of processing.

Sorry, but that turned out longer than I planned.  I hope it translates well. 

[Jocman]

Well......You've been really good and kind to explain me the I2C matter and the difference between software and hardware managing.

I understand, the processor can handle the software job, but (obviously) has limits.

Nevertheless, someway you're confirming my thoughts. I can understand if things don't work because of the cpu load, if I put on the same board the 3 MAX + the WS2812. Particularly, the WS2812 managements sucks the cpu dry a lot. For my knowledge, the cpu is continuously dealing with every single LED in order to accomplish the software data, and more LEDs more work to do. In this optic, the FastLed library should be an excellent library, optimized for the workload. Besides, my WS2812 setup is not so stressing (or I think / hope so), as it only wait for the switches to change their state then switch green / red / yellow / OFF all the LEDs, with no "lights games". And, in any case, just to avoid an overload, I put the WS2812 management on a separate board: honestly, it seems to me that the switches on the same board with WS2812 have a little delay, but really inappreciable....

The display board, deal only with 3 MAXs: the only thing to do is wait for new data (and we're talking about integers/strings) and manage it; no graphics or something like. And you had a look to my display code: yes, is quite long as I've to check all the variation, but do you think is really so bad to overload the nano?

Honestly, it seems to me my current situation (a board only for the displays) should be the optimal one ("your job is waiting for data and displaying them, nothing else to do").

Just for example, in my overhead setup (the UV26, Datalink and RWR have a separate board each-  and the UV26 manage a MAX7219 too), I put a mega driving all the warning lights + overhead switches + 1 MAX7219 (I build a compass with 3 7-segments to show the course 000-359 and with 16 LEDs switching on/off depending on the course direction N-NNE-NE-E-ENE, etc etc ), and during my test everything works fine (or maybe I've to start doubt....)

[No1sonuk]

Something that could reduce your WS2812 load is to wire strips in parallel if they don't need to be indepently controlled.
e.g. if you're using them as a backlight in several panels, and all need the same settings, you could run, say 6 strings of 12 instead of 1 string of 72.  Then your LED control only has 12 LEDs to deal with, not 72.  It's how neopixel lightsabre blades work.  Though they're usually 2 parallel strings of over 100.

I think it doesn't matter if the strings are all the same length - just set maxLEDs to the longest string length, and those with short strings will ignore the data for the missing ones.

Displays are usually the most processor-intensive.  Particularly with the way DCS works.

It may just be that the Nano isn't quite up to the job. Did you try the displays on a Mega?

Have you considered an ESP32?  They can run DCS-BIOS arduino code on USB connections.  I don't think the RS485 code has been ported yet.

[Jocman]

Just back home from work and tried some other test.....

1) 1 nano driving both MAX boards (double and single, daisychained): scroll test OK, but only the double board works

2) 1 nano driving only the double MAX board: scroll test OK, display work properly

3) 1 nano driving only the single MAX board: scroll test OK, display work properly

I didn't try a mega with the display (actually I've no mega more at this moment....) - but really, use a mega just to drive 3 displays?. (at this point I should think to use a mega for everything - display all the switches-rotary-encoders instead of the other 3 nanos) and leave a nano just for the lights.... Well, I'll get one, join all the nanos code in one and try with the mega

Do you think a Uno could do the job?

About the ESP32, maybe I should have some spare ones from my domotic projects.....need to figure out where.....

[No1sonuk]

The thing is that the Uno (the R3) has the same processor as the Nano (ATmega328), so it might not help unless the speeds are faster.  The Mega has a different processor (ATmega2560).

I needed to use a Mega for a display project recently due to a need for more memory.  It was an F-18 UFC test, and there wasn't quite enough memory in a Nano for the font to use on an OLED.

I've been leaning towards ESP32s for display projects, particluarly the graphic types, as they have a lot of memory and processor overhead.

Edited July 8, 2024 by No1sonuk

[Jocman]

I got a mega from a friend.

But now there's another strange behaviour....

I loaded on the mega the display sketch (the full one, for all 3 MAXs), but now it seems the 3rd MAX is completely dead....It displays the scroll digit test only on the double board, the single board doesn't give any sign of life.....

If I swap the display wires to the nano (with the same sketch), it runs normally the scroll test on all the MAX. I don't do anything strange: just pull off the 3 display wires from the mega and insert in the nano (same pins: 3-4-5). The nano runs correctly the scroll digit test on all MAXs, the mega only on the first 2 MAXs

Ah, and, of course, if with the mega I run DCS, only the double board display works...

I don't know what damn is happening.....

Edited July 9, 2024 by Jocman

[Jocman]

Update.....

I just connected even the +5V from mega to the MAXs boards chain. Everything started working fine. Even with all the other boards connected to RS485, everything was fine, all the displays are working.

I'm wondering: isn't the COM (or GND) the one that must to be shared among all the components to avoid malfunctions?

My RS485 interface for the mega is a separate board (or better, I use the nano interface board with no nano on board, sharing only the RS485 and power side, wired with wires).  the +5V/GND to the MAX chian came from the interface board.

Anyway, as it seems that the problem is related to the poor memory of the nano, I think I've to relay on the mega fore driving the displays. But, as it seems to me, as said, a waste of resources to use a mega just for the displays, could I join all the switches-encoders-led the that mega too? I'm thinking to keep a nano only for the WS2812, but honestly I'll get back 3 nanos.

[No1sonuk]

Generally speaking, yes, it's really only the GND you need to make common.

Maybe you have some electrical noise on the power supplies that linking them smoothes out.  MAYBE the LED displays changing causes current spikes.  Without poking around with an oscilloscope, I can't say.  BUT...  If it works now, back away slowly and leave it alone... 

You could try moving the switches to the Mega first.  Then try moving the encoders.  They tend to be a bit more touchy.