Jittery output for Altimeter data

Guys, was actually flying around today, testing all the bits and bobs out, generally very happy with everything, especially all the gauges working in concert!

I've got a load of OLED's working nicely too, but the two that are on the altimeter, the main one that scrolls the first three digits and also the one that has the barometric preset four digit number are behaving less that perfectly. It's splitting hairs with the scrolling altimeter, but the left hand number blanks and jumps, like its receiving a jittery signal. It is plugged into a USB port on the PC at the moment, after moving it from a hub to see if it improved the signal, but no difference.

As for the barometric height setting, that is all over the place - it starts off displaying perfectly, then after a while seems to become a random number generator. As above, it is plugged directly into a USB port on the PC , not a hub. The code for it is below, as you can see it is not a particularly complicated one. ** EDIT - forgot to mention, it is a number that does not change, it stays constant as long as you don't make any adjustment, making it more weird that it daces about

#define DCSBIOS_DEFAULT_SERIAL

#include <DcsBios.h>
#include <Arduino.h>
#include <U8g2lib.h>
#include <Wire.h>

U8G2_SSD1306_64X32_1F_F_HW_I2C u8g2(U8G2_R0, /* reset=*/ U8X8_PIN_NONE);


char* displayString = "----";

// onDcsBiosWrite does not exist anymore, use Int16Buffers instead
DcsBios::Int16Buffer altPressure0Buffer(0x1086);
DcsBios::Int16Buffer altPressure1Buffer(0x1088);
DcsBios::Int16Buffer altPressure2Buffer(0x108a);
DcsBios::Int16Buffer altPressure3Buffer(0x108c);

void setup() {
 
 u8g2.begin();

DcsBios::setup();
}

void loop() {
 DcsBios::loop();
 
 if (altPressure0Buffer.hasUpdatedData()) { displayString[3] = mapeo(altPressure0Buffer.getData()); }
 if (altPressure1Buffer.hasUpdatedData()) { displayString[2] = mapeo(altPressure1Buffer.getData()); }
 if (altPressure2Buffer.hasUpdatedData()) { displayString[1] = mapeo(altPressure2Buffer.getData()); }
 if (altPressure3Buffer.hasUpdatedData()) { displayString[0] = mapeo(altPressure3Buffer.getData()); }

 u8g2.clearBuffer();
 u8g2.setFont(u8g2_font_fub20_tn );
 //u8g2.setTextSize(1);
 u8g2.setCursor(0, 24);
 u8g2.print(displayString);
 u8g2.sendBuffer();

 delay (100);

}

char mapeo(unsigned int valor){

 if (valor < 6553) { return '0'; }
 if (valor < 13107) { return '1'; }
 if (valor < 19660) { return '2'; }
 if (valor < 26214) { return '3'; }
 if (valor < 32767) { return '4'; }
 if (valor < 39321) { return '5'; }
 if (valor < 45874) { return '6'; }
 if (valor < 52428) { return '7'; }
 if (valor < 58981) { return '8'; }
 return '9' ;

}

It is not critical to get these sorted, but they are details that do make a difference. If anyone is able to make some suggestions as to how to improve this, I would be very grateful!

Cheers

Les

Some options are:

1) Read data at a slower rate.

2) Discard data that's "too different" from the previous value.

3) Average the data - Add the old value and the newly-read value, then divide by two.

4) Discard data that changes too long after the adjustment control is used.

Another thing that might work is to take control of the number.

I'm not sure if it's possible, but this would involve reading the number once from DCS when you start, then stop reading the number.

Then you regularly send the number you have to tell the game's altimeter what to display. When you adjust the number, change your display and again, send the number.

Thanks for the response

I did try a slower sampling rate. For the scrolling number, too slow and it fails to scroll, but with the barometric one, I even tried a half second interval - totally slow. Funnily enough on the ground it is stable, but in the air, not even half second sampling helps, no idea why

As for the rest of the suggestions, you may have to help this old brain understand how to approach those

The output from DCS BIOS is an integer between 0 and 65335 in each case, and the 'if' mapping is a way to convert it, but I suppose not the only way

Cheers

Les

OK.

Not sure which aircraft you're looking at, but a few I checked in the control reference don't appear to allow you to send the barametric number, only read it

2) Discard data that's "too different" from the previous value.

For this, you subtract the lower number from the higher, and if the difference is over a figure you decide, you ignore the new number as a "blip".

Partial code snippet:

pressureDifference = newPressure - oldPressure; // Get the difference
pressureDifference = abs(pressureDifference);   // Make sure the number is positive

if (pressureDifference < pressureDifferenceLimit){
     // Enter your gauge change code here
}
else {  // Insert ignore it code here (if any) 
}

This just compares two values. You don't need to mess about with mapping the values before comparing unless you want to. Just set the pressureDifferenceLimit variable accordingly.

One step further would be to check a few in a row, so only when you get, say 3 numbers within your limit do you consider them valid.

3) Average the data - Add the old value and the newly-read value, then divide by two.

Kind of self-explanatory. If you average the data, the number difference you'll get is half what it could be.

4) Discard data that changes too long after the adjustment control is used.

Set a variable that records the millis() time when you use the adjustment control. When the onchange routine runs for the pressure, check if it's within n millis of using the adjuster. Ignore changes beyond that time.

Of all of these, #2 is probably the best option, as it runs all the time and has least probability of throwing away valid data. #4 is probably the worst option in that regard.

#3 will still give you jittery numbers, but it won't vary as much.

Apologies about the aircraft type, it's the A10-C.

This is the exemplar code from DCS BIOS reference

void onAltPressure0Change(unsigned int newValue) {
   /* your code here */
}
DcsBios::IntegerBuffer altPressure0Buffer(0x1086, 0xffff, 0, onAltPressure0Change);

I have to confess it's a little confusing that the output is a 0 to 65335 integer for these four numbers, as it is a digital display not a gauge, and other similar outputs like the TISL code wheel numbers are actually output as the numbers (0 to 9 in 0.5 increment steps or 0 to 19 in 1 increment steps). If the output was like that it would be a lot easier to handle, and less prone to jitter.

Nonetheless we have what we have, and I am very grateful for it.

I suppose to I have to ask why does the value get corrupted, as maybe understanding that will help. Also, is there a better way to convert the 0 to 65335 output to a single digit

Cheers

Les

I am starting to see this when the aircraft is static on the runway now - I will try and make a short video.

However as the values are static on the ground, it make me wonder what is going on that the output is so unstable.

Cheers

Les

Ok guys, I made a video - and of course the Baro Altimeter behaves itself perfectly in this one, however the altimeter readout does misbehave - check out about 30 seconds in, remember the aircraft is static at the end of the runway so neither value should change at all

I've tried increasing and decreasing the delay time for the data refresh, and it doesn't seem to make any difference

Cheers

Les

Looks like the needle reading isn't working right either (or at all).

I'd suggest that if you have one, rig a character LCD to read the data separately and display it in stripped-down form separately, and check that when the gauge numbers go loopy, the LCD display numbers do too. If they do, it's likely the source data. If they don't, it's either your code or the gauge hardware.

BTW, I guess the 0-65535 number would be very relevant when you consider in reality they would be wheels with numbers 0 to 9 on them, and the 0-65535 would be 0-360 degrees rotation of those wheels.

Also, did you try using the Arduino "MAP" function?

e.g.

displayString[0] = map(altPressure0BufferValue, 0, 65536, 0, 10); // 65536 would = 10, and should never occur

And why not use the onChange function?

EDIT:

I tested that mapping function using a 32-bit variable so it could go to 65536, and I got the following numbers:

Input Result

6553 = 0

6554 = 1

13107 = 1

13108 = 2

19660 = 2

19661 = 3

26214 = 3

26215 = 4

32767 = 4

32678 = 5

39321 = 5

39322 = 6

45875 = 6

45876 = 7

52428 = 7

52429 = 8

58982 = 8

58983 = 9

65535 = 9

65536 = 10

However, when I change the input variable to 16-bit, 65536 doesn't happen, it becomes 0, and the mapped number changes to 0.

All the other changes occur at the same points.

Looks like the needle reading isn't working right either (or at all).

 

I'd suggest that if you have one, rig a character LCD to read the data separately and display it in stripped-down form separately, and check that when the gauge numbers go loopy, the LCD display numbers do too. If they do, it's likely the source data. If they don't, it's either your code or the gauge hardware.

The altimeter isn't hooked up yet, as I am waiting for an optocoupler for the zero function - in the current situation I think it will be a while, but plenty of other jobs to do so it won't be a problem.

I'll rig up an LCD today and try it, that's what I did to figure out the TISL output so I'll just re-use that hardware.

Also curious about the map function, I have nothing to lose by giving it a go if I can work out how to use it

Cheers

Les

I tried the LCD output check - the output is rock solid, so the issue must be with the sketch glitching. Not sure where the corruption is creeping in, both the altXXXftCntBuffer and altPressure2Buffer outputs are stable and smooth, but I still get the values jumping around.

So something must be reading the data wrongly or erratically, but on the face of it it is a very simple sketch so I am reverting to my base state of puzzlement for this one.

I am trying to use the map function as you suggested, and after checking out the reference material I tried to splice it into my LCD code, which you can see below. I clearly am missing out something though, I get the dreaded "'newValue' does not name a type" error

#include <Wire.h>
#include <LiquidCrystal_PCF8574.h>
#define DCSBIOS_IRQ_SERIAL

#include <DcsBios.h>

LiquidCrystal_PCF8574 lcd(0x27); // set the LCD address to 0x27 for a 16 chars and 2 line display

int show;




unsigned char newValue;

 newValue = map(altPressure0BufferValue, 0, 65536, 0, 10);{ // 65536 would = 10, and should never occur{
 lcd.setCursor(0, 0);
 lcd.print(newValue);
}
DcsBios::IntegerBuffer altPressure0Buffer(0x1086, 0xffff, 0, onAltPressure0Change);

/*void onAltPressure1Change(unsigned int newValue) {
   lcd.setCursor(7, 0);
 lcd.print(newValue);
 }
 DcsBios::IntegerBuffer altPressure1Buffer(0x1088, 0xffff, 0, onAltPressure1Change);

 void onAltPressure2Change(unsigned int newValue) {
  lcd.setCursor(0, 1);
 lcd.print(newValue);
 }
 DcsBios::IntegerBuffer altPressure2Buffer(0x108a, 0xffff, 0, onAltPressure2Change);

 void onAltPressure3Change(unsigned int newValue) {
   lcd.setCursor(6, 1);
 lcd.print(newValue);
 }
 DcsBios::IntegerBuffer altPressure3Buffer(0x108c, 0xffff, 0, onAltPressure3Change);

 /*
 void onAlt10000ftCntChange(unsigned int newValue) {
   lcd.setCursor(0, 0);
 lcd.print(newValue);
 }
 DcsBios::IntegerBuffer alt10000ftCntBuffer(0x1080, 0xffff, 0, onAlt10000ftCntChange);

 void onAlt1000ftCntChange(unsigned int newValue) {
  lcd.setCursor(7, 0);
 lcd.print(newValue);
 }
 DcsBios::IntegerBuffer alt1000ftCntBuffer(0x1082, 0xffff, 0, onAlt1000ftCntChange);

 void onAlt100ftChange(unsigned int newValue) {
   lcd.setCursor(0, 1);
 lcd.print(newValue);
 }
 DcsBios::IntegerBuffer alt100ftBuffer(0x107e, 0xffff, 0, onAlt100ftChange);
*/

void setup() {
 lcd.begin(16, 2);
 lcd.clear();
 DcsBios::setup();

}

void loop() {
 DcsBios::loop();
 lcd.setBacklight(255);
}

Cheers

Les

I think your problem is here:

unsigned char newValue;

 newValue = map(altPressure0BufferValue, 0, 65536, 0, 10);{ // 65536 would = 10, and should never occur{
 lcd.setCursor(0, 0);
 lcd.print(newValue);
}

Firstly, this code isn't inside a function.

You have the comment and LCD commands inside curly braces{}.

But I think what's causing the particular error you reported is that you're defining newValue as a character, then trying to map it as a number.

Try leaving it as a number and then converting it later only if you need to.

So I think you need to replace the code quoted above with this:

void onAltPressure0Change(unsigned int newValue) {
 newValue = map(newValue, 0, 65536, 0, 10); // 65536 would = 10, and should never occur

 lcd.setCursor(0, 0);
 lcd.print(newValue);
}

Or even make it usable in your final code by changing it subtly to include global variables:

 int AltPressure0digit;  // put this and the ones for the other digits with your variable definitions

void onAltPressure0Change(unsigned int newValue) {
 AltPressure0digit = map(newValue, 0, 65536, 0, 10); // 65536 would = 10, and should never occur

 lcd.setCursor(0, 0);
 lcd.print(AltPressure0digit);
}

Using this version sets a global variable that can be used in other functions and retains newValue after the mapping, so you could display it as well for diagnostic purposes.

Ok, I did the changes as follows

#include <Wire.h>
#include <LiquidCrystal_PCF8574.h>
#define DCSBIOS_IRQ_SERIAL

#include <DcsBios.h>

LiquidCrystal_PCF8574 lcd(0x27); // set the LCD address to 0x27 for a 16 chars and 2 line display

int show;




//unsigned char newValue;
void onAltPressure0Change(unsigned int newValue0) {

 int Value0 = map(newValue0, 0, 65536, 0, 10); // 65536 would = 10, and should never occur{
 lcd.setCursor(4, 0);
 lcd.print(Value0);
}
DcsBios::IntegerBuffer altPressure0Buffer(0x1086, 0xffff, 0, onAltPressure0Change);

void onAltPressure1Change(unsigned int newValue1) {

 int Value1 = map(newValue1, 0, 65536, 0, 10); // 65536 would = 10, and should never occur{

 lcd.setCursor(3, 0);
 lcd.print(Value1);
}
DcsBios::IntegerBuffer altPressure1Buffer(0x1088, 0xffff, 0, onAltPressure1Change);

void onAltPressure2Change(unsigned int newValue2) {

 int Value2 = map(newValue2, 0, 65536, 0, 10); // 65536 would = 10, and should never occur{
 lcd.setCursor(2, 0);
 lcd.print(Value2);
}
DcsBios::IntegerBuffer altPressure2Buffer(0x108a, 0xffff, 0, onAltPressure2Change);


void onAltPressure3Change(unsigned int newValue3) {

 int Value3 = map(newValue3, 0, 65536, 0, 10); // 65536 would = 10, and should never occur{
 lcd.setCursor(1, 0);
 lcd.print(Value3);
}
DcsBios::IntegerBuffer altPressure3Buffer(0x108c, 0xffff, 0, onAltPressure3Change);





void setup() {
 lcd.begin(16, 2);
 lcd.clear();
 DcsBios::setup();


}

void loop() {
 DcsBios::loop();
 lcd.setBacklight(255);
}

Which works, but is reading one less for each number, so 2992 becomes 1881 - an improvement but not sure why the data is reading like that

Next step (even though there is the error above) is to test it in my OLED sketch to see how stable it is

cheers

Les

I have spliced in the code above to the OLED sketch, and unfortunately the erratic indication continues. ***edit - which is obvious because I did not comment out the original references..... what a numpty

Les

I commented out and revised the sketch so now I can compile and load this sketch

#define DCSBIOS_DEFAULT_SERIAL

#include <DcsBios.h>
#include <Arduino.h>
//#include <U8g2lib.h>
#include <Wire.h>
#include <U8g2smalllib.h>
U8G2_SSD1306_64X32_1F_F_HW_I2C u8g2(U8G2_R0, /* reset=*/ U8X8_PIN_NONE);

char* displayString = "----";

// onDcsBiosWrite does not exist anymore, use Int16Buffers instead


void onAltPressure0Change(unsigned int newValue0) {

 int Value0 = map(newValue0, 0, 65536, 0, 9); // 65536 would = 10, and should never occur{
 displayString[0] = (Value0); 
 
}
DcsBios::IntegerBuffer altPressure0Buffer(0x1086, 0xffff, 0, onAltPressure0Change);

void onAltPressure1Change(unsigned int newValue1) {

 int Value1 = map(newValue1, 0, 65536, 0, 9); // 65536 would = 10, and should never occur{
 displayString[1] = (Value1); 

 
}
DcsBios::IntegerBuffer altPressure1Buffer(0x1088, 0xffff, 0, onAltPressure1Change);

void onAltPressure2Change(unsigned int newValue2) {

 int Value2 = map(newValue2, 0, 65536, 0, 9); // 65536 would = 10, and should never occur{
 displayString[2] = (Value2);
 
}
DcsBios::IntegerBuffer altPressure2Buffer(0x108a, 0xffff, 0, onAltPressure2Change);


void onAltPressure3Change(unsigned int newValue3) {

 int Value3 = map(newValue3, 0, 65536, 0, 9); // 65536 would = 10, and should never occur{
 displayString[3] = (Value3); 
 
}
DcsBios::IntegerBuffer altPressure3Buffer(0x108c, 0xffff, 0, onAltPressure3Change);


void setup() {

 u8g2.begin();

 
u8g2.clearBuffer();
u8g2.setFont(u8g2_font_fub20_tn );
u8g2.setCursor(0, 24);
u8g2.print(displayString);
u8g2.sendBuffer();

delay (10);

 DcsBios::setup();
}

void loop() {
 DcsBios::loop();

It clearly isn't reading the displayString values correctly because all I get on the OLED is " ---- " which is what is being defined as the char* at the beginning of the sketch. I've obviously got something in the wrong place

By the way, by changing the mapping to 0 to 9 it cured the out by one digit issue

Cheers

Les

I notice " (Value0) ", etc. That doesn't need parentheses. I don't think it's causing an issue in this case though. It's treated as parentheses in a maths function.

I think you might need to convert your digit values to chars because you're using a char array to store them.

If you put your digit values in as they are (0-9), you're storing the control characters or the custom characters. You need to store them in the char array as their ASCII equivalents (48-57 in decimal).

Try changing

displayString[0] = (Value0);

to

displayString[0] = Value0 +'0';  // Convert to ASCII and store

This adds the ASCII value of the "0" character to the digit value before it's stored in your char array.

By the way, by changing the mapping to 0 to 9 it cured the out by one digit issue

Odd. Maybe the DCS mapping is off a bit. The table I made (from actual code results) indicates 0-10 should be OK.

But, what should work, and what does work are not always the same. :D

I tried it, to no avail. I even tried it adding 48 to the number just in case

It makes me wonder if I'm using the OLED library correctly, it the syntax I'm using essentially ignoring the instances of displayString as they are inside their own argument?

Cheers

Les

No Idea.

If that doesn't work maybe try making the digits into a single number and sending that.

i.e.

AltPressure = (Value3 * 1000) + (Value2 * 100) + (Value1 * 10) + Value0;

And

u8g2.print(AltPressure);

Don't forget to define Value0, etc. and AltPressure as global variables - At the beginning, outside of a function.

And " Char* " might be an issue:

https://forum.arduino.cc/index.php?topic=44034.0

I've been messing around with this, and there's a few points to feed back

Firstly I have three OLED's currently functioning on my rig, all connected directly by USB, namely the following displays:-

scrolling altimeter digital readout, using a 128 x 64 OLED using the Adafruit SSD1306 protocol

scrolling fuel quantity digital readout, using a 128 x 32 OLED using the Adafruit SSD1306 protocol

non-scrolling barometric pressure readout, using a 64 x 32 OLED using the U8G2 protocol

The use of the U8G2 protocol was driven by the fact that the 64 x 32 OLED's don't work with the SSD1306 protocol

1) all three OLED's glitch, with the altimeter displays being worse than the fuel quantity readout and the Baro pressure readout being the worst of the three, despite being the simplest sketch

2) even if the USB connections to everything else is disconnected the remaining single OLED display will still glitch

3) the fuel quantity and altimeter readouts are already using the map function in their scrolling script to convert the 0 to 65535 values to integers between 1 and 10

4) I have checked the outputs from DCS BIOS for all three parameter sets with an LCD character display and the output from DCS is stable and clean

5) using the map function to convert the output to single digit integers then outputting to the LCD display, the display is perfect, smooth, clean, stable, and correct.

6) my scrolling sketches are derived from MiddleFart's scrolling altimeter sketch, which was designed for a 128 x 32 OLED module. I loaded up his original sketch on a spare 128 x 32 OLED module and tried that, and while it is much better than the equivalent 128 x 64 altimeter sketch, still glitches, so I can see that 128 x 32 modules are more stable.

7) I have a number of OLED modules, and the characteristic is repeatable across them, where the OLED compatibility allows - some 128 x 32 OLED's work with SSD1306, some need U8G2, not sure why

So I am forced to conclude that there is some kind of issue with the OLED's and these sketches. I am able to load and run the example sketches for the OLED's with no problems.

Maybe a vain hope, but does someone have a good stable DCS BIOS sketch for an OLED that they can post for me to try?

Cheers

Les

I wonder if your data flow is too high for one arduino to handle the interface AND the display.

Or maybe the I2C data rate is too high.

I had a quick rummage, and this looks a bit like what you're trying to achieve:

https://forums.eagle.ru/showthread.php?p=3337986&highlight=SSD1306#post3337986

Thanks, not sure what, if anything I could do about the data flow.

I may try loading the sketch in a Mega to see if that changes anything, but feeing a bit dispirited at the moment. Tomorrow with a fresh start I think!

Cheers

Les

I dunno.

Maybe it needs the display-driving arduino separated from the one that extracts the data.

You say the numbers are stable on a simple display, but get screwed up in the OLEDs.

Maybe your problem is that the arduino receiving and decoding the data is the same one trying to tell the OLED how to display the numbers. Maybe it should be telling another arduino WHAT to display, rather than HOW?

What is puzzling is that you're having trouble that others don't seem to be.

What is puzzling is that you're having trouble that others don't seem to be.

Seems to be the story of my cockpit build, have a look at the issues I had with RS485....

I played around with this a bit more this morning. I loaded up the altimeter sketch onto a Mega, and with a new 128 x 64 OLED ran it, with identical glitching.

I also modified the Baro Alt sketch so only two numbers instead of four were displayed, in case the adjacent numbers were trying to overwrite each other - no, the two missing digits stay missing and the remaining displayed ones jump about randomly, and as I had the LCD display showing the output from DCS bios, I could see that the output does not appear to be at fault.

Yet again I am at a dead end. I was thinking of asking over on the Arduino forum, but lately the responses from there have been sarcastic and belittling, with them making you feel stupid for asking questions because you don't understand it. You get answers that are equally unfathomable as the original problem and you are made to feel like a retard because you don't know what it means, and that you shouldn't be messing with stuff if you don't understand it.

Maybe I should park this for a while and get on with something else, it's not like it's the only job left to do!

Cheers

Les

Yet again I am at a dead end. I was thinking of asking over on the Arduino forum, but lately the responses from there have been sarcastic and belittling, with them making you feel stupid for asking questions because you don't understand it. You get answers that are equally unfathomable as the original problem and you are made to feel like a retard because you don't know what it means, and that you shouldn't be messing with stuff if you don't understand it.

I've noticed that too. It's annoyingly unhelpful.

I've been having a rummage on these forums (and spotted you pop up a few times ;) )

Regarding the altimeter, I see you tried this:

https://forums.eagle.ru/showpost.php?p=4194969&postcount=58

But it seems you're trying to run it now with a 64-line display.

In the comments on some code linked to in a video about that, it says an arduino might not be fast enough.

So maybe my thought about too much data throughput is closer than I thought.

I just ran the barometric version of Middlefart's code and had the same in-flight glitching you are reporting.

Regarding the Barometric pressure, have you tried Ian's example here:

https://forums.eagle.ru/showpost.php?p=3096525&postcount=699

I've not tried it myself yet, but it seems to me you should be able to use that as-is.

Not sure how to change it to I2C, though.

BTW, regarding your comment on another thread:

It also strangely will not load on a Nano board, with an error message that it is too big coming up. I have it on an Uno board, on which it works fine. Is there something that I can do to reduce it so that it fits on the Nano? **EDIT** tried on another Nano board and it compiled fine - no idea why

It might be because some Nanos have a different microcontroller chip that has less memory.

Thanks - I was going to have a go at just writing a sketch to output the raw values of the Altimeter data to the OLEDs without any scrolling of conversion, just to see if it wrote it in a stable manner.

In a way it is comforting that you are getting the same glitching, makes me feel less like I'm being picked on! Nonetheless we need to find a way round it.

Ian's sketch needs to be converted to I2C as you say, but that's maybe a bit advanced for my level. Part of the issue is that making a simpit like this takes up time and multiple skillsets and practices.

I could possibly dedicate myself to trying to learn in sufficient depth how to program more advanced Adruino programs, but I would have to self teach, and it would leave no time to actually put it to any practical use. That's one of my bugbears with the Arduino forum, the use of the sketch is a means to an end, and only part of it at that. We need specialists to help us out with the bits we are not good with to allow us to get on with the bits we are confident with. I'm a 53 year old engineer. All this computing stuff came about after I left school, so it is not something I've ever had any formal training with.

Interesting thought about the Arduino speed, it never occurred to me. And presumably because the different Arduinos only vary in memory capacity and number of outputs and not speed, using a Mega won't help.

Lastly, I eventually worked out that I have two different types of Nano, the ATmega 168 type and the ATmega328. That's why some don't load, and having to use the U8G2 protocol for the 64 X 32 OLEDs forces the use of the larger memory types, as do the scrolling sketches

Cheers

Les