@@AngryDogPerformance the wide screen is an Ali express item from Wisecoco. www.aliexpress.com/item/4000475157263.html To verify you find the right one, check that it has a blue hdmi board with a semi circle cut out of one edge in the images. The 7" touch display is one of the many usb capacitive touch screens also on aliexpress. Try www.aliexpress.com/item/1005007010531600.html (Not the one you are looking at in the video, but I have used the "with speakers" version successfully in an SDC product). SDC basically works with any hdmi display that is full HD or lower resolution. As long as you can get the config settings for it for the Pi. For touch, the screen must be a usb hid touch device.

@@richmet That is amazing. in 2018 i started looking for options all over the world to do this exact project for a coyote swap in my town car. I think the market just wasn't ready yet at that exact moment, so i put the project aside. Looks like maybe 12mo later this started becoming a more mainstream project and manufacturers have been building more and more of these for all sorts of applications. The 12.3 specifically was one i was having trouble finding. The cheapest one i remember finding was ~$500 on ali back then. $35 now....amazing! Thanks for the quick reply. One other question though, how has the visibility been on that 12.3 in direct sunlight?

No, I have specifically avoided doing that. It would take a very long time to do it properly, and TunerStudio can already do it. Both can be connected at the same time.

If you mean for building TinySDC, this is not self-build product (and it is still a the prototype stage at the moment). If you mean any other SDC implementation, then see the website at sdc.v8creations.com

I changed my mind on this (requires SDC 1.41). See here: sdc.v8creations.com/tinysdc.html

@@minoomm3911 Don't worry that is normal. Just use whichever code you see when you are ordering, as long as it comes from the device you are going to use.

@@richmet Wonderful, thank you sir !! If I have a (technical) question, how can I contact you ?

@@minoomm3911 You will be able to contact me via the e-mail address that the license comes from.

@@richmet Thank you sir 👌🏻✌🏻✌🏻

@@yip5471 this is not uncommon

@@richmet ik ik, i’ve been researching it for awhile (especially for hondas) some people have cracked it but the CAN is pretty hard to crack on 2007 on vehicles

I've got some boards here but they need building up. How many do you need?

@@richmet I’m just needing one I was going to order on your website but couldn’t due to no stock

@@riddlerga I've got one built I can list. Where is the canbus data coming from, or are you just future proofing? SDC doesn't read canbus data in any formats other than its own.

@@richmet I have a dropbear ecu that I want to connect to a raspberry pi 3b+

@@riddlerga The speeduino firmware running on the dropbear does not have any support for broadcast based CAN. It is all request-reply based, and is limited in the dataset that is supported. Due to this, SDC still has to be connected to the serial feed on the dropbear (in fact on all Speeduinos not just the dropbear design).

It's all custom.

It is not designed to work on either the pi4 or pi5. By extension it won't work on any other pi that does not use a videocore4. The compute power of a pi4 or 5 is not required at all to run it. "Issues" implies I am trying to support them, but I am not. They are just significantly different and the effort is very large to support them so I'm not doing it at this time.

Excellent response, is this package something you are selling or posting more information for somewhere? I am exploring options for digital dash for my swap project. Is the CAN board something you've created? ​@@richmet

@@JakeMakesProductions sdc.v8creations.com There are links to purchasing from there. I do hardware kits or software only. Be aware the CAN support is not for interfacing to existing oem systems. It's for implementing a multiple node system or as the basis for building your own extensions.

@@richmet great I found your site, I am only looking to read from the oem can system. (No write function) I was previously looking at open Auto pro but it looks like your program is a bit more flexible with its "piggyback CAN network". There are a couple things I'd like to add such as a transfer case controller that checks for neutral gear before shifting to 4low and more than one display. Open auto pro looks capable of this but would be running off of a singular pi, I like how your system is divided into dedicated modules (similar to OEM). I think I already have an Arduino dual-ch hat to start doing some testing, is this compatible with your program to get started?

@@JakeMakesProductions The sdc can network is 1mbit can (I.e not can-fd). Anything that talks that can see the messages. Obviously you need the can hardware on the pi for it to be able to transmit or receive messages, as well as the arduino or whatever other devices you want to add. The can protocol is described in the help pages in case you haven't seen that yet.

The io hat contains a standard canbus peripheral and transceiver, but the sdc software is not designed to interpret manufacturer canbus messages. You wouldn't want to mix sdc format canbus messages with oem vehicle messages as they may overlap, causing the oem devices to error.

Sorry for late reply. Looks like you found it all by yourself based on the store registration 🙂

I built my own application specific framework for it Chris.

@@richmet Yes, I found the SDC site after the fact. :)

did you ever get a reply?

@@FCKSHT813 unfortunately not, assuming he's keeping it closed source, which i dont blame him with all the work gone into it

It is loosely based on the Senna display. I'd call it 'in the style of' rather than a direct copy. I am not actually intending to provide a wide range of pre-built screens, but rather a range of examples that people can use for their own designs. Anyone can create and extend the graphics via the editor. I'll do a video on it at some point. You can see the mclaren-esque one here: kzbin.info/www/bejne/mKq4aKR5r8ufqbs

At the moment every data attribute has to be from one and only one source. There is no support for multiple instances of the same attribute.

@@richmet No worries, I will just run 2 screens - a dedicated serial from each speedy to each SDC and screen. Are you going to sell these soon? If so double the sales from me.

It's been a while since this discussion. Dual ECU support was added about 6 months ago. So you can now in fact display data from 2 speedys on one screen. See sdc.v8creations.com/dualecusupport.html

​@@richmet That is great news, thanks for the follow up/update. Nice technical write up too, even I could follow it!

It will work on any display size up to 1920x1080. I run it in my car on a dual display (two devices on canbus) and one of those is a 1920x720 screen. The other is the one you see in this video, which is 1024x600. You can load in any layout regardless of screen size and if it's too big it will be scaled down to fit the screen, provided the designed size was set in the screen editor.

Yeah we had talked in slack before, Im not sure if I still have the chats, but cool! I look forward to releases!

It uses a list of GPS camera locations.

@@richmet oh ok it doesn’t detect then. Thanks

@@zzonerr Yeah detection isn't really a thing these days. Almost all camera warning systems have a database of GPS locations and use your current position (and road for a nav system) to determine when to issue a warning. Mine doesn't know what road you are on so it uses a 30 degree cone projected forward from your current position, defined by a time of 15 seconds based on current travel speed.

@@richmet thank you, really nice work 👍

It's in the video title - Speeduino.

It wasn't a case of taking something that already exists and installing it. I had to create everything from scratch.

You can contact me via private messaging on the speeduino forum user ric355

I built some custom software that runs directly on the pis instead of running Linux. That's why it's so quick to boot.

@@richmet can you share it?

It's a standard 0.4.3 board. I forget which revision. Might be 0.4.3b.

@@richmet ok she uses a mega 2560 or a teenzy? if mega 2560 how did you make the can connection?

It's a mega. I built a device which bridges the serial connection to a canbus.

@@richmet ok if possible a tutorial or a wiring diagram it's verry usefull

It's not a tablet. It's a raspberry pi but rather than running Linux it has a custom developed Kernel that enables direct access to the hardware using a development platform called Ultibo. The same kernel runs on the left and right screens (one Pi for each) but with different configuration.

It's a TVR Chimaera

There are 5 devices on the network and at least two of them need to be able to see engine data, so it needs to be broadcast since you can't share a serial cable between two devices. This level of abstraction also means flexibility for future changes. The very first device I made was a single unit screen which took the serial data directly. The gauges software can still run in this mode although I do not use it on this vehicle.

I have recently implemented some changes that speed the boot time a little more by doing 2 things: Firstly, some of the graphics are now 'load on demand' so that carefully selected images are only read from the SD card when they are needed. This reduces initial boot time by about 1 second. Secondly, I have written an 'image vault' feature. This is a compressed file containing all of the images needed (excluding load on demand images) and it is loaded into memory in a single shot. This makes the loading of all of the other images significantly more efficient. Most of the boot time is waiting for the SD card reads, hence the concentration on the images. The system uses page definitions in an XML file to define the layouts. I did make some changes to only load the initial page and then load the rest in the background shortly after boot, but for technical reasons related to the way the GPU works this is a complicated piece of work for limited gain: As it stands now, the barrier to getting the cluster to appear sooner is actually the boot time of the right hand large LCD screen. It takes about 4 seconds to boot and that is roughly the same time as the cluster application currently takes to initialise. So getting it any faster is a waste of time right now and that is the most significant reason why I put lazy load on the back burner. The two screens are actually synchronised at boot but I don't think I had it enabled when I took this video. The left hand screen waits until the right screen has initialised before switching from the boot logo. It is ready much sooner because it has a different xml configuration which has fewer pages and fewer graphics.

@@richmet thank you for your reply. By any chance, do you have a GitHub repository or a Instructable? Something I have also been after is having the ability to load a tune on the fly. Kinda like having the ability to have and eco mode for daily driving and a race mode for track day. With your experience with the speeduino system, do you think this will be possible?

@@jared4670 you don't actually need to have two different tunes for eco and performance. This is because the areas of the fuel and ignition maps for those types of driving are different, so both can be done in a single map. Speeduino does have two fuel maps and they can be switched using an input or blended in several ways (blending is typically done when using ITBs which give a poor manifold pressure signal at idle rpms). Another reason you might want two maps is for different fuel types, but assuming same fuel eco and performance can be done in the same tune.

The sensors I am using are bluetooth, and someone had already worked out the protocol so I just used their description. I found a project on github github.com/ra6070/BLE-TPMS which has a description for the data format on the main page. I did not use their code, just the protocol description, so I have no idea if theirs works. These bluetooth sensors are broadcast based, so you don't have to get involved with bluetooth connections, but you will need some sort of bluetooth stack to access them. Note most OEM sensors are *not* bluetooth; they typically use a 433Mhz proprietary format (frequency depending on where you are in the world) which is a lot harder to work with.

@@richmet I see. Thanks. I thought you used commonly OEM available 433MHZ ones. It's an option, actually. thanks!

The smaller one is a 7" capacitive touch bought from Amazon. It's unbranded but can be identified by the four mounting lugs on the top and bottom edges, and is 1024x600 resolution. The larger one is a 1920x720 12.3" LCD from Ali-express seller 'Wisecoco'. It's the one that has a blue driver board with a semicircle cut out of one end of it. Note that neither of these screens allow programmatic control of brightness. I have engineered auto brightness control for the small display with a mosfet and a light sensor, tapping in to the backlight switch, but there is no equivalent for the large screen.