BoboBear

Hi Jacks, I also used the same chips from AliExpress https://www.aliexpress.com/item/32548458025.html?spm=a2g0s.9042311.0.0.27424c4djdYXvp Yes, they're SMD so can be a little tricky. So I created PCBs and had JLCPCB make them for me. https://easyeda.com/editor#id=|dbb1be9385694980905935ddbbfc51a6|dc2825a1b9294ceaa06cb5d2e9779abe Some other useful info here:- https://guy.carpenter.id.au/gaugette/resources/

Oops! Good catch! (Corrected in original post, hopefully prevent confusion. Thanks) Glad it helped

Is that a typo? DcsBios::StringBuffer<4> tacanChannelBuffer(0x1162, onTacanChannelChange); Should be outside of onTacanChannelChange procedure Also, I would suggest moving the display.updateDisplay() call to just after DcsBios::loop(). That way if multiple things get updated in one DCSBios update you only write once to the i2c

I think you're missing a call to update the display in your loop() I don't have the Sparkfun display library, but it's probably something like:- display.writeDisplay(); Take a look at the example sketch with the library

I have a similar issue. I replied to your post over on the main DCS-BIOS over RS485 thread

I've been struggling with a similar problem for the last couple of days. It only seems to happen with quite complex instruments (for me Ka50 PVI800, lots of buttons, LEDs, 7 seg displays etc) Only occurs over RS485, not serial I think I've tracked it down to a slight issue in the Arduino lib, specifically DcsBiosNgRS485Slave.cpp.inc. (not DcsBiosNgRS485Master.cpp.inc thanks doubleup) case RX_WAIT_DATA: rxtx_len--; if (rx_datatype == RXDATA_DCSBIOS_EXPORT) { parser.processCharISR©; } if (rxtx_len == 0) { state = RX_WAIT_CHECKSUM; } The rx ISR has a section where a new byte is sent off to be processed. However, the ISR is reentrant, meaning that if a new byte is received before the previous one is processed, that too is added to the process queue. The problem is that when the end of the message occurs, and the various export stream listeners are busy updating, the CRC byte can be received. And because the checking for the end of message relies on processCharISR returning, so it can check the rxtx_len and set to state to RX_WAIT_CHECKSUM, (it hasn't yet, still busy), the CRC also gets sent off to processCharISR, and the end of message is missed. rxtx_len is now 255, so now the next 255 'random' bytes get added to the incoming stream, resulting in some very weird updates. The solution is to check and set the state correctly before processing the byte. ie swap the order of the 2 if statements in the RX_WAIT_DATA case. case RX_WAIT_DATA: rxtx_len--; if (rxtx_len == 0) { state = RX_WAIT_CHECKSUM; } if (rx_datatype == RXDATA_DCSBIOS_EXPORT) { parser.processCharISR©; } Now, when the checksum byte comes in, it's correctly handled, even if processCharISR and processChar haven't finished yet. This does the trick with RS485 for me. It's now rock solid. Perhaps try the above and see if it helps?

Great to hear that works for you. Thanks for sending the file. I suspect I need to add some checking that the settings file is valid for the current dcsBios json file. I'll try to add that this weekend so it doesn't catch people out in future

I've also been looking at using X27 type car instrument steppers. From what I've read, their step requirements are a little different and I'm not sure the normal H bridge stepsticks are the way to go. I found this website pretty helpful https://guy.carpenter.id.au/gaugette/resources/ And found the driver chips on AliExpress https://www.aliexpress.com/item/32548458025.html?spm=a2g0s.9042311.0.0.1fc14c4dN49EPU These seem to drive these steppers pretty well (and bonus of 1 chip drives 4 steppers)

Try deleting the dcsBiosDebugSettings.json file. (If I remember correctly, it's in your Documents folder on windows) (or better yet, copy it to a new name first. And send it me if that fixes the issue.)

Sorry for slow response, been away from forum a little while Not sure if you're still looking for this, but looks like the json files are all in separate plugin dirs now https://github.com/dcs-bios/module-spitfire-lfmkix

I had a look at the RS485 master issue. Seems that a master doesn't like a lot of data as soon as the serial port opens. So I've added a slight delay. It seems to work ok now on a RS485 master. (My master setup is quite minimal though) New version (1.2) added to GitHub with win64 exe and MacOSX App.

Hmm. I thought it should work with RS485 bus, but I have to admit, I haven't tested it. I'll take a look but it'll be the end of the week as I'm away from home at the moment.

Yep, should be fully independent of a DCS World install. Just need the aircraft .json file from the DCSBios doc folder. Report issues here or via PM. Either way is good. Regards, Bear

Hi Lex, Yes, it should send updates to steppers ok. The App supports the IntegerBuffer DCSBios type. You can set the new IntegerBuffer value (stepper position) via a slider, or can get the app to regularly increase/decrease the IntegerBuffer value. If you try it, let me know what you think. Regards, Bear

This is a small python app I've been working on to help me debug my pit instruments. It can send instrument updates, gauge positions, led states etc without having to start DCS. The user can select a DCSBios json definition files, and then choose which indicators to update over a serial port. App also shows the responses received from the hardware. Note. I've only been working on this a couple of weeks on and off. It's not well tested yet. So don't be surprised if you hit issues using it. Let me know what they are and I'll try to fix them. However, as it's proving useful to me, I'm releasing it now in case it helps someone else. https://github.com/tldBear/dcsBiosDebug/blob/master/README.md