lesthegrngo

Hi all, I previously had the A10C RWR and CDU working on separate monitors, alongside the two MFCD's using four monitors. My issue is not the monitorsetup in terms of the positioning on the windows, more that in the case of the RWR and CDU, no matter what I call them out as, or where I place them they no longer work. I don't know if the name of them has changed, but there is no effect in game; I want this equally for the A10C and A10CII Here's my .lua script _ = function(p) return p; end; name = _('Camera+LMFCD+RMFCD+RWR+CDU'); Description = 'Left MFCD to left monitor,Right MFCD to right, CDU and camera on the center' Viewports = { Center = { x = 0; y = 0; width = 2560; height = 1440; viewDx = 0; viewDy = 0; aspect = 1.778; } } LEFT_MFCD = { x = 2750; y = 0; width = 610; height = 610; } RIGHT_MFCD = { x = 2750; y = 600; width = 610; height = 630; } ED_A10C_RWR = { x = 3070; y = 0; width = 610; height = 610; } ED_A10C_CDU = { x = 3584; y = 1024; width = 800; height = 480; } UIMainView = Viewports.Center GU_MAIN_VIEWPORT = Viewports.Center Can anyone see if there is anything incorrect there? Cheers Les

I'm going to make a new PCB with decoupled circuitry for the IR sensor and nano. I suspect that there is interference or at least interaction between the different nanos, and maybe the stepper driver (A4899) as well, and have them powered separately. I'm not certain it will cure it but I will certainly try it to test. You can see my sketch above for the Altimeter, and while it works I have always had reservations about it as I don't think that the motion is as smooth as it could be. I'm willing to try different setups, if someone has a sketch that works well plus a schematic of the hardware I would be willing to give it a go. If possible I would prefer not to have to use a stepper driver (and definitely not an EasyDriver!) but as my setup already has 5v and 12v feeds it won't be a problem. Another change I am going to make is to ditch the USB HDMI devices I am using to drive the 5 small monitors that are used with Helios and MonitorSetup. I have to confess that I have been burying my head in the sand a little on this one, ignoring the obvious issues that I now am facing up to. They work, they are neat and simple to install but the bald fact of the matter is that they are not reliable, and Windows doesn't play very nicely with them for setups like ours. It is a lottery as to whether Windows will remember the desktop setup that you make, and to have half a chance of this you can't disconnect the USB connection. If you do, even if the PC is powered down, the chances are that when you power up the desktop will default to all the monitors in a horizontal line. This wouldn't be so bad if it was always the same order, but that isn't happening. As a result, all the carefully selected MonitorSetup.lua work goes straight out of the window and you have to mess around with it to reset at least 30% of the time. It also means Helios has to be reset virtually every time you start it, and sometimes the displays simply don't display. Maybe I'm expecting too much from it, but it is not a fit and forget plug and play setup. I have an old GTX660 that I removed after Windows stopped recognising it as a secondary GPU, I will try and resurrect that. I also have the GTX1070Ti in my son's desktop I can try, I'm sure he won't complain if I end up replacing that with something better 'cos I stole it. I never really investigated why I couldn't get the second GPU to work (it used to, then a Windows update came along and messed it up) so maybe a bit of sleuthing is in order. Of course, it also means going back to 6 DisplayPort/ HDMI cables, one of the reasons I turned to the USB setup in the first place. However I don't really think I have much of a choice if I want a good solid reliable setup. There's no doubt that the USB setup packages really nicely, it really did help simplify the whole lot, but it means I can't just jump on the rig and fly, I have to spend 15 to 20 minutes first making sure the configuration is OK. Not workable in the long run Les

Hi all, I am looking for a way to trim the background frames for the ADI and HSI on the A10-C. Due to my setup, I have physical bezels, but using the standard instrument backgrounds, either the top of the HSI overlays the bottom of the ADI, or the bottom of the ADI overlays the top of the HSI. If I could modify one of the two to crop it slightly it would solve this, however I am unable to locate the files to modify them in an image editor. Can anyone advise on how to do this? Cheers Les

Hi Vinc, yeah, I checked the slave number. I set up an Excel spreadsheet to track them that automatically highlights if the number is duplicated, after falling foul of that. Having said that, I can change it and see if it makes a difference Cheers Les

Hi All, I can't believe I am actually saying this, but I am nearly finished* building the rig! I do have to go back and find out why Helios isn't working but that's not really building it. I have converted most of my sketches and panels successfully to RS485 but there is one issue I can't solve. My Altimeter will work in USB mode but defies all my attempts to make it run under RS485. Now, I could just keep it as a USB sketch but I did intend it to be run on RS485 to reduce the number of USB connections. I have tried it on its own, with nothing else connected and it just jitters around. I have replace the nano, Max487 chip, tested the IR sensor (as I said, it works in USB mode. The other three nanos on the same PCB run RS485 flawlessly, so it can't be that, or at least not the basic PCB. I have checked it and rechecked it for shorts or open circuits, but can't find any issues with it, although I accept that there may be issues with the design. Is there anything about the sketch below that would interfere with RS485? *for a given value of 'finished'.... I know it will never really be finished as I will always find something to improve //#define DCSBIOS_IRQ_SERIAL #define DCSBIOS_RS485_SLAVE 49 #define TXENABLE_PIN 2 #include <AccelStepper.h> #include "DcsBios.h" #include <Wire.h> struct StepperConfig { unsigned int maxSteps; unsigned int acceleration; unsigned int maxSpeed; }; class Vid29Stepper : public DcsBios::Int16Buffer { private: AccelStepper& stepper; StepperConfig& stepperConfig; inline bool zeroDetected() { return digitalRead(irDetectorPin) == 1; } unsigned int (*map_function)(unsigned int); unsigned char initState; long currentStepperPosition; long lastAccelStepperPosition; unsigned char irDetectorPin; long zeroOffset; bool movingForward; bool lastZeroDetectState; long normalizeStepperPosition(long pos) { if (pos < 0) return pos + stepperConfig.maxSteps; if (pos >= stepperConfig.maxSteps) return pos - stepperConfig.maxSteps; return pos; } void updateCurrentStepperPosition() { // adjust currentStepperPosition to include the distance our stepper motor // was moved since we last updated it long movementSinceLastUpdate = stepper.currentPosition() - lastAccelStepperPosition; currentStepperPosition = normalizeStepperPosition(currentStepperPosition + movementSinceLastUpdate); lastAccelStepperPosition = stepper.currentPosition(); } public: Vid29Stepper(unsigned int address, AccelStepper& stepper, StepperConfig& stepperConfig, unsigned char irDetectorPin, long zeroOffset, unsigned int (*map_function)(unsigned int)): Int16Buffer(address), stepper(stepper), stepperConfig(stepperConfig), irDetectorPin(irDetectorPin), zeroOffset(zeroOffset), map_function(map_function), initState(0), currentStepperPosition(0), lastAccelStepperPosition(0) { } virtual void loop() { if (initState == 0) { // not initialized yet pinMode(irDetectorPin, INPUT); stepper.setMaxSpeed(stepperConfig.maxSpeed); stepper.setSpeed(1000); initState = 1; } if (initState == 1) { // move off zero if already there so we always get movement on reset // (to verify that the stepper is working) if (zeroDetected()) { stepper.runSpeed(); } else { initState = 2; } } if (initState == 2) { // zeroing if (!zeroDetected()) { stepper.runSpeed(); } else { stepper.setAcceleration(stepperConfig.acceleration); stepper.runToNewPosition(stepper.currentPosition() + zeroOffset); // tell the AccelStepper library that we are at position zero stepper.setCurrentPosition(0); lastAccelStepperPosition = 0; // set stepper acceleration in steps per second per second // (default is zero) stepper.setAcceleration(stepperConfig.acceleration); lastZeroDetectState = true; initState = 3; } } if (initState == 3) { // running normally // recalibrate when passing through zero position bool currentZeroDetectState = zeroDetected(); if (!lastZeroDetectState && currentZeroDetectState && movingForward) { // we have moved from left to right into the 'zero detect window' // and are now at position 0 lastAccelStepperPosition = stepper.currentPosition(); currentStepperPosition = normalizeStepperPosition(zeroOffset); } else if (lastZeroDetectState && !currentZeroDetectState && !movingForward) { // we have moved from right to left out of the 'zero detect window' // and are now at position (maxSteps-1) lastAccelStepperPosition = stepper.currentPosition(); currentStepperPosition = normalizeStepperPosition(stepperConfig.maxSteps + zeroOffset); } lastZeroDetectState = currentZeroDetectState; if (hasUpdatedData()) { // convert data from DCS to a target position expressed as a number of steps long targetPosition = (long)map_function(getData()); updateCurrentStepperPosition(); long delta = targetPosition - currentStepperPosition; // if we would move more than 180 degree counterclockwise, move clockwise instead if (delta < -((long)(stepperConfig.maxSteps / 2))) delta += stepperConfig.maxSteps; // if we would move more than 180 degree clockwise, move counterclockwise instead if (delta > (stepperConfig.maxSteps / 2)) delta -= (long)stepperConfig.maxSteps; movingForward = (delta >= 0); // tell AccelStepper to move relative to the current position stepper.move(delta); } stepper.run(); } } }; /* modify below this line */ /* define stepper parameters multiple Vid60Stepper instances can share the same StepperConfig object */ struct StepperConfig stepperConfig = { 730, // maxSteps 2200, // maxSpeed 1000 // acceleration }; // define AccelStepper instance AccelStepper stepper(AccelStepper::DRIVER, 4, 5); //was 11, 10 // define Vid29Stepper class that uses the AccelStepper instance defined in the line above // v-- arbitrary name Vid29Stepper alt100ftPointer(0x107e, // address of stepper data stepper, // name of AccelStepper instance stepperConfig, // StepperConfig struct instance 6, // IR Detector Pin (must be HIGH in zero position) 0, // zero offset [](unsigned int newValue) -> unsigned int { /* this function needs to map newValue to the correct number of steps */ return map(newValue, 65535, 0, 0, stepperConfig.maxSteps - 1); }); void setup() { DcsBios::setup(); } void loop() { DcsBios::loop(); }

If you look here you will see that there is a post about the oxygen panel and converting rotary switches so that they were geared using 3D printed parts- it works really well

Nice! A10 guy unfortunately, but you never know what the next project will be! thanks Les

I’m interested to try this myself- I have some sketches that are not limited by pins but by the number of DCS Bios components connected to it. For example, a mega with all 6 IFF BCD switches connected can only accept 4 more switches before the sketch fails to work, despite using less than a quarter of the available pins cheers

Hi all The Altimeter works well in USB mode, but I simply cannot get it to function properly in RS485 mode. I have three other Nanos on the same PCB for the altimeter scrolling OLED, climb gauge and Baro Alt OLED. All work fine in RS485 mode so the shared RS485 traces and wiring is apparently OK. I momentarily considered the IR circuit with the resistors to maybe be contributory as there is a path through that from VCC to GND, but that would affect the other RS485 devices as it is common to them too. I have been back and forth through the PCB with a multimeter and can confirm that there are no open circuits, shorts, or any other apparent issues. With the 12v to the stepper driver connected, when you connect the RS485 cable it will instantly move the pointer to the zero position, so the sketch seems to at least be partially working. However thereafter despite the RX light flashing, not much else happens. It looks like the pointer is trying to move, but not properly, it gives the occasional twitch. The other point of note is that when I connect it on the same slave line as other devices, it makes them glitch occasionally too, however if it is on another slave line it does not affect the others. Can anyone give me a clue as to why it is not working in RS485 mode? //#define DCSBIOS_IRQ_SERIAL #define DCSBIOS_RS485_SLAVE 49 #define TXENABLE_PIN 2 #include <AccelStepper.h> #include "DcsBios.h" #include <Wire.h> struct StepperConfig { unsigned int maxSteps; unsigned int acceleration; unsigned int maxSpeed; }; class Vid29Stepper : public DcsBios::Int16Buffer { private: AccelStepper& stepper; StepperConfig& stepperConfig; inline bool zeroDetected() { return digitalRead(irDetectorPin) == 1; } unsigned int (*map_function)(unsigned int); unsigned char initState; long currentStepperPosition; long lastAccelStepperPosition; unsigned char irDetectorPin; long zeroOffset; bool movingForward; bool lastZeroDetectState; long normalizeStepperPosition(long pos) { if (pos < 0) return pos + stepperConfig.maxSteps; if (pos >= stepperConfig.maxSteps) return pos - stepperConfig.maxSteps; return pos; } void updateCurrentStepperPosition() { // adjust currentStepperPosition to include the distance our stepper motor // was moved since we last updated it long movementSinceLastUpdate = stepper.currentPosition() - lastAccelStepperPosition; currentStepperPosition = normalizeStepperPosition(currentStepperPosition + movementSinceLastUpdate); lastAccelStepperPosition = stepper.currentPosition(); } public: Vid29Stepper(unsigned int address, AccelStepper& stepper, StepperConfig& stepperConfig, unsigned char irDetectorPin, long zeroOffset, unsigned int (*map_function)(unsigned int)): Int16Buffer(address), stepper(stepper), stepperConfig(stepperConfig), irDetectorPin(irDetectorPin), zeroOffset(zeroOffset), map_function(map_function), initState(0), currentStepperPosition(0), lastAccelStepperPosition(0) { } virtual void loop() { if (initState == 0) { // not initialized yet pinMode(irDetectorPin, INPUT); stepper.setMaxSpeed(stepperConfig.maxSpeed); stepper.setSpeed(1000); initState = 1; } if (initState == 1) { // move off zero if already there so we always get movement on reset // (to verify that the stepper is working) if (zeroDetected()) { stepper.runSpeed(); } else { initState = 2; } } if (initState == 2) { // zeroing if (!zeroDetected()) { stepper.runSpeed(); } else { stepper.setAcceleration(stepperConfig.acceleration); stepper.runToNewPosition(stepper.currentPosition() + zeroOffset); // tell the AccelStepper library that we are at position zero stepper.setCurrentPosition(0); lastAccelStepperPosition = 0; // set stepper acceleration in steps per second per second // (default is zero) stepper.setAcceleration(stepperConfig.acceleration); lastZeroDetectState = true; initState = 3; } } if (initState == 3) { // running normally // recalibrate when passing through zero position bool currentZeroDetectState = zeroDetected(); if (!lastZeroDetectState && currentZeroDetectState && movingForward) { // we have moved from left to right into the 'zero detect window' // and are now at position 0 lastAccelStepperPosition = stepper.currentPosition(); currentStepperPosition = normalizeStepperPosition(zeroOffset); } else if (lastZeroDetectState && !currentZeroDetectState && !movingForward) { // we have moved from right to left out of the 'zero detect window' // and are now at position (maxSteps-1) lastAccelStepperPosition = stepper.currentPosition(); currentStepperPosition = normalizeStepperPosition(stepperConfig.maxSteps + zeroOffset); } lastZeroDetectState = currentZeroDetectState; if (hasUpdatedData()) { // convert data from DCS to a target position expressed as a number of steps long targetPosition = (long)map_function(getData()); updateCurrentStepperPosition(); long delta = targetPosition - currentStepperPosition; // if we would move more than 180 degree counterclockwise, move clockwise instead if (delta < -((long)(stepperConfig.maxSteps / 2))) delta += stepperConfig.maxSteps; // if we would move more than 180 degree clockwise, move counterclockwise instead if (delta > (stepperConfig.maxSteps / 2)) delta -= (long)stepperConfig.maxSteps; movingForward = (delta >= 0); // tell AccelStepper to move relative to the current position stepper.move(delta); } stepper.run(); } } }; /* modify below this line */ /* define stepper parameters multiple Vid60Stepper instances can share the same StepperConfig object */ struct StepperConfig stepperConfig = { 730, // maxSteps 2200, // maxSpeed 1000 // acceleration }; // define AccelStepper instance AccelStepper stepper(AccelStepper::DRIVER, 4, 5); //was 11, 10 // define Vid29Stepper class that uses the AccelStepper instance defined in the line above // v-- arbitrary name Vid29Stepper alt100ftPointer(0x107e, // address of stepper data stepper, // name of AccelStepper instance stepperConfig, // StepperConfig struct instance 6, // IR Detector Pin (must be HIGH in zero position) 0, // zero offset [](unsigned int newValue) -> unsigned int { /* this function needs to map newValue to the correct number of steps */ return map(newValue, 65535, 0, 0, stepperConfig.maxSteps - 1); }); void setup() { DcsBios::setup(); } void loop() { DcsBios::loop(); } Cheers Les

Hi all, I noticed that in game, when the oil pressure to drops to zero on the gauge, instead of the L- (or R-)ENG PRESS light flashing, the L- (or R-) ENG HOT lights flash instead on the cockpit view CLP. They are the ones immediately above the PRESS lights so suspect it is a mapping issue Can this be fixed? Cheers Les

I use a MAX7219 chip with a matrix using this sketch, which was derived from one that was posted on here some years ago //#define DCSBIOS_IRQ_SERIAL //#define DCSBIOS_DEFAULT_SERIAL #define DCSBIOS_RS485_SLAVE 60 #define TXENABLE_PIN 2 #include <DcsBios.h> #include <LedControl.h> LedControl lc=LedControl(11,13,10,1);//DIN,CLK,LOAD,# OF IC's unsigned char cl_row_map[48] = { 0, 0, 0, 0, 1, 1, 1, 1, 2, 2, 2, 2, 3, 3, 3, 3, 4, 4, 4, 4, 5, 5, 5, 5, 0, 0, 0, 0, 1, 1, 1, 1, 2, 2, 2, 2, 3, 3, 3, 3, 5, 5, 5, 5, //4, 4, 4, 4, 4, //5 }; #define SEG_DP (1<<7) #define SEG_A (1<<6) #define SEG_B (1<<5) #define SEG_C (1<<4) #define SEG_D (1<<3) #define SEG_E (1<<2) #define SEG_F (1<<1) #define SEG_G (1<<0) unsigned char cl_mask_map[48]= { SEG_C, SEG_D, SEG_F, SEG_A, SEG_C, SEG_D, SEG_F, SEG_A, SEG_C, SEG_D, SEG_F, SEG_A, SEG_C, SEG_D, SEG_F, SEG_A, SEG_C, SEG_D, SEG_F, SEG_A, SEG_C, SEG_D, SEG_F, SEG_A, SEG_B, SEG_E, SEG_G, SEG_DP, SEG_B, SEG_E, SEG_G, SEG_DP, SEG_B, SEG_E, SEG_G, SEG_DP, SEG_B, SEG_E, SEG_G, SEG_DP, SEG_B, SEG_E, SEG_G, SEG_DP, SEG_B, SEG_E, SEG_G, SEG_DP, }; unsigned char max7219_rows[8]; void setup() { DcsBios::setup(); memset(max7219_rows, 0xff, sizeof(max7219_rows)); lc.shutdown(0,false); //turn on the display lc.setIntensity(0,15);//set the brightness lc.clearDisplay(0); //clear rthe display and get ready for new data } void updateCautionLights(unsigned int address, unsigned int data) { unsigned char clp_row = (address - 0x10d4) * 2; unsigned char start_index = clp_row * 4; unsigned char column = 0; unsigned char i; bool is_on; for (i=0; i<16; i++) { is_on = data & 0x01; // set caution light state (clp_row, column, is_on) if (is_on) { max7219_rows[cl_row_map[start_index+i]] |= cl_mask_map[start_index+i]; } else { max7219_rows[cl_row_map[start_index+i]] &= ~(cl_mask_map[start_index+i]); } data >>= 1; column++; if (column == 4) { clp_row++; column = 0; } } } void onClpData1Change(unsigned int newValue) { updateCautionLights(0x10d4, newValue); } DcsBios::IntegerBuffer clpData1(0x10d4, 0xffff, 0, onClpData1Change); void onClpData2Change(unsigned int newValue) { updateCautionLights(0x10d6, newValue); } DcsBios::IntegerBuffer clpData2(0x10d6, 0xffff, 0, onClpData2Change); void onClpData3Change(unsigned int newValue) { updateCautionLights(0x10d8, newValue); } DcsBios::IntegerBuffer clpData3(0x10d8, 0xffff, 0, onClpData3Change); void loop() { DcsBios::loop(); // update MAX7219 unsigned char i; for (i=0; i<8; i++) { lc.setRow(0, i, max7219_rows[i]); } } Now, where the following parts came from I don't know, they don't show up on that Bort thing void onClpData1Change(unsigned int newValue) { updateCautionLights(0x10d4, newValue); } DcsBios::IntegerBuffer clpData1(0x10d4, 0xffff, 0, onClpData1Change); void onClpData2Change(unsigned int newValue) { updateCautionLights(0x10d6, newValue); } DcsBios::IntegerBuffer clpData2(0x10d6, 0xffff, 0, onClpData2Change); void onClpData3Change(unsigned int newValue) { updateCautionLights(0x10d8, newValue); } DcsBios::IntegerBuffer clpData3(0x10d8, 0xffff, 0, onClpData3Change); By changing the individual callouts I can manage the sketch to make my panel show the same as the game, however the one that confuses me is that when oil pressure drops to zero in-game, instead of the on screen cockpit L-OIL PRESS and R-OIL PRESS lights illuminating, you get the L-ENG HOT and R-ENG HOT lights on the in-game display. That's just incorrect, the in game CWP should have the oil pressure lights flashing. It's an OCD thing! Les

All, I notice that in game, when I have been checking out the warning panel, there are a couple of mismatches. I have set the lights to function using BoboBears debugger, and they are set correctly according to that. However in game, when the APU GEN light should be flashing (and is on screen), on the actual panel the STALL SYS light is flashing. I can correct that, it looks like the last two lines are inverted on my sketch. However, when the L-OIL PRESS and R-OIL PRESS should be illuminating, on the screen the L-ENG HOT and R-ENG HOT lights are flashing, and the correct lights are flashing on the actual panel! So in game it looks like lines 5 and 6 are inverted, and my sketch has it correct. ****EDIT**** Pitch Sys and Yaw Sys lights are also correct in game but reversed on the output Does anyone else see that? Les

Confirmed, calibration issues Thanks Les

No, but I wondered if there was something about the loaders that made the difference. As I said, the number of times when pins would not work on the new ones but work perfectly with the At168's and older 328P's shows something is going on, and maybe it's the way the data is sent to the Nano Les

I have come back to this as the 'new' 328 nanos I have just don't want to work. I have some older ones that use the Old Bootloader that are much more compatible, especially with RS485 devices. The trouble is I have used all mine up and have about ten of the 'new' ones that are not able to function. I have ordered some more AT168 versions, which I will use to populate those parts of the rig that can use them, but it essentially excludes anything with an OLED. I am hoping I can harvest enough of the 'old' 328's that I can use to service all the ones that need it, but want to hedge my bets and try and get some more of the older ones. The trouble is the only reliable way to tell the apart is by trying to load a sketch on them, if you use the wrong bootloader they won't load. so a) how can I tell they are the 'old' version and b) where can I order some? Cheers Les

only the rudder axis, not the brakes Les

I'll double check - I upgraded to the MFG Crosswinds and made pendulum pedals for them, maybe my setup isn't right Les

Yeah, I am going for the two nano solution, simply because I have them sitting around. A bit messier with the need for some more wiring, but not too much. I do wonder why that limitation is there though Cheers Les

ok, thanks- I thought I tried doing that, but maybe I didn't press them hard enough Cheers Les

I have been looking for this for a while, more out of curiosity that anything else, as I can assign it to a Bodnar controlled switch but where exactly in the cockpit is the 'release wheel brakes' switch? Sometimes when I go to quick start - takeoff, the wheel brakes are on, and I have to tap the W key to release it, That means, in theory at least, that there should be a button or switch in the cockpit that performs the same function I want as much as possible to not have to use the keyboard, if nothing else due to the inconvenience, so I will probably invent a switch (maybe by the Emergency Hand Brake lever) just to have it assigned, but would like to know if there is a real one somewhere Cheers Les

Hi Vinc I had the OLEDs working with a u8g2 version, but the sheer size of the u8g2 sketch when you are forced to use the full frame buffer option meant that you only had space to do the OLEDs and nothing else. There were advantages to the u8g2 version, there is a lot more flexibility with text and it works better for placement, but in the end the SSD1306 version was a better compromise. Now, if they were to bring out a Nano with double the memory it would make me rethink it By the way, yet again I found that there was a limit to the number of total devices that could be operated that was independent of the number of available pins. The setup theoretically would allow all 5 OLEDs via the multiplexer over pins A4 and A5, the 5 frequency rotary encoders via pins D3 to D12, and one of the rotary switches via D13, A0, A1, A2 and A3. I could make the OLEDs and the 5 encoders work fine, but as soon as I add the rotary switch line, it stops the entire sketch from working. Uncomment the rotary switch line, back it comes. I found the same behaviour with the IFF panel using the BCD switches, it would accept all the BCD switches and a maximum of four or five other switches before it made the sketch fail, and that was on a Mega. I have no idea why, I ended up just designing around it Cheers Les

I can use that with the u8g2 library. Unfortunately SSD1306 needs a different protocol. However, I was able to achieve what I wanted to by playing around with the4 sketch. It's not perfect but it does the job. One day I'll come back to this and try and improve it Cheers Les

strange...... another thing to investigate, I'm using the A10c as well cheers Les

Ok, looks like I need to re-evaluate what I need in terms of the font conversion. The .c version of the file is essentially u8g2 format and seems incompatible with the SSD1306 library, so I need to find a way to convert the bdf file to an SSD1306 compatible .h file I ended up using my son's computer to try and get bdfconv working, which did work. Not sure why it doesn't on my PC but at least I have managed to get that back. However studying the options, clearly a .h file is not one of them, so I now have to find some kind of converter that is compatible with SSD1306 files. I have found many that convert standard fonts, Squix for example, however none will do bespoke files. Cheers Les

Thanks Vinc! Not sure why, but all python based programs are disabled on my PC. They will briefly start then almost immediately shut down again. I need to find out what's going on there Cheers Les