lesthegrngo

I used this site to show me how to do mine, remembering that you have to modify the X27 stepper by cutting off the little rotation limit pin - simple enough Look for the part that says 'IR Positioning sensor' https://realsimcontrol.com/io_step.html Cheers Les

Thanks guys - on the font thing, it seems it loads all of them whether or not they are used Changing the F to 1 reduced it to 33%, so good tip there Vinc. However I obviously need to check my setup as it isn't playing ball, whether that's a mistake in physical wiring or my logical setup I don't know. Whatever, as usual I learnt something more even if I haven't solved it yet! I'll keep trying Les

I'm running into memory issues, not for the first time, due to the u8g2 library. Even using an AT328 Nano, it exceeds the memory capacity and while it will compile, despite my test sketch being a simple one, it is not possible to load it. This is the sketch I'm using #include <Arduino.h> #include <U8g2lib.h> #include <Wire.h> #define PIN_SCLK 3 // Serial Clock Input #define PIN_SDIN 2 // Serial Data Input #define PIN_RST 13 // Reset #define PIN_CS 11 // Chip Select #define PIN_DC 10 // Data/Command Control U8G2_SH1122_256X64_F_4W_HW_SPI u8g2(U8G2_R0, PIN_SPI_SS, PIN_DC, PIN_RST); void setup(void) { u8g2.begin(); } void loop(void) { u8g2.clearBuffer(); u8g2.setFont(u8g2_font_ncenR08_tr); u8g2.drawStr(32,30,"Hello \n"); u8g2.drawStr(32,45,"World!"); u8g2.sendBuffer(); delay(1000); } As you can see there is nothing imposing about the sketch itself but it uses 121% of the dynamic memory Had this problem before and got told to use a 'bigger' Arduino, but it won't fit in the available space Any ideas?

it is strange, it's almost as if the OLED / LCD devices interfere with the signal somehow. I had previously noted that you can't run an OLED and a stepper motor successfully one one Nano as the stepper movement is massively impacted. My suspicion for that is that the stepper update cadence is directly related to the OLED refresh rate, and the U8G2 driven OLEDs would slow it down to a point where it was useless. However I can't imagine why there would be any effect on other Nanos that are just connected via RS485 Despite this, the multiple Mega master solution does seem to be a viable one so my intention is to use one dedicated Master for all the stepper motor driven devices, and one or two others for all the remaining OLEDs, LCD's and things like the CLP One other thing I will try is some 5v bus bars so that the 5v supply to the devices are not just on the RS485 lines. I doubt it will make any difference but costs nothing to try Les

Thanks - I'll give it a try with the 3.3v VDD Les

I've used the U8G2 library so if that's compatible I'll try it Les

Hi all I got one of these OLED panels for the UHF radio panel, and I clearly didn't concentrate when selecting it as it has a different pinout via a 16 way FCC cable https://www.buydisplay.com/white-2-08-inch-graphic-oled-display-panel-256x64-parallel-spi-i2c The sketches that accompany it seem to be for use with ESP32 type boards, and I don't see example Arduino sketches to help me figure out. I have some LCD modules that use a similar connection, but they are wired differently (these ones) https://www.buydisplay.com/character-8x1-lcd-display-module-hd44780-controller-black-on-white So I am trying to configure them to work with the Nano's and believe that I have to use 7 of the pins, including the GND and VDD connections. The latter I was going to connect to the 3.3v Nano connection I believe the A0 connection on pin 4 is the 'load' pin, however pins 8 onwards seem to require extra hardware, yet looking at the video accompanying the site there clearly are not many connections to the dev board Other SPI devices have the following 7 pin nomenclature GND VCC D0 D1 RES DC CS Four out those are clear, however D0, D1 and DC must be the SDIN, SCLK and A0 connections, but I'm not sure which is which - any ideas? I am trying to use the sketch on the website to just try the pinout possibilities, but for some reason, despite downloading the AT98X52.H file and putting it into the libraries folder, the sketch doesn't recognise it so I can't get past the compilation stage to try it Cheers Les

I'm disappointed to report that despite putting in a dedicated 5A 5v power supply the gauge twitching is still there. Interestingly it seems to manifest itself when a device is connected that has an OLED or LCD display attached. I also tried a single Mega Master rather than the three bus version and it is the same However, when I used two Megas as masters, and ported the OLED and LCD connected devices to one and the non OLED / LCD devices to the other, it works fine I have four Megas so can add a couple more if necessary, and if it works I'm not going to complain. However it would be good to know why it behaves like that Les

definitely seems to improve if I disconnect stuff; may have to try and find a more powerful 5v PS I have an old ATX power supply somewhere, I wonder if I can repurpose it

I have it working, one of the Nano's had the I2C scan sketch installed which apparently stopped everything else from being able to work with the RS485 However there is still something not right, as the gauges periodically flicker full scale as though there is a momentary power interruption. I have a 5v supply connected directly to the RS485 mega on the RS485 bus so I know that that is not the cause of it. I also notice that the VHF radio panel only has three of the five OLEDs displaying at any one time Nonetheless it is progress and I will keep niggling away at it EDIT here's a video showing the behaviour I was describing Les

Tried it out today, I must have something wrong as it didn't work. I can see the master lights flashing, but none of the slaves are showing any lights. All the gauges do the start up routine so it's at least partly OK. Tomorrow I'll recheck it all out, see if there's a stupid error in the setup. I will probably start by going back to my old master and single bus setup to test out the wiring to rule that out Les

I have used it on a couple of gauges, using it behind thin (<2mm) 'opal' translucent acrylic. It works fine, but you won't be able to see it very well in daylight. I intend using it in the future and I intend to try and use my laser cutter to make it the correct shape, but haven't got around to it just yet. I just used a scalpel to cut it, but always made sure that I kept the original electrical connection points on it. I notice the one you have in the pic has multiple connection points, meaning that it is more flexible in terms of how you can cut it; mine only had one point I would like to go back to it but it will definitely be something that will wait for the rest to function first, then be a retro fit. Not cheap though. As for dimming, not sure, and not sure you will need it Les

got it, thanks An aside, did I see somewhere that it is better to connect the Master Mega via USB 2.0 rather than 3.0 and above? Cheers Les

Guys, looking at the DcsBiosNgRS485Master.h file in the library, it shows the following lines #define UART1_TXEN_PORT PORTE #define UART1_TXEN_DDR DDRE #define UART1_TXEN_PIN 4 #define UART2_TXEN_PORT PORTE #define UART2_TXEN_DDR DDRE #define UART2_TXEN_PIN 5 #define UART3_TXEN_PORT PORTG #define UART3_TXEN_DDR DDRG #define UART3_TXEN_PIN 5 It is calling out pin 5 twice, but also it is in conflict with the sketch which also defines the TXEn pins I will be setting up as follows TX1 / RX1 will use pin 4 as TXEn TX2 / RX2 will use pin 3 as TXEn TX3 / RX3 will use pin 2 as TXEn I assume that I do not have to make any more references that defining the TXEn pins in the sketch in the following bit of code #define UART1_TXENABLE_PIN 4 #define UART2_TXENABLE_PIN 3 #define UART3_TXENABLE_PIN 2 and the UART1 will be allocated by the library sketch definitions with this part of the code, right? #define uart1_txen_setup() UART1_TXEN_DDR |= (1<<UART1_TXEN_PIN) #define uart1_set_txen() UART1_TXEN_PORT |= (1<<UART1_TXEN_PIN) #define uart1_clear_txen() UART1_TXEN_PORT &= (1<<UART1_TXEN_PIN) #define uart2_txen_setup() UART2_TXEN_PORT |= (1<<UART2_TXEN_PIN) #define uart2_set_txen() UART2_TXEN_PORT |= (1<<UART2_TXEN_PIN) #define uart2_clear_txen() UART2_TXEN_PORT &= (1<<UART2_TXEN_PIN) #define uart3_txen_setup() UART3_TXEN_PORT |= (1<<UART3_TXEN_PIN) #define uart3_set_txen() UART3_TXEN_PORT |= (1<<UART3_TXEN_PIN) #define uart3_clear_txen() UART3_TXEN_PORT &= (1<<UART3_TXEN_PIN) Cheers Les

PCB cut and populated already, nice and neat. Just got to modify the sketch and try it now Cheers Les

Thanks for confirming Due to my limited production methods I have to have the TXEnable pins in reverse order so that I can lay out the traces without having to make a more complicated double sided PCB Cheers Les

Guys, pretty certain that the answer is yes, but want to check before committing to cutting PCB's - the TXEnable pin can be any pin I choose, right? Cheers Les

Thanks for that - I never thought of Github, like a lot of these sites I use it for downloading stuff but didn't really pay any attention to what it is! As for the character error thing, I'm not sure if it was that or not; it was coming up with lots of errors, tons of XXX is not a member of DCS BIOS, that type of thing Cheers

I will try it; why not! I hope that it doesn't give memory allocation issues or suchlike but there is only one way to find out. Tomorrow I will make a PCB shield for the mega with three MAX478 chips and connections and see how it goes Cheers Les

I have the hardware to do all four of those options The question is, which is the best in terms of least lag / dropouts / conflicts?

Errrr, no...... 'cos I didn't know I could do that! So, if I understand what you are saying correctly, I can connect 3 MAX487 chips to the Mega on the TX/RX1, TX/RX2 and TX/RX3, and have one 'network' for each part of the rig? Les

The 'return line' would be because the cockpit is essentially a 'U' shape, with the master behind the dash middle of the 'U'. That means the line would go all the way to the end of one console, then return back to the center of the 'U' before going to the other console Does that make sense? Cheers Les

Hi all, I am wiring in all the devices more permanently, however I want to know which is the best way to lay out the RS485 connections. At the moment the wiring design I have is like a tree; it starts with one main connection, which then connects to two or three connections, with wires gong to hubs. Each hub has three or four RS485 connections for each device and so on However the impression I get talking (and I use that work loosely) to the guys on the specific forums is that the RS485 network should be like a train line, one long line with 'stations' along it when the connections to the devices are made. While it would add extra wiring it would not be impossible to do, however I want to do the right thing first time. The train line version will take extra planning to get the return wiring for each console. The way the 'experts' were talking it would all go horribly wrong if I adopted what they termed the 'spider web' network For practical considerations none of the devices will be more than 120cm away from the 'master' RS485 connection So should I favour one design philosophy over the other? Les

I re-installed the Arduino IDE and now it compiles fine; I have done registry scans and virus scans etc to check but nothing comes up as being screwy. Looks like I will have to keep an eye on that, maybe do a pre-emptive periodic reinstall to make sure that it doesn't have issues. However before re-installing the IDE I tried copying the sketch to a USB stick and opening it on another laptop and a message came up saying that the sketch was not able to open. Strange Les

Yet another one today Take a look at these two sketches for the glare-shield lights and switches. The first one give a bunch of errors during compiling, and the second works just fine. Can anyone see what the difference is? Non-working sketch #define DCSBIOS_IRQ_SERIAL //#define DCSBIOS_RS485_SLAVE 61 //#define TXENABLE_PIN 2 #include "DcsBios.h" #include <Arduino.h> DcsBios::LED apuFire(0x10da, 0x0010, 13); DcsBios::Switch2Pos extStoresJettison("EXT_STORES_JETTISON", 11); DcsBios::Switch2Pos fireApuPull("FIRE_APU_PULL", 14); DcsBios::Switch3Pos fireExtDisch("FIRE_EXT_DISCH", 19, 18); DcsBios::Switch2Pos fireLengPull("FIRE_LENG_PULL", 17); DcsBios::Switch2Pos fireRengPull("FIRE_RENG_PULL", 15); DcsBios::LED lEngFire(0x10da, 0x0008, 16); DcsBios::LED rEngFire(0x10da, 0x0020, 12); DcsBios::LED canopyUnlocked(0x10da, 0x0004, 3); DcsBios::LED gunReady(0x1026, 0x8000, 10); DcsBios::LED markerBeacon(0x10da, 0x0002, 4); DcsBios::LED nosewheelSteering(0x10da, 0x0001, 9); void setup(void) { DcsBios::setup(); } void loop() { DcsBios::loop(); } and the working sketch #define DCSBIOS_IRQ_SERIAL //#define DCSBIOS_RS485_SLAVE 61 //#define TXENABLE_PIN 2 #include "DcsBios.h" #include <Arduino.h> DcsBios::LED apuFire(0x10da, 0x0010, 13); DcsBios::Switch2Pos extStoresJettison("EXT_STORES_JETTISON", 11); DcsBios::Switch2Pos fireApuPull("FIRE_APU_PULL", 14); DcsBios::Switch3Pos fireExtDisch("FIRE_EXT_DISCH", 19, 18); DcsBios::Switch2Pos fireLengPull("FIRE_LENG_PULL", 17); DcsBios::Switch2Pos fireRengPull("FIRE_RENG_PULL", 15); DcsBios::LED lEngFire(0x10da, 0x0008, 16); DcsBios::LED rEngFire(0x10da, 0x0020, 12); DcsBios::LED canopyUnlocked(0x10da, 0x0004, 3); DcsBios::LED gunReady(0x1026, 0x8000, 10); DcsBios::LED markerBeacon(0x10da, 0x0002, 4); DcsBios::LED nosewheelSteering(0x10da, 0x0001, 9); void setup(void) { DcsBios::setup(); } void loop() { DcsBios::loop(); } There must be something in there that is different, and if someone could point it out I would be grateful Cheers Les