Hey, I’m planning on connecting the Tracker One to a vehicle that uses the J1939 standard.
I see that in the tracker firmware, there is this piece of code that gets executed at every loop:
canInterface.readMsgBufID(&rxId, &len, rxBuf); // Read data: len = data length, buf = data byte(s)
Now, I believe the vehicle I’m connecting the Tracker to is sending messages periodically (this happens with engine speed, and other messages).
Now my questions:
1- I see CAN_INT goes down when there is a message in the queue, does it make sense to keep reading messages until there are no more in the buffer? I guess this can be done with can.available(), but the Tracker uses the MCP_CAN lib, and I could not find in it an available() fx.
2- when reading a message and specifying an ID with this call:
canInterface.readMsgBufID(&rxId, &len, rxBuf)
what happens with the messages that do not match that ID, are they discarded or do they remain in the queue?
I don’t think that’s how a vehicle OBD-II CAN interface normally works. J1962 connector under the dash connects to the ECU. That connection is not a full stream of everything that is going on in the vehicle.
Instead, you use
sendMsgBuf to request a specific PID like engine RPM or vehicle speed. The ECU then responds with a reply with the data for that specific PID, which you read using
Because the data is typically not a constant stream you normally won’t get multiple message back. But it’s probably not a bad idea to call it in a loop. The return value of readMsgBufID will be
CAN_NOMSG if there is no message waiting, and you should exit the loop.
The ID in
rxId is not a filter. It’s filled in with the ID that the first packet in the queue.
I’m going to get to it soon, but from what I read, J1939 could be a stream of some messages:
Apparently, the engine speed is one of those messages transmitted all the time.
I’ll come back with more info or perhaps a confirmation about this - thanks for all the details.