Thank you for the quick reply! That gear indicator is around $250 retail. The application I am working on already has an electronic dial gauge set that has integrated the PCS gear indicator into the bezel/cluster. If possible I really need to stay with this gear indicator if at all possible to avoid having to redesign/manufacture the mounting/etc. I did go ahead and change the name of the subroutine with no improvement. Just to confirm, you were able to test and confirm that the code worked as intended? I have also tried using an OBD plug and HPT today as a diagnostic tool, but I am still getting the same error when trying to connect.

 

Not exactly, I ran your code on a standalone can setup and got the same error as you. Then I ran my own code in a setup where I was transmitting messages to the CAN encoder below. When I unplugged the CAN connection, I got the same exact error as you did. When I plugged the can back in, it stopped.

BTW, I'm working with a canbus display device, that can not only display what gear you are in, but has a touch screen and dial that has advanced haptic inputs like touch and swipe. It has a GUI builder that lets you put in any graphics or text and any number of screens. All kinds of canbus controlled stuff like screen dimming, progress bars, gauges, etc. It's a Grayhill Touch encoder. A single hole with a locking nut mounts it.

 

That encoder looks very slick. Lots of potential in a small package. Did everything related to the can send function look like your implementation? Are you able to post any snippets of transmit code for comparison? I’m wondering if there is like an initialization frame or handshake or something that I’m missing. The gear indicator is connected to the other end of the CAN bus but so far no luck.

 

I never tried two MCP2515s on a single processor, but that shouldn't be a problem IMHO. Maybe check that you didn't mix up your CAN high and CAN Low. Also terminators should be in the circuit, but not critical for short distances.

I added some of your code to mine to check the error message. Here is a little routine that send a request to the encoder to see what screen it's on every half a second. I use this to see when the encoder finally boots up (takes a few seconds) before I send it more data and also to make sure we haven't lost communication. The encoder then sends back a response and if I don't get the screen number back, I'll know it's FUBAR.



Your code looks fine otherwise

 

Wait, so something like this could be made into a dash?

 

Yes, absolutely! But...... you're probably going to need an intermediary processor with 2 can bus interfaces and lots of code in between. The reason for 2 canbus interfaces is because most automotive canbus are are 500kb or 1000kb. This one appears to be 250kb.

That looks like an industrialized intelligent display similar to the 7" one in my setup (post 78 in this thread) only it talks canbus instead of a simple serial interface and it doesn't have a touch screen. Probably a bit brighter which is a plus.

A CANBUS interface is great for industrial apps because of it's inherent noise immunity, but for simplicity of interfacing a serial one is simpler.

The code in your intermediary processor will have to translate the can data from the source can input (or just from sensors) and decide how often to update the can display so as not to overload it. In my touch screen, there are about 7000 lines of code that are for the most part dedicated to the display. Doesn't need to be that complicated for just displaying data but mine has full live editing capability, and is more of a user interface than just a display.

Almost all of these new intelligent devices, like this display, and the touch encoder and my 7" touch screen have a GUI that runs on a PC to help set up the graphics and the location and the appearance of each of the variables you will need to address on the screen. That makes the setup of the display easier.

Maybe post the actual link to this display so we can look at the details.

 

I'll try and do that today. Maybe I posted the wrong one. I swore the one I found initially was 1mb/s

 

If you find one that can work at the same speed as your CAN and it can be taught to translate certain PIDS to variables, on the screen, then you should be able to make it work as a display. The GUI would have to be told what the pids it's interested in and how to convert that data to variables on the screen. I havn't seen any like that yet, but that's how I would design the GUI if I were creating a general purpose display. But I assume these are more for custom medical equipment where the developers have the ability to customize the protocol messages to the display and not the other way around. Curios to see what you find.

However if then interface is like the on in the Grayhill Touch encoder I played with, it expects the messages with specific addresses and specific contents and I don't believe it can be trained to understand foreign commands other than the specific ones defined in the documents Here is the Grahill Touch Encoder CAN protocol

 

Found the tech dataset for your display: https://mm.digikey.com/Volume0/opasd...0FGAAASA01.pdf

Couple of takeaways. It says it has a capacitive touchscreen. It got lots of other interface options like rs232 and more. It says 250k is default, but no way to change it.

They even hard arduino code examples for it: https://github.com/Smart-Display-Ser...duino_Examples

Digikey does not stock it. They also make one in 7"

 

Scanning through some of the Winstar documentation it says that they can work with existing DBC files. The little 3.5" screen would make for a nifty dash to display transmission channels that are brought into Holley EFI.

Andrew

 

Hi all,
Just wanted to say thank you for this post. I've been wanting to make a gas mileage computer for my Holley Sniper for a few years now and finally took on the project.
With the help of this post in particular, I was able to finally crack the Holley Sniper with my Arduino and get live data from the ECU.
Extremely exciting and rewarding to see the numbers that pop up in the Serial Monitor match the values that are on the handheld display!

Not sure how to post the code as it says it's too long.

 

This looks quite promising, my project got back burnered due to an unscheduled engine rebuild but I'd really like to see your code. Maybe try zipping the INO file and naming it something simple the. Reattaching it.

 

#include <Arduino.h>
#include <mcp_can.h>

float RPM, pulseWidth, dutyCycle, closedLoopComp, targetAFR, AFR, lbPerHour, timing, IAC, MAP, TPS, MAT, CTS, battery;

union CANData
{
unsigned char arr[4];
float value;
};

MCP_CAN CANBus(53); //CS Pin. 10 for UNO
int CANStatus;

void setup()
{
Serial.begin(115200);
Initialize();
}

void loop()
{
if (CANStatus == CAN_OK)
{
CheckForCANMessage();
Serial.println("RPM: " + String(RPM) + " MAP: " + String(MAP) + " CTS: " + String(CTS));
}
}

void Initialize()
{
CANStatus = CANBus.begin(MCP_ANY, CAN_1000KBPS, MCP_8MHZ);

if (CANStatus == CAN_OK)
{
pinMode(2, INPUT);
CANBus.setMode(MCP_NORMAL);
}
else
{
Serial.println("Init fail: " + String(CANStatus));
}
}

void CheckForCANMessage()
{
if (!digitalRead(2))
{
unsigned long int ID;
unsigned char len;
unsigned char buff[8];

CANBus.readMsgBuf(&ID, &len, buff);

ID = ID & 0xFFFFF800;

union CANData val;

val.arr[3] = buff[0];
val.arr[2] = buff[1];
val.arr[1] = buff[2];
val.arr[0] = buff[3];

float newVal = (float)(val.value);

switch (ID)
{
case 0x9E005000: RPM = newVal; break;
case 0x9E009000: pulseWidth = newVal; break;
case 0x9E00D000: dutyCycle = newVal; break;
case 0x9E011000: closedLoopComp = newVal; break;
case 0x9E015000: targetAFR = newVal; break;
case 0x9E019000: AFR = newVal; break;
case 0x9E039000: lbPerHour = newVal; break;
case 0x9E049000: timing = newVal; break;
case 0x9E059000: IAC = newVal; break;
case 0x9E05D000: MAP = newVal; break;
case 0x9E061000: TPS = newVal; break;
case 0x9E065000: MAT = newVal; break;
case 0x9E069000: CTS = newVal; break;
case 0x9E06D000: battery = newVal; break;
}
}
}

 

I was able to strip it down to its most basic form, so looks like I got it to fit.
Holley's documentation doesn't seem to line up, but the main thing that I discerned from their documentation is that the value for the Sniper CAN Bus data is that it's a float. Once it's cast to a float, everything works as it should.
This code is set up for a Mega 2560 board, so the Chip Select (CS) pin is set for 53. An UNO would need it set to 10.

 

Good to know. I'm guessing you are tapped into the four pin connection, what's the pinout on it? I haven't have much luck finding a good answer and can't check mine as it's sitting on the floor right now.

 

BTW, I'd like to post the code for the standard Holley bus, but I don't have a Holley ECU to test with. If someone lends me one for a short period of time, I'll write the sample code and test it, and then drop it here. Then I'll return the Holley.

I built an engine simulator, so I can plug this in the Holley to test out the code.

 

Yes. I got a splitter off of Amazon for about $15 (much better than Holley's version for $45). It works great for keeping my handheld connected and sending data to the Arduino.
The power and ground aren't needed for this setup as everything is already powered. Just need the High / Low to the CAN Bus transceiver.

 

That's perfect, thanks. Now I can finally ditch the y cable in the engine compartment and integrate it into the engine harness and run it into the interior.

 

Anyone figured out how to pull the ethanol content from the flex fuel sensor over canbus?

 

This is definitely getting outside my wheelhouse. Lol