Options for 7" LCD screens for dashboard

Status
Not open for further replies.

Talkiet

Well-known member
Help. I have got a LONG way into a project to build the following on a Teensy 3.5 for my race car...

- GPS Lap timer
- Tyre temperature monitor/logger
- Brake temperature monitor/logger
- Digital dash with data from ECU (canbus) and other sensors (like brake, oil pressure, fuel level) through direct analog inputs.

It's all working, and working well... Check this out.


BUT, and it's a huge but... I can't find a screen that works well.

I have a Nextion 7" screen on the car in the video above, and it's unreadable on track, even with the sun visor. Apart from that, the project creation, programming ease and update speed is all good.
I bought a 4D systems "Superbright" display and it's catastrophically unsuited. EVERY graphic element is read from a microSD card every time... That tachometer that is 720*82 pixels, updating at 10Hz? That takes over half the pixel bashing bandwidth BY ITSELF, and it's choppy to boot. It won't work.

"Sunlight readable displays" and "LCD for car dashboard" google results are hopelessly polluted with people thinking that putting a standard LCD in a car will work, and "Automotive LCD" gets me links, but nothing I could actually buy.

So here's the question...

Does anyone know of a legit sunlight readable option that I could drive from a Teensy? I am prepared to dediate a Teensy to JUST that task and send it commands via UART if required. I have tried a 20*4 large LCD display, and it was readable but I have need for more data to be displayed. a 128*64 LCD dot matrix is also too small. It needs to be at least a 5" (preferably 7") 800*480 display at least.

This is what my current display looks like in the garage...


I am considering going down the path of just building Bluetooth in and outputting everything as CAN data to use an external display (like any proper digital dash, or something like Realdash on a nice bright phone), but my preferred option is a dedicated colour sunlight readable display.

And no, I am not looking at it while racing in any great detail. I use it during warmup to check tyre and brake temps, on the straight to check engine temp and oil pressure, and immediately after the race to check engine state and temps. I will have a race mode with a sector time delta and idiot lights for "tyres too hot" or "engine gonna go boom". I have a row of ultrabright LEDs above the display for RPM and shift information.

I have spent quite some time looking and it's incredibly frustrating - not least because the Google results are so full of people sticking a tablet to their dashboard and claiming a digital dash!

Cheers - N
 
I suspect trying to get all of the pieces together will be a daunting task, and you are probably the first person to try it.

One thought might be get a Raspberry Pi to drive a sunlight readable HDMI display, and talk to the PI via normal serial (or bluetooth, etc.). Obviously there you need to program in both the Teensy and Pi environments.

I did recall that somebody did a Teensy -> VGA output, and some of the displays still have VGA inputs. Even if they don't have VGA inputs, you should be able to get VGA->Composite or VGA->HDMI converters. From my google searches, I see qix67 did the library and FrankB, Manu98, and StenfanS used it:

Because I was curious, I did notice these products in Amazon from stone-hmi.com that claims to have a serial UART based display, but it is kind of hard to determine the capabilities of this display:
 
indeed, a fire and go nextion vs a fire and acknowledge 4d display both have pros and cons, but i wouldnt prefer bluetooth over hard wiring for high speed data acquisition, due to lack of high baud rates and reliability.

you could get an SPI display (not sure if they make them sunlight readable) and draw what you need on it via code, if you do it all via software sketch, its more complex and time consuming.. for the nextion & 4d you use less mcu code but the displays already know what to do with the single line commands you send, so code is cleaner on mcu end, but your stuck with the display’s limitations as above. if you prefer to write 4dgl code in the serial environment, the 4d supports > 2Mbaud using raw registers, but you’ll need to draw the images from the host end, of course.
 
Thanks gents. I had considered something with an HDMI display - there's a lot more choice in those sort of displays but as you mention of course, there's now 2 full applications to develop on two separate platforms. Certainly do-able and it would be able to sit as a separate project with a clean interface between them, but I'd prefer a simple display.

I also happened upon the Stone HMI displays after posting and have sent a query on the price for the 5 and 7" models. They have their advanced series which claim up to 1000cd/m2 for the 7". It's a 3rd HMI format to learn but they don't take long to pick up, and the software side on the Teensy should be pretty easy to convert. The capabilities can't be less suited than the 4D. I note they have significant amounts of memory like the Nextion, not 32 KILOBYTES like the 4D, so I am reasonably confident that the gfx elements will be in fast memory while running, not drawn from the SD.

Cheers - N
 
the 32KB referred is the onboard flash for code storage, the Stone HMI uses a 2GB SD card for storage, upgradable to 4GB.
note, the SD slot on the 4D puts the bootsector code as well as some program in flash, but can also use SD for storage, up to 4GB in size for filesystem, and capable of using the rest as RAW sector data

just pointing it out :p
 
Hmm, interesting. I have not been able to fully confirm what the differences are with the Stone displays.. All I have to go on is their spec page. I am specifically looking at this module (The advanced one with allegedly 1000cd/m2 brightness)

http://www.stone-hmi.com/_d276735288.htm

It says standard 2GB flash and 4gb extended (which does sound suspiciously like something removable). It also mentions though that the picture switching speed is 47ms (equates to 21frames per second) which is better than the 4D 3.5 frames/sec so that would suggest that images can be displayed from actual onboard memory, not from an SD card. I have found multiple official confirmations in the 4D forums that the 4D panels always display all graphics - including frames of gauges (userimage objects) - from the SD card at a MAX of 1220000 pixels per second.

If there's a way to use the 4D to store some gauges or data on internal RAM to speed up a single gauge display then that might be enough to be hugely helpful - but I thought I had seen confirmation that it only has 32kb of onboard storage.

It's reallllly sunny here at the moment so I have just loaded a mockup screen onto the 4d and looking for a long enough extension cable to get the screen into direct sunlight to see how it looks... :)

Cheers - N
 
yeah my work on 4D included 2 of their screens in the car:

https://www.youtube.com/watch?v=3IG5EZG9KeU

however, i later modified the push-to-start to digital animation:

https://www.youtube.com/watch?v=bEWWOAI2ocM

which also included HVAC section:

https://www.youtube.com/watch?v=DB5bRkkyhpQ

It's okay for what I use it for, but I can't do much now at -20 temps, so I'm stuck working on code these days at the PC :p
each display had it's own thread using TeensyThreads, so both ran at their optimal speeds
 
Yep - it seems like the 4D displays are great for relatively static displays, but their forums have a lot of people struggling to get higher refresh rates working smoothly. Looks like there are a few ways to improve things with clever workarounds, but the absolute throughput of storage -> screen is so low that any high frequency refresh gauges that have any real area are always going to be battling the hardware :-(

I love how integrated and finished the install looks in your car - I think I recall seeing a post somewhere on the forums too - the RPM display is distinctive and I remember that.

Cheers - N
 
fiberglassing is fun, I redid the cluster to add lips, now keeps the sun off :) however and not finished painting it, and added 2 microSD slots to the bezel, so I could easily reflash the display uSD cards when adding/removing objects

kdaiip.jpg
 
Just a hat-tip to the TeensyThreads reference - I hadn't seen that before but I'm looking at it now and getting all excited about what it means for input and menu handlers as well as the actual lap timing code...

Cheers - N
 
It's awesome library, I currently run 4 threads, be sure to use mutex locks on shared ports, and you'll be fine, when I added the 2nd display i noticed a slowdown of the first display (obviously).
TeensyThreads ressolved the issue of returning full speed back to the first display as each handler & display code is in a seaparate thread
 
perhaps an option to consider would be 2 cellphone screens placed one above the other in landscape. many cellphone screens
are very bright and easy to read outdoors.
 
why cell? im surprised you didnt suggest a tablet for the size he wants, and of course, that would require writing apps for it (android/ipad) which would further limit his use of gpio access and whatnot, unless he also wanted to program a bluetooth protocol for mcu -> tablet, and live with the limited baudrate involved...
 
well, partly because i think cell screens offer increased brightness for daylight viewing over what tablets offer and partly because i'd like to see a project involving arduino compatible interface to MIPI DSI for LCD/OLED screens found on cellphones.
there was one that fizzled out a couple years ago but it seemed to be a solid project. although it was mostly to adapt HDMI to DSI, it also had a as yet undeveloped arduino interface that if matured would probably allow a teensy to be hooked directly to a cellphone screen. this project already has adapters for iphone 4, LG Optima, HTC Droid, which kinda shows how dated it is as a now sleeping project. but, to your point, it seems there would be no need for any apps, nor any limits of gpio or need for any bluetooth. something like this would just pump teensy [or other] to framebuffer then to cell screen. but, overall, since it only partially exists at this time it's actually of no use if the OP needs of currently viable solution. maybe i mentioned the 2 cell screens in hopes there would be a reply questioning it and i could then post the link and then the project comes back to life. :)
https://hackaday.io/project/364-mipi-dsi-display-shieldhdmi-adapter/details
 
See if any reflective LCDs are still being made. Or...eInk/ePaper, if you can live with the slowness.
 
Should be compatible with the FT8XX series from FTDI. Same series used on the Gameduino.
Got a pair of 7" FT811's I have been playing with. Pretty nice little chip, the Gameduino library can be a little confusing but there is a few active fellows working on a fork that supports Teensy's.

Only thing I don't like about Newhaven is that they are so damn proud of their screens. I can get a 7" cap touch screen from HotMCU with the FT811 chip and ribbon included for $32. Hell it even has a nice little acrylic case with mounting standoffs. The only negative is its not daylight view-able like 95% of screens.
 
I also had problems with the update speed of the 7" 4D systems display, for me the biggest issues was the fact that the library is blocking program execution. I managed to solve the issue by pulling the relevant library code into my sketch and changing the way the display is updated by implementing a kind of object queue. You can find an explanation on the 4d systems forum. It could be that the display is still too slow for what you're trying to do but at least the flow of the program is not blocked. If the display cannot keep up controls will skip updates but in the end they will all show the correct value so this approach is not suitable if you want to log all the states on the display but it works very well if the requirement is that the display should always show the actual values.

Kind regards,

Gerrit
 
Thanks for all the thoughts... some comments...
- Cellphone screens are awesome... I will quite possibly give up on the screen completely and focus on writing a CANbus output system for everything and then pick that up in Realdash on a phone (lots of daylight readable phones).
- The 4D screen is too slow. Went down quite a few rabbit holes. The fact they pull everything off SD ALL THE TIME and the libraries block execution are killers. You can use fire and forget but the display can get badly out of sync.
- I have ordered another HMI screen by Stone. It's a 5" 900nit HMI screen with a reasonmable amount of flash (256mb) so I suspect that's going to be significantly faster than the 4D. (in fact the Nextion would be perfect if it was daylight readable.
- I'm considering seeing if I can graft the 4D screen onto a Nextion controller since the 4D screen is pretty much useless to me now.

In any case for the moment I am giving up on 4D, I would always be fighting something too slow. If the Stone HMI LCD doesn't work then I'll move to CANbus messages for a 3rd party display solution (realdash on a phone)

Cheers - N
 
Interested to hear your thoughts on the Stone screen and using it. Might just be the perfect solution for my similar project as well, but a bit more than I'm interested in spending without some real-world feedback.
 
Hi,

I'm surprised by your experience with the 4D. Yes the limit is 2Mb/s to the display, but that's normally enough (in fact it's a bit more if not coming from the SD).

I'm driving a plane EFIS and the horizon refreshes at 30fps from the SD. The trick is was to limit it to 200x200 (center part with static frame around) and build the other gauges from graphic primitives, which are a bit faster. You have to work by delta, if you refresh the full screen it clearly doesn't work.

But I'm driving it with a 4D custom program, not 4D Serial which I never tried. It reacts to frames sent on a fire and forget mode by the Teensy, not slowing the cycle time which is way below 1ms. I did also create combined a graphic file from a Java program which allows to address the SD without the overhead of the FAT. PM me if you need info on driving the 4D.
 
I managed to work on a 4D library that is able to also retrieve live values from LCD's objects, without needing to code in callback. It also doesn't go out of sync either.
 
I too am looking for a good "sunlight readable" displa but with a lot more resolution on a larger screen. Right now I am reading ADC and timing with my Teensy 4. (T4.1 on the way) and serial feeding batches of data to a MS Surface Pro4 to get high resolution and easy menu and displays using Python and Pygame (graphics). Would like to simplify and go straight to a lsrge hires touchscreen. Any ideas?
 
Status
Not open for further replies.
Back
Top