Cheap solution for CDU Display

Alright, thanks for taking a look at it.

 

P.S. Free CDU's for anyone making a contribution, including the original poster of course.

Can you post a better picture of the CDU so I can make contribution so I can get a free CDU with my free F18 grip?

Can you post a better picture of the CDU so I can make contribution so I can get a free CDU with my free F18 grip?

You can always pm me your sarcastic remarks Deadman. There's really no reason for you to mock our efforts to create a free program for the community to run their CDU's. I could understand it when I was posting renders, but these are actual working prototypes. Prototypes manufactured on automated computer controlled machinery I designed and built myself.

I cannot post a better picture because this is the very first unit out of the manufacturing line and has some errors. I will however post many more pictures of the next one, and much better pictures of the final version. Unless you have code writing skills I don't see a reason to offer you a free unit. Or did you mean you can offer me dimensions? Dimensions that are available on multiple places online? I know you are working on your own CDU, along with the rest of the simpit products, and I'm beating you to it. But instead of mocking me you should focus your energy on actual manufacturing... you know, like me.

Deadman I told to you to be more specific when writting. Your text can be interpreted as sarcastic and condesending which I am sure wasn't your intention.

Oh well now you just lost the possibility of a free CDU. Look on the bright side though. You still get a free F-18 grip from hegykc.

Too bad I do not have any coding skills. I will just have to buy mine from hegykc or LynxDK

Cheers

Hans

Hey, all.

Sorry for beeing silent, had a lot of work (regarding real life) to do and so I missed your progress here. Also cut me slack if I ain't understand your partially sarcastic or funny conversation.

Meanwhile it looks like I bet on the wrong horse with my hardware...

(Link to my screen - if somebody is interested)

It looks to me, you all gambling with adafruit, while I have an Eastrising board and screen.

While the with the screen (buydisplay.com) given examples - even modified to check different fonts - run fine, I have serious problems to bring robinmli's sketch to life, means: to transscribe his sketch into UTFT-"language".

Also wrote the Author of RinkyDinkelectronics.com as an answer to my question "... how to design a 20x32-font..."

I am afraid UTFT only supports fonts with characters which have a width that is dividable by 8 (as in 8, 16, 24 and so on).

The height can be whatever you need as long as all characters in the font have the same height.

20x32 pixel characters is not possible without a complete re-write of the entire font system in UTFT.

 

Regards

Henning Karlsen

I think about to open a new thread for not further contaminate this one (sorry, robinmli) cause I think my problems are complete different to these are discussed here :)

@hegykc: What kind of sophisticated software do you use for calculating hex-matrixes? Asking just for the case, I have to go the whole way from start. :(

@hegykc: What kind of sophisticated software do you use for calculating hex-matrixes? Asking just for the case, I have to go the whole way from start. :(

Using The GIMP, you can export a monochrome image in .xbm format. That's basically a text file containing a C array with the image data. That's what I used to make the font files for my altimeter demo.

For the UTFT library, there is also an online conversion tool.

Thank you, Ian.

This is now a complete new discipline and I'll have to chew on for a while :)

So many building sites and too little time... :book:

Hegykc I understand that English is not your first language and the difficulty translating it has cause you a lot of misunderstandings. So how you could get that i was being sarcastic or mocking your version of an A-10 C CDU by asking a question , is well interesting.

You did not specify what type of contribution one could make to get their free item "P.S. Free CDU's for anyone making a contribution, including the original poster of course. "

As far as I know I can still expect a free grip but then again you do make conflicting statements all of the time. Such as this complete false statement

"I know you are working on your own CDU, along with the rest of the simpit products "

I have never offered to make a CDU. I don't intend to duplicate mine yes it is out of a simulator. The cost would be close to other that make them in the $1000.00 range and with you all ways stating that you will make every thing dirt cheep well it is not worth my time or an investment in equipment to make 1to 1 replicas of the CDU with the small number of cockpit builders making A-10Cs.

At this time do to a complete lack of interest in the A-10 pit I have not offered any parts in the last 6 months.

What do you mean by prototypes ?

You can always pm me your sarcastic remarks Deadman. There's really no reason for you to mock our efforts to create a free program for the community to run their CDU's. I could understand it when I was posting renders, but these are actual working prototypes. Prototypes manufactured on automated computer controlled machinery I designed and built myself.

 

I cannot post a better picture because this is the very first unit out of the manufacturing line and has some errors. I will however post many more pictures of the next one, and much better pictures of the final version. Unless you have code writing skills I don't see a reason to offer you a free unit. Or did you mean you can offer me dimensions? Dimensions that are available on multiple places online? I know you are working on your own CDU, along with the rest of the simpit products, and I'm beating you to it. But instead of mocking me you should focus your energy on actual manufacturing... you know, like me.

Well it must all be in my mind then. Only strange thing is I have the cad files of the products I was trying to replicate for you to make, like the MFCD's, glare shield etc. You worked on custom cut lcd screens, replica rubber keypad for the cdu... should I continue?? My engine instruments being the one that got you mad because I designed and offered to sell them on my own, "behind your back". Those are your own words by the way. And all this time you're weren't actually trying to manufacture anything. Well, silly me.

Posting in my other thread that my projects are "SWAG (scientific wild-ass guess )" and when I call you out on it, I'm misunderstanding you? My English might not be perfect, but I can tell the difference between someone looking to contribute logical and meaningful content, and someone trying to stir things up. This thread is about fixing the cdu code. So when I ask for contributions, you don't have to look up the dictionary, or play a lawyer with my words, just use common sense. We need code.

In the last 3 years I haven't once posted on any of your projects, let alone something in mean spirit. I would ask you to give me the same courtesy back. Just ignore me and all my projects.

I'm not one to get into an argument, but Deadman, (and knowing the past issues that you've had with Hegykc) to me your response did sound sarcastic and mocking (and English is my first language) to the degree that you were assuming you'd be expecting a cdu module along with your F-18 stick. If you'd have shown your interest with the clarity of your own potential contribution you would probably have received a more appropriate response.

Anyways, I followed you for ages on your A-10C pit, how come you've lost interest in it? You even bought a real front end. Maybe it's all the modules that are coming out for dcs and you're deciding which other aircraft front ends you can buy?

Well it must all be in my mind then. Only strange thing is I have the cad files of the products I was trying to replicate for you to make, like the MFCD's, glare shield etc. You worked on custom cut lcd screens, replica rubber keypad for the cdu... should I continue?? My engine instruments being the one that got you mad because I designed and offered to sell them on my own, "behind your back". Those are your own words by the way. And all this time you're weren't actually trying to manufacture anything. Well, silly me.

 

Posting in my other thread that my projects are "SWAG (scientific wild-ass guess )" and when I call you out on it, I'm misunderstanding you? My English might not be perfect, but I can tell the difference between someone looking to contribute logical and meaningful content, and someone trying to stir things up. This thread is about fixing the cdu code. So when I ask for contributions, you don't have to look up the dictionary, or play a lawyer with my words, just use common sense. We need code.

 

In the last 3 years I haven't once posted on any of your projects, let alone something in mean spirit. I would ask you to give me the same courtesy back. Just ignore me and all my projects.

You speak english amazingly well, I can't even tell its not your first language. :thumbup:

Once again your going off in to another discussion bring up your side of of past things instead of solving the issued at hand. I stated your *CDU* had SWAG. As far as i remember you are using Lar's panel designs witch he gave up for free witch are based on his calculations (SWAG). You have gone ballistic and imply accurate distentions are all over the net prove it post it or its all bs like most or you yap yap yap.

Well it must all be in my mind then. Only strange thing is I have the cad files of the products I was trying to replicate for you to make, like the MFCD's, glare shield etc. You worked on custom cut lcd screens, replica rubber keypad for the cdu... should I continue?? My engine instruments being the one that got you mad because I designed and offered to sell them on my own, "behind your back". Those are your own words by the way. And all this time you're weren't actually trying to manufacture anything. Well, silly me.

 

Posting in my other thread that my projects are "SWAG (scientific wild-ass guess )" and when I call you out on it, I'm misunderstanding you? My English might not be perfect, but I can tell the difference between someone looking to contribute logical and meaningful content, and someone trying to stir things up. This thread is about fixing the cdu code. So when I ask for contributions, you don't have to look up the dictionary, or play a lawyer with my words, just use common sense. We need code.

 

In the last 3 years I haven't once posted on any of your projects, let alone something in mean spirit. I would ask you to give me the same courtesy back. Just ignore me and all my projects.

Why is it the Scotts say I am not getting in to some thing and then. There ya go jumping in feet first?

your question was? "how come I have lost interest in it" I have not i have just lost the interest in posting about it here.

I'm not one to get into an argument, but Deadman, (and knowing the past issues that you've had with Hegykc) to me your response did sound sarcastic and mocking (and English is my first language) to the degree that you were assuming you'd be expecting a cdu module along with your F-18 stick. If you'd have shown your interest with the clarity of your own potential contribution you would probably have received a more appropriate response.

Anyways, I followed you for ages on your A-10C pit, how come you've lost interest in it? You even bought a real front end. Maybe it's all the modules that are coming out for dcs and you're deciding which other aircraft front ends you can buy?

One - I'm not Scottish, I just live here and 2, I don't believe that what you're commenting on is a Scottish vocal tradition!!! lol. At least not that I've heard.

So what on earth does this mean if it's not lost interest? - "At this time do to a complete lack of interest in the A-10 pit I have not offered any parts in the last 6 months."

It's a competetive world out there. If you don't do it - someone else will, and good luck to them.

Dear Community.

After fighting some beginner's issues - to be honest: my learning curve was some kind of smooth - I brought that thing into business. After I've learned some of the basics, it was almost a plug-and-play matter :)

I use an UNO with a 3.5"-TFT, driven by an ILI9341.

The code is what RobinMLi gave to us. Thank you very much. Without your work I sat still here, staring at a white screen on my knees ;)

It looks really good, even the refresh rates are acceptable (clearly less than half a second).

So I wanted to put some whip cream on top of the cake:

Because my TFT has no interface for dimming the backlight (resp. brightness of the font) and it could be nice to change that to personal taste or to adopt environmental conditions.

Althow the DIM/BRT-Rocker has no inSim-Function, DCS-BIOS reads and streams this if there is something happened.

I use this to change the color-value of the written lines.

It works well, but with a little problem: Just altered lines are shown with the new color - as intended.

Is there a single command, that tells DCS-BIOS to re-read (or re-send, depends on the aspect) all 24 lines, no matter if them changed or not? This command should be set each time, the DIM/BRT-Rocker is triggered.

I know: It will take a few (felt 200 to 400) milliseconds to refresh all lines on one single rush. But how often you will change screen's brightness?

So I don't know if it's worth to cut the TFT-panel to feed the backlite-LEDs with a PWM. This would be qiete more elegant. Of course.

This work could be dangerous to the panel... and if a few lines of code can do almost the same job...

Here is my code. Put your attention to lines 20 to 44.

And there is no keypad yet. ATM I do not know how I'll implement that. Maybe I convert the whole thing to RS485 and couple a second UNO or a NANO for feeding the keypad. So they can share the load.

I have to wait, what I'll dream of that matter :)

/*
 Tell DCS-BIOS to use a serial connection and use the default Arduino Serial
 library. This will work on the vast majority of Arduino-compatible boards,
 but you can get corrupted data if you have too many or too slow outputs
 (e.g. when you have multiple character displays), because the receive
 buffer can fill up if the sketch spends too much time updating them.
 
 If you can, use the IRQ Serial connection instead.
*/
#define DCSBIOS_IRQ_SERIAL

#include "DcsBios.h"
#include <Adafruit_GFX.h>
#include <UTFTGLUE.h>
int i = 0; // just for testing/debugging
int j = 0; // just for testing/debugging

UTFTGLUE myGLCD(0x9341,A2,A1,A3,A4,A0);

// set different brightness
// bright1 = 0x01E0; // darkest
// bright2 = 0x02E0; // values just for reference
// bright3 = 0x03E0; // so you know what my intention is
// bright4 = 0x04E0;
// bright5 = 0x05E0;
// bright6 = 0x06E0;
// bright7 = 0x07E0; //brightest
int cduBrt = 0x04E0; // start value
void onCduBrtChange(unsigned int newValue) { // newValue range 0 (left/down),1 (neutral),2 (right/up)
   if (newValue == 0){ // DIM/BRT-Rocker left
	cduBrt = cduBrt - 0x0100;
};
if (newValue == 2){ // DIM/BRT-Rocker right
	cduBrt = cduBrt + 0x0100;
};
if (cduBrt > 0x07E0){
	cduBrt = 0x07E0;		
};
if (cduBrt < 0x01E0){
	cduBrt = 0x01E0;		
};
};
DcsBios::IntegerBuffer cduBrtBuffer(0x10fa, 0x0003, 0, onCduBrtChange);
// problem: just altered lines are drawn with new brightness

void printChar(int row, int col, unsigned char c) {
 int16_t x = 13 + col * 19;
 int16_t y = row * 32 + 6;
 myGLCD.drawChar(x, y, c, cduBrt, 0x0, 3); //0x07E0
} 

/* paste code snippets from the reference documentation here */
void onCduLine0Change(char* newValue) {
 for(int i = 0; i < 24; i++){
   printChar(0, i, newValue[i]);
 }
}
DcsBios::StringBuffer<24> cduLine0Buffer(0x11c0, onCduLine0Change);

void onCduLine1Change(char* newValue) {
 for(int i = 0; i < 24; i++){
   printChar(1, i, newValue[i]);
 }
}
DcsBios::StringBuffer<24> cduLine1Buffer(0x11d8, onCduLine1Change);

void onCduLine2Change(char* newValue) {
 for(int i = 0; i < 24; i++){
   printChar(2, i, newValue[i]);
 }
}
DcsBios::StringBuffer<24> cduLine2Buffer(0x11f0, onCduLine2Change);

void onCduLine3Change(char* newValue) {
 for(int i = 0; i < 24; i++){
   printChar(3, i, newValue[i]);
 }
}
DcsBios::StringBuffer<24> cduLine3Buffer(0x1208, onCduLine3Change);

void onCduLine4Change(char* newValue) {
 for(int i = 0; i < 24; i++){
   printChar(4, i, newValue[i]);
 }
}
DcsBios::StringBuffer<24> cduLine4Buffer(0x1220, onCduLine4Change);

void onCduLine5Change(char* newValue) {
 for(int i = 0; i < 24; i++){
   printChar(5, i, newValue[i]);
 }
}
DcsBios::StringBuffer<24> cduLine5Buffer(0x1238, onCduLine5Change);

void onCduLine6Change(char* newValue) {
 for(int i = 0; i < 24; i++){
   printChar(6, i, newValue[i]);
 }
}
DcsBios::StringBuffer<24> cduLine6Buffer(0x1250, onCduLine6Change);

void onCduLine7Change(char* newValue) {
 for(int i = 0; i < 24; i++){
   printChar(7, i, newValue[i]);
 }
}
DcsBios::StringBuffer<24> cduLine7Buffer(0x1268, onCduLine7Change);

void onCduLine8Change(char* newValue) {
 for(int i = 0; i < 24; i++){
   printChar(8, i, newValue[i]);
 }
}
DcsBios::StringBuffer<24> cduLine8Buffer(0x1280, onCduLine8Change);

void onCduLine9Change(char* newValue) {
 for(int i = 0; i < 24; i++){
   printChar(9, i, newValue[i]);
 }
}
DcsBios::StringBuffer<24> cduLine9Buffer(0x1298, onCduLine9Change);

void setup() {
 DcsBios::setup();

 // Setup the LCD
 myGLCD.InitLCD();
 myGLCD.clrScr();
 myGLCD.setTextSize(3);
 myGLCD.setColor(55, 0, 0); // seems to have no effect
}

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

Dear Community.

After fighting some beginner's issues - to be honest: my learning curve was some kind of smooth - I brought that thing into business. After I've learned some of the basics, it was almost a plug-and-play matter :)

 

I use an UNO with a 3.5"-TFT, driven by an ILI9341.

The code is what RobinMLi gave to us. Thank you very much. Without your work I sat still here, staring at a white screen on my knees ;)

 

It looks really good, even the refresh rates are acceptable (clearly less than half a second).

And I bet they could still be improved a bit for the common case where only a single character changes (cursor blinking, editing the scratchpad). The current code uses a StringBuffer per 24-character line of text, so when a single character changes, the whole line is rewritten.

For a graphic CDU display, it would be a good idea to make a variant of the StringBuffer class that tracks changes on a per-character basis instead.

 

So I wanted to put some whip cream on top of the cake:

Because my TFT has no interface for dimming the backlight (resp. brightness of the font)

According to the ILI9341 datasheet, the controller supports a "set backlight brightness" command. But if the manufacturer of the shield hasn't wired the backlight control up to the ILI9341 chip, that probably won't work.

There are a few more backlight-related commands that seem to influence the gamma correction or something, but I have no idea what they do.

Is there a single command, that tells DCS-BIOS to re-read (or re-send, depends on the aspect) all 24 lines, no matter if them changed or not? This command should be set each time, the DIM/BRT-Rocker is triggered.

You can call a StringBuffer's getData() method at any time to get the buffered data (e.g. to get line 0, use "cduLine0Buffer.getData()").

Thank you Ian. I'll examine that. As usual, that'll take me a while (basically, I have no idea, what I do here :) )

Meanwhile I encountered some small blemish inside the modified font. Sorry, RobinMLi. This will not substract anything of your great work!

I was able to fix that thanks to Ians amazing hint to export bitmaps as *.xbm . Strange side effect: Gimp-Export mirrors the hex code!

The font looks now exactly like that inside the sim.

Simply re-rename it to glcdfont.c and copy it to your Adafruit_GFX_Library directory. Make a backup before!!!

If there is still a mismatch: Just let me know. I'm now quiet familiar to edit that :)

glcdfont.c.txt

Alright. moving forward :)

I'll have something to share soon too:

This was the first variation, now it's a backup. The new one has only one i2c chip and matrix for the keyboard. It's a fully developed and ready-to-order schematic, not just a render:

This looks really amazing.

How do you want to connect this beauty to DCS?

I ran here into a problem. I still haven't found a convincing solution to bring TFT and keymap together and link this to DCS by DCS-BIOS/RS485.

MEGA2560 hold enough I/Os to connect everything, but it is too slow to refresh the screen quick enough. Have checked this: Is really, really slow.

If I use an UNO for the TFT, I'm running out of pins. Even if I plan to link a second AVR (UNO or NANO) by I2C or RS485. My TFT uses all Analog INs (no idea exactly for what for) so SDA and SCL are occupied: No I2C available even if these pins are still free.

If I link both AVRs inside the device (CDU) by RS485... I do not know if TX and RX are still "free". At least one digital Pin for TXenable should be available if I set SD-Card aside (shouldn' be a problem).

But even if TX/RX are free to use: my programmer's skills are weak. Too weak for this.

Workaround (from my noob's position) would be, to connect both boards independent by USB: Unsatisfying!

Is there already someone researching this matter and - maybe - found a solution? And - best case - is willing to share this with us?

PS: Didn't went for the "Contrast Issue" yet. Lack of time. :(

I would give the teensy 3.6 a look. It's small, has a boatload of io and has plenty of horsepower. It should be able to handle all the buttons and the display with ease. I haven't used the 3.6 but I have used other teensys and they are phenomenal compared to thier avr counterparts.

I would give the teensy 3.6 a look. It's small, has a boatload of io and has plenty of horsepower. It should be able to handle all the buttons and the display with ease. I haven't used the 3.6 but I have used other teensys and they are phenomenal compared to thier avr counterparts.

on this recommendation I've just bought one to test, I hope you're right Mr!

Progress linking by RS485, encountered some problems

Dear Friends.

Meanwhile I managed to connect the display by RS485. But there is still some work to do.

While the display worked without any issues if it connected by USB, it shows - connected by RS485 - a very unattended and unwanted behavior.

I attached some photographs of used hardware and some "screenshots". I made also a short

Sorry for bad quality. I don't go for an Oscar with that.

In the first take you can see the screen is built very quick (quick enough, I think). The next takes show how the trouble cumulates.

At the videos is a connected USB to the UNO to be seen. This is just for powering the UNO/Screen aggregat. The onboard AMS1117 on the UNO is unable to manage this. Next step is to improve power-management to feed it all by the RS485-bus. No problem at all.

Also I attached a copy of the used sketch. Ignore the commented lines. I will work on them, if this main issue is solved.

The unwanted characters appear on the screen just if DCS is running. If DCS is paused or stopped, latest picture stays on the screen until it is unpowered. No matter how long it runs: No further new characters appear on the screen.

Most juicy picture is the last one: This happend a few milliseconds before stopping DCS. As you'll see, there are almost all characters are shown as them listed in the ASCII-table. Maybe this gives a hint to someone who knows about serial-communication.

During the test the screen-device has been the only slave device connected to the RS485-Master. It makes no difference, if I link other slaves to the bus.

I assume some kind of interference between RS485's and Adafruit's libraries.

I have no idea, where I should start to debug this.

By reason it works by DCSBIOS_IRQ_SERIAL (USB) faultless, I assume a problem with RS485.

Is it to slow?

I have a loony thought: Is it possible to filter data which sent by the RS485-master? It looks like, the device is receiving data and has no idea what to do with...

DCS_CDU_DISPLAY_RS485.ino.txt

Dear Friends.

Meanwhile I managed to connect the display by RS485. But there is still some work to do.

 

While the display worked without any issues if it connected by USB, it shows - connected by RS485 - a very unattended and unwanted behavior.

 

I attached some photographs of used hardware and some "screenshots". I made also a short

. (hope it works, it is my first playlist).

Sorry for bad quality. I don't go for an Oscar with that.

In the first take you can see the screen is built very quick (quick enough, I think). The next takes show how the trouble cumulates.

At the videos is a connected USB to the UNO to be seen. This is just for powering the UNO/Screen aggregat. The onboard AMS1117 on the UNO is unable to manage this. Next step is to improve power-management to feed it all by the RS485-bus. No problem at all.

 

Also I attached a copy of the used sketch. Ignore the commented lines. I will work on them, if this main issue is solved.

 

The unwanted characters appear on the screen just if DCS is running. If DCS is paused or stopped, latest picture stays on the screen until it is unpowered. No matter how long it runs: No further new characters appear on the screen.

Most juicy picture is the last one: This happend a few milliseconds before stopping DCS. As you'll see, there are almost all characters are shown as them listed in the ASCII-table. Maybe this gives a hint to someone who knows about serial-communication.

 

During the test the screen-device has been the only slave device connected to the RS485-Master. It makes no difference, if I link other slaves to the bus.

 

I assume some kind of interference between RS485's and Adafruit's libraries.

I have no idea, where I should start to debug this.

 

By reason it works by DCSBIOS_IRQ_SERIAL (USB) faultless, I assume a problem with RS485.

Is it to slow?

I have a loony thought: Is it possible to filter data which sent by the RS485-master? It looks like, the device is receiving data and has no idea what to do with...

Did you ever sort this issue with the cdu via rs485? I'm having the exact issue.

Now I'm some confused. Tapatalk seems to be a little bit slow. (my last post isn't arrived here yet)

PS (edit): Found out, I'm too dumb to divide a common post from a PM at Tapatalk. So I copy the original Text out of the PM here. So can everyone can see the context:

Did you ever sort the cdu display issue via rs485? I'm having the exact issue from your post with weird characters displaying at random.

 

Mine works via serial but mine freaks out like in your YouTube videos.

Hi.

No. We didn't found neither a solution nor the source of this misbehave.

My CDU -- even it's inactive for months now -- works at some what hybrid mode: keys and backlight are driven by RS485 while the screen works on a separate UNO by serial.

 

So there is still a chance to earn the Nobel price by solving this phenomena.

 

Cheers

Tekkx

 

Gesendet von meinem TA-1020 mit Tapatalk

 

 

Yeah I thought so, didn't think it was a circut issue with the max chips. I had a feeling we would have to drive the cdu display via serial. Not a bid deal but when I was having the same issue and read your post I had to ask. Thank you sir!

 

I played with the sketch a lot and couldn't figure it out. The interface or character bleed may just no jive with a 485 net. May have to hit the arduino boards and ask around. It may need a custom circuit.

@Tulsa-A10: I think, it's a DCS-BIOS-specific RS485-issue.

DCS-BIOS sends just altered data along the bus. So any kind of disruption or jamming (or what-ever) has enough time to change screen's content. This do not solve the mystery, because - at my knowledge this is never observed and reported before - states of LEDs and switches are not affected.

Where those strange values - showed on the screen - come from... this is a little bit spooky. Meanwhile I tried several methods of shielding with absolutely no effect.

The only solution - at the actual design (Sorry Ian. This is NOT a critism of your amazing work!) - could be to send the whole screen's content every few seconds. But this potentially block the bus and prevent other data's smooth flow.

Conclusion: (just at my state of knowledge!) DCS-BIOS with RS-485 isn't applicative to feed screens continuously with data.

Now I'm some confused. Tapatalk seems to be a little bit slow. (my last post isn't arrived here yet)

PS (edit): Found out, I'm too dumb to divide a common post from a PM at Tapatalk. So I copy the original Text out of the PM here. So can everyone can see the context:

 

 

@Tulsa-A10: I think, it's a DCS-BIOS-specific RS485-issue.

 

DCS-BIOS sends just altered data along the bus. So any kind of disruption or jamming (or what-ever) has enough time to change screen's content. This do not solve the mystery, because - at my knowledge this is never observed and reported before - states of LEDs and switches are not affected.

Where those strange values - showed on the screen - come from... this is a little bit spooky. Meanwhile I tried several methods of shielding with absolutely no effect.

The only solution - at the actual design (Sorry Ian. This is NOT a critism of your amazing work!) - could be to send the whole screen's content every few seconds. But this potentially block the bus and prevent other data's smooth flow.

 

Conclusion: (just at my state of knowledge!) DCS-BIOS with RS-485 isn't applicative to feed screens continuously with data.

Thank you for the feedback. I had a feeling you'd say that. Not a big deal, I'll just use screens via serial for now. My favorite characters are the sad faces.. they frown and confirm your screen isn't going to work.. haha

I have ordered some of these amazing new NANO every.

In China. So they will run a while.

If these arrived, I'll do a test with that. Everys have a faster CPU... It's a small chance, but a chance.

Stay tuned.

Gesendet von meinem TA-1020 mit Tapatalk