The Quarky Engineer

The Motec Display Creator for the C187 display is pretty cool. I can see myself spending lots of time here.

Lots of pins for this C187 hookup. When I built the harnesses for the engine bay sensors, I brought every sensors power and ground back individually as well as the signal. I did that because in the Motec you can indicate which sensors are on which power supply rail and for things that are ratiometric (like temp sensors) it can correct for the voltage not being exactly 5.0V.

I need to add the end connectors to the car harness and it will be ready to install… Then on to the dyno for Timothy Bailey and I to have some fun. Thanks Tony Palo for recommending I get the 187 instead of the smaller one. Indeed I’ll need all of those inputs! Also thanks to Sharif Abdelbaset for the wiring tip.

I have my harness partially done for the C187, so I powered it up to make sure it works. The display is incredible. It is bright and has high contrast from all angles.

(Note – Nerdy stuff)
So after a bit of noodling on the conversation last week, I have decided that a hybrid approach will be the best way to build the CAN master device/recorder/display driver. The goal is to have this device be something that is installed in the car and have it connect to the car’s CAN bus and capture data from the other Open-CANDAQ devices (Analog inputs, Thermocouples, Speed, etc), as well as anything on the factory CAN bus. I’d like it to also support some interfaces to some displays, as well as support auto log uploads over wifi, bluetooth, or perhaps telemetry over a cell modem.

I mentioned last week that many of the Pi based CAN boards use the MCP2515 CAN controller, which has no FIFO. I had considered using the new MCP2517fd which has a FIFO, but after a bit of experimenting it could still lead to some timing problems. (there are worst cases where interrupt latency could slower than a full rate bus and a 32 frame FIFO).

Since I already have a great working firmware for the dsPIC33, I am going to make a board with that microcontroller and a socket for a Raspberry PI Zero W. That will fit into the same kind of case as the other devices, and the dsPIC33 has an excellent onboard ECAN interface with very low latency support, lots of RAM for buffers, plus support for both simple and complex filtering. I’ll connect the dsPIC33 to the Pi over 10MHz SPI, and since I am writing the firmware on the dsPIC33 I can implement my own low latency caching protocol.

This gives me the best of both worlds, since I’ll have a complete Linux environment for doing networking, upgrades, math functions, conversions, display driving, etc. The dsPIC33 microcontroller has plenty of power at 80MHz to do sub microsecond frame turnarounds, lots of ram for buffers, and of course it has some on board ADCs that I can use for a few extra inputs (knobs and switches perhaps ) as well as to monitor the 12V and 5V power rails.

It will be an easy board to design since I already have the parts and layout for the connectors, so I should be able to get this to OSHPark this week. Cost wise this will still be a pretty cheap setup, as the Pi Zero is about $15, and that dsPIC is about $5.

This is winter in Portland, and I love it. A nice rainy morning! And the forecast show a great 10 days. I moved here 24 years ago, and I still smile on days like today. Perhaps all that radiation has flipped a few bits.

Now there are the tools for a party! #Motec

I have been experimenting with some CAN receiving hardware as part of the Open-CANDAQ project. I wanted to have an inexpensive CAN logging system that can handle full CAN frame rates, write to something like an SD card, potentially do some on the fly manipulation for display driving, and support networking for transfer of data.

An obvious choice is an ARM based Linux platform like the Raspberry Pi or the Beaglebone. The Pi doesn’t directly support CAN, but there are a number of aftermarket shields based around the MCP2515. TheMCP2515 is an CAN-SPI controller that is very easy to interface to. All it needs on the host microcontroller is an SPI port and a single interrupt pin.

One of the flaws of the MCP2515 is the lack of a FIFO buffer. It can only hold one message, and if you don’t get that message before the next one arrives, you will lose the new message. That means you need very fast interrupt response time.

I hooked up a Pi 3 + MCP2515 to my home CAN test network and did a bit of testing. I was surprised to see that if there is no additional load on the PI, it can in fact capture all the frames on a 99% saturated 1mbit CAN bus. I loaded the CANbus using a couple of copies of cangen and was able to capture 1 million frames without a single drop.

However if I added i/o load the pi ( either disk io or serial io), I started getting dropped frames. With a very full load I would miss over 25% of the frames. When I lowered the frame rate to 1ms frame interval (so ~1000 frames/sec down from ~7200 frames/sec full rate) it still dropped 10% of the frames. Even at 10ms frame interval it dropped 2%.

So, the MCP2515 is not a viable option. Fortunately Microchip knows this and has released a new MCP2517fd which has both a FIFO and CANFd support. There are not any shields yet with that chip, but I ordered 10 of the chips from Digikey and I’ll make a small test board once they get here. I suspect they will be sufficient for an load test case on a CAN bus, especially on a PI3 that has a quad core processor. If this works, it will make for a very cost effective CAN capture device.

Oh this looks nice. I think the GTR will like it. Now I need to figure out where/how to mount it!

I finally got around to upgrading my home VMWare cluster from eSXi 5.5 to eSXi 6.5. Since moving the datastores to a shared NFS mounted ZFS array over 10gig ethernet things like this are much easier. I know Matthew R. Wilson will look down on me for not using something else, but eSXi is so damn convient.

Everything fired right back up after the upgrade, including my home Hadoop cluster.