TFT LCD screens and DCS Bios

At the risk of sounding greedy (after all, look at how much DCS Bios gives us already...) has anyone experimented with using those 3.5 and 5 inch TFT LCD screens for displaying info, or better still replicating the more difficult gauges?

I have one of the 3.5 inch screens, which came - as a lot of things did - with an Arduino starter kit I bought years ago for my sons to try to get them interested. Of course, I couldn't compete with Call of Duty or Grand Theft Auto, and so they sat on the shelf until I discovered DCS Bios and started playing around with it myself and now thanks to you guys and DCS bios I actually have stuff working and even starting to look good.

But there are some bits that would benefit from having a good LCD screen - the attitude indicator is a great example, Helios does it but comes at the cost of having to set up multiple monitors which when they are different sizes does end up complicating issues. A nit-pick to be sure, but the TFT LCD screen is super neat, and the idea of using it to display a gauge appeals.

Of course, brain dead Les here spent an hour trying to work out the wiring before realising it plugs straight on to the Uno board that came with the kit.

So, has anyone tried using these?

Cheers

Les

Disregard. Didn't read the question properly

Those examples are "only" displaying text which is reasonably easy with a combination of dcs--bios and the libraries that usually come with the LCD screens.

However displaying a gauge like the attitude indicator is a different story because it means taking the raw output from dcs-bios (roll, pitch) and using that to determine how to display a graphical image.

Now this is processing that is already done inside Helios so it would be an interesting project to look at the helios source code for the attitude indicator (for a start) and see how hard it would be to convert it to arduino code.

edit: I've downloaded the helios source for inspiration and I just so happen to have a spare LCD screen with aurdino interface that I bought for my UFC but it doesn't fit, so I guess I know what I'm doing tonight!

Ah ups. Misread the question. Sorry. Disregard above. Works only for CDU

Cheers

Hans

No need to apologise, still like that CDU as well!

Cheers

Les

Are you able to provide a link of the LCD screen you're talking about?

Most of the LCD displays i've seen meant for arduinos are very simplistic.

I would think that a raspberry pi would be a better fit for this situation, but I could be wrong. I believe raspberry pis can render opengl now so technically if it made a socket connection to the server running on your pc, i'd think that you can just send the altitude data and a program can render the graphics to a lcd connected to the raspberry pi via opengl.

Sure, this one looks identical to the one I have

https://www.ebay.com/itm/TFT-LCD-Display-3-5-Touch-Screen-Module-for-Arduino-R3-Board-Plug-and-Play/183758102938?ssPageName=STRK%3AMEBIDX%3AIT&_trksid=p2060353.m2749.l2649

Cheers

Les

Sure, this one looks identical to the one I have

 

https://www.ebay.com/itm/TFT-LCD-Display-3-5-Touch-Screen-Module-for-Arduino-R3-Board-Plug-and-Play/183758102938?ssPageName=STRK%3AMEBIDX%3AIT&_trksid=p2060353.m2749.l2649

 

Cheers

 

Les

I ordered one of these online and was going to mess with it when it comes in. I'll let you know what I find!

By the way, could you let me know which aircraft attitude indicators you were going to look at specifically so I could mess around with them when it comes in?

Just an update - I ended up going with

https://www.amazon.com/gp/product/B01EUVJYME/ref=ppx_yo_dt_b_asin_title_o01_s00?ie=UTF8&psc=1

and did some basic testing with the Arduino UNO.

It takes 217ms to just refresh a solid color on the screen with nothing else. I don't think it would be advisable to use a TFTLCD screen + arduino for attitude due to the low update speed. It just doesn't seem appropriate.

I am getting in a raspberry pi + lcd for that later this week and was going to test with that when it comes in.

I came to the same conclusion after playing around on the weekend. No way you'd get a good refresh rate. Better off just using an LCD with HDMI input and running helios. That way you could get all the analog/standby gauges on one (correctly sized) panel.

Thanks for looking into this guys, and great feedback too. The raspberry pi option sounds interesting too, looking forward to what comes out of this

Cheers

Les

Just an update on the raspberry pi.

There is good news and bad news.

The good news is the raspberry pi supports opengl.

The bad news is the latest version that the raspberry pi 3 model that i'm using supports is opengl 2.1 which is very old school opengl.

Regardless, i'm currently learning how opengl 2.1 works so I can play around with this.

Had some issues getting opengl projects to compile, but got it figured out and currently i've got a rotating blue rectangle on a 5" lcd connected to the pi. Not much so far, but some progress is still progress.

Great progress, I wish I was able to help but were it not for guys like you we'd ll be looking at a printed photo that looks like the instruments and pretending!

Cheers

Les

Just an update.

Built a mockup texture for the attitude indicator. (I suck at art, but trying.)

Restructured the opengl program and got it set up where I can load in textures, loaded in the mockup texture. Still need to add the horizontal lines for pitch and remove the bottom lines for banking that were left over.

One issue i've noticed with the 5" screen i'm using is it kind of needs to be viewed at a specific angle. At harsh angles, the screen is not usable as seen in the next pic.

That's amazing! If you need bitmaps or jpg files making to use, let me know, I'm more than happy to help seeing as you are doing all the difficult work

Cheers

Les

That's amazing! If you need bitmaps or jpg files making to use, let me know, I'm more than happy to help seeing as you are doing all the difficult work

 

Cheers

 

Les

That sounds great. I have a photoshop template, so i'm thinking that once this is all set up people should be able to design how they want theirs to look without too much trouble.

Been making some good progress. Here is where we're at now. The camera does a really bad job at picking up this LCD screen for some reason. There is some screen tearing, but I will work on figuring out a fix for that later.

Here is a video showing what it will look like at certain pitch/bank angles. I wasn't able to embed the video on here for some reason. Still need to add in the horizontal pitch ticks for 25-90 degrees.

Next going to start working on the programs for communicating between DCS World->Computer->Raspberry PI.

Sorry for the delayed response, family stuff got in the way!

That looks really promising, was it using in gata data or a separate canned data stream?

Cheers

Sorry for the delayed response, family stuff got in the way!

 

That looks really promising, was it using in gata data or a separate canned data stream?

 

Cheers

I've been a bit busy also haven't been able to work too much on it.

I was considering having it set up like the following...

Have Master control server running on PC with DCS World.

Have raspberry pi + other controls in the future connect to master control server.

Have DCS World connect to master control server via Export.lua and have it send updates accordingly to the master server.

Have master server dispatch the updates to the controls that the given update is related to.

Was just going to use tcp sockets for the communication between the three.

Just want to chime in that the new Raspberry Pi 4 supports OpenGL ES 3, might be relevant for the work youre doing Pindrought

I have been trying to do some attempts on this matter as well. The Arduino (Nano) does indeed seem much too slow to yield the desired update frequency, though I am wondering if the Teensy (4.0) would be able to deliver the necessary processing capabilities. Alternatively I also got my Nextion screen, which I hope to be able to employ for this. This features an integrated graphics processor so it would need to rely on data input, which could be handled via the Arduino.

Any thoughts / recommendations on this?

Greetings

I have one  of those 3.5" screens for the CDU and works fantastic with help from this website with the code, ( CDU not built yet but in progress )

I have upgraded to a 5" TFT but struggling Again with the code

any help greatly appreciated

Existing code used for the 3.5" works perfect ( may be of use to someone )

#include <Adafruit_GFX.h>
#include <Adafruit_GrayOLED.h>
#include <Adafruit_SPITFT.h>
#include <Adafruit_SPITFT_Macros.h>
#include <gfxfont.h>
#include <Adafruit_GrayOLED.h>
#include <Adafruit_SPITFT.h>
#include <Adafruit_SPITFT_Macros.h>
#include <gfxfont.h>

/*
  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>

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

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, 0x07E0, 0x0, 3);
} 

/* 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(0, 0, 255);
  myGLCD.drawRect(10, 0, 469, 319);
}

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

--------------------------------------------------

New code for the 5" TFT

Draws a rectangle as requested but no text displayed when connected to DCS  with DCS Bios connected and running

#include <Adafruit_GFX.h>
#include <Adafruit_GrayOLED.h>
#include <Adafruit_SPITFT.h>
#include <Adafruit_SPITFT_Macros.h>
#include <gfxfont.h>
#include <Adafruit_GrayOLED.h>
#include <Adafruit_SPITFT.h>
#include <Adafruit_SPITFT_Macros.h>
#include <gfxfont.h>
#include <UTFT.h>

/*
  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>

UTFT myGLCD(SSD1963_800480,38,39,40,41);

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, 0x07E0, 0x0, 3);
} 

/* 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();
  pinMode(8, OUTPUT);  //backlight 
  digitalWrite(8, HIGH);//on
  // Setup the LCD
  myGLCD.InitLCD();
  myGLCD.clrScr();
  //myGLCD.setTextSize(3);                                  
  myGLCD.setColor(0, 255, 0);                              //This bit works
  myGLCD.drawRect(10, 0, 790, 477);                  //
}

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

in what you pasted for not working:

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, 0x07E0, 0x0, 3);
} 

the // at the beginning of the line myGLDC.drawChar line makes it a comment, not code, so this printChar method doesn't actually *do* anything.

remove the // and it should work?  if that doesn't compile, presumably the library for the 5" has a different signature for printing text?

Can I ask where you bought the 5" TFT? I got one from Buydisplay but due to a locked in font issue it shows corrupted characters here and there.

Cheers

Les

Hi anyone got some code for 3.5" TFT  screens <that work>. for the F/A18? or anything  interesting that can be ported to them?

appreciated!Not a wizard at coding myself,soz any help would be appreciated!

Any suggestions for how to draw fixed indications, how to draw indications based on dcs bios input, and how to have the dcs bios input drive those indications?