Multi network and sensor automotive datalogging

[rgeyer]

Hello All,

I'm looking for guidance on a project I'm designing. The goal is to monitor, and log the traffic on multiple networks in my car, as well as some analog sensors. I started building this with a RaspberryPi, and some golang code since I am *much* more comfortable with userland computer software programming (https://github.com/rgeyer/go-ssm2logger), but I realized it's likely going to be much better to do this with a more embedded solution.

At the moment, these are the things I'd like to log.

1. CAN0 - 500kbps Engine/Driving
2. CAN1 - 125kbps Body
3. CAN2 - 125kbps Entertainment
4. Subaru Select Monitor (SSM) - 4600bps UART
5. Fuel Pressure - Analog sensor

I intend to wrap this data in my own data frames which will include a timestamp, the type of packet, then the content. This will ideally be streamed to an SD card for logging, as well as being output over USB serial so that I can connect a laptop to see and analyze the data in real-time.

I have selected the Teensy 3.6 for the following reasons

• Fast USB Serial (12 Mb/s)
• Dual embedded CAN (Still need a 3rd)
• Embedded SD Card

I have a couple of questions.

CAN Question:
First, since I need a 3rd CAN connection, I see three different options.

1: Use the two embedded CAN, with appropriate transceivers, and add a third CAN using something like the MCP2515 over SPI
2: Do not use the embedded CAN at all, and do all CAN over SPI using MCP2515 (or similar?)
3: Assign two more digital pins as CAN2 TX and RX, and go spelunking in the Teensyduino code, and FlexCAN to support my franken-configuration

Ideally, I'd love to do #3, but I'm not sure it is even possible?

If it is not, any advice on which of the other two approaches to use in order to address all three of the CAN networks I'm attempting to monitor?

Speed:
I (probably naively) thought that since I was dealing with less than 1Mb/s of throughput (500kbps + 125kbps + 125kbps + 4600bps) that I would have no problem writing that data to an SD card, and spewing it out the USB serial, all with cycles to spare for processing, and accepting input/interrupt commands via USB serial. Afterall, writing to an SD card is usually measured in multiples of 100MB/s, and I have 12Mb/s through USB serial.

But, in reading this thread (https://forum.pjrc.com/threads/55114-SD-Datalogging-Best-Practice-in-2019) I'm beginning to get concerned that maybe I'm not thinking through this correctly?

I'm sure I'm leaving things out, and I'm still quite new to Arduino, but I'm a fairly accomplished software engineer, and happy to take advice, learn, and do the work. Please feel free to ask me questions about what I may have left out.

Thanks in advance for your guidance!

 

[tonton81]

there is no guarentee of catching every single frame in the automotive environment as they are repetitive and constant in processing, the mailboxes/fifo may overflow if the traffic is too fast, you need to consider this. This is not a fault of the teensy processor nor other mcus but the storage of the CAN chip mailboxes itself and how fast the processor can empty that mailbox before the next message gets lost waiting for a drop box. You will be far worse with a MCP2515 as it has only 2 RX mailboxes, teensy 3.x have 16 mailboxes, or if you use FIFO, 6 deep fifo with 8 mailboxes. You could go with 2 teensies to spread accross all 3 busses, then pass the data exchange between them for processing

 

[Darcy]

I have seen teensy 3.6 with 3 canbus + single wire comms + Datalogging. CAN0 and CAN1 were using the FLEXCAN controller incorporated in the teensy, CAN2 was handled using MCP2517FD.
You should have no problem doing what you want to do as your bus speeds are low. IMHO It is highly unlikely you will drop any frames at those speeds.
The most difficult bits are logging efficiently to SD, but logging binary and/or using pre-allocated files has been successful for me and I have 2 buses at 1000K baud each.
USB streaming all the data is probably not a good idea, but I have never tried.
I have not seen automotive CAN pushed past 50% bandwidth so I think you should be OK.
Google suggestion for hardware and code:
1: Skpang
2: Heavy-Vehicle-Networking-At-U-Tulsa

Good luck.

 

[rgeyer]

Thank you both for your responses, it's given me some good guidance and prompted me to go reading a bit more of some datasheets and other things.

Here's a couple things I've gleaned from my research.

I have seen teensy 3.6 with 3 canbus + single wire comms + Datalogging. CAN0 and CAN1 were using the FLEXCAN controller incorporated in the teensy, CAN2 was handled using MCP2517FD.

My application is for a 2005 Subaru, so CAN2.0B is ample. Thank you Darcy for the search hints, and identifying the MCP2517FD. I've got some MCP2515 prototype boards which I may experiment with at first, but the large number of FIFO and filtering on the 2517FD are quite attractive, even if I am only using it for CAN2.0B

My previous message may have hinted at my ignorance here, but I assumed that "FlexCAN" and the capability baked into the Teensy were somehow software driven, rather than a module that was part of the MCU. Thus my suggestion of "repurposing" a couple of digital pins for that purpose. I understand now that the FlexCAN controllers are embedded in the MCU, so that's not an option, and an external standalone controller is necessary.

there is no guarentee of catching every single frame in the automotive environment as they are repetitive and constant in processing, the mailboxes/fifo may overflow if the traffic is too fast, you need to consider this. This is not a fault of the teensy processor nor other mcus but the storage of the CAN chip mailboxes itself and how fast the processor can empty that mailbox before the next message gets lost waiting for a drop box. You will be far worse with a MCP2515 as it has only 2 RX mailboxes, teensy 3.x have 16 mailboxes, or if you use FIFO, 6 deep fifo with 8 mailboxes. You could go with 2 teensies to spread accross all 3 busses, then pass the data exchange between them for processing

You should have no problem doing what you want to do as your bus speeds are low. IMHO It is highly unlikely you will drop any frames at those speeds.

I tend to agree with you Darcy that it's unlikely this solution will miss CAN frames, but even if it does, that's actually not mission-critical for my application. The 4600bps UART comm is actually the most important, while the CAN logging will be largely academic (for now).

The most difficult bits are logging efficiently to SD, but logging binary and/or using pre-allocated files has been successful for me and I have 2 buses at 1000K baud each.

As for logging to SD, my plan is to write my proprietary packets/frames to the SD in a stream, one file for every drive cycle. I'll be writing software to be used on a computer to actually interpret that binary stream. Hopefully I'll be able to get the throughput I need there, I may be hitting you up for some detail on your logging solution Darcy.

USB streaming all the data is probably not a good idea, but I have never tried.

I may be willing to abandon this, but the idea is that I could do bi-directional communication over USB. This might allow me to interpret the data "in real-time" with a connected laptop, and/or send commands to the Teensy which might change the behavior of the logging. I.E. Add a CAN filter, or change which PIDs I'm requesting from the OBDII line.

I'm prepared to abandon this of course, and use a "config file" on the SD card as a way to statically configure the behavior, but I like the idea of being able to interact with it from a computer. We'll see how that goes.