M2 Processor Capabilities

General Discussion
#1

Hi there! I found Macchina a few days ago and it looks like the solution to my problems! I’m trying to make a real-time data logger for my car. Specifically I want to sniff CAN traffic on GMLAN and one or two CAN buses and log these data to a file as well as transmit over bluetooth. Additionally, I’d like to capture OBD-II data for a subset of SAE-standard PIDs, which will require active querying.

I originally purchased the Freematics ONE+ B, which I thought was a done deal. It had everything I was looking for (GPS, LTE, accelerometer, magnetometer, WiFi, Bluetooth), but the software support is absolutely abysmal. Their support forum is sparsely populated and full of spam. They claim that their device can be used to sniff CAN traffic, but when I upload their example sniffing sketch, I see no data and a week of debugging and forum posts has yielded no answers or help. I’m able to use the device to query an OBD-II PID and read the response, but if I send the query frame manually, I can’t even sniff the response which indicates some serious issues. Part of the issue here is the ELM327 is isolated from the processor and can only be accessed through a protocol co-processor with closed-source firmware, so my debugging capabilities are very limited.

The Macchina M2 seems like a great alternative, but I have a few questions before I commit to buying it. First, I originally wanted both Bluetooth and GPS simultaneously, but it appears such a thing is not possible with the M2 without unsightly external wiring. I can tolerate this, however, since my vehicle provides GPS over CAN. My main concern is the throughput of the M2 processor. The Freematics is ESP32-based and is dual-core, so I was less worried, while the M2 is based on the single-core Arduino Due. Will the M2 be able to:

  1. Query a subset (but still many) OBD-II PIDs
  2. Capture all CAN frames on two or more buses
  3. Write the data from (1) and (2) to both SD and Bluetooth?
#2

@froghorn - The answer is YES to all of those!

For Bluetooth, you’ll want to plug in a module for that. We just so happen to make the SuperB, which is a ESP32 based XBEE-format module that will plug right into M2.

M2 is completely open source, so there is no “black box” interpreter chip. You’ll be programming the SAM3X8E processor to interact directly with your car’s ECU…

Take a look at these “mini-tutorials” for examples of projects:

https://docs.macchina.cc/projects/mini-project-tutorials

Let us know if you have other questions.

#3

Thanks for the quick reply @josh. I saw the SuperB and already added it to my cart :slight_smile: I’ve already taken an intensive look at your spec, documentation, and starter code before getting to this point. I like the Macchina project, I just hope it doesn’t go the way of other crowd funded car hacking projects (like the CANBus Triple).

Just to be clear though, you believe that the SAM3X8E has enough processing power to query dozens of PIDs, sniff data, and record to bluetooth and SD simultaneously in real-time?

#4

Oh I actually did have one other question. I was looking at the SuperB vs. SuperBX. The latter has a u.FL connector for an external antenna, correct? I was thinking of getting that one just in case I need better connectivity, but it appears that the connector replaces the trace antenna. Does this mean the SuperBX cannot be used without the external antenna connected?

#5

@josh So I talked with the owner of Freematics who told me that their CAN sniffer is unable to sniff without a filter “due to high speed CAN bus data could block serial communication.” Is the M2 capable of capturing all frames received on a bus?

#6

I’ve seen some pretty amazing projects done with M2. It all depends on what you are doing, code efficiency and that sort of thing. Give it a try.

That is correct, You’ll either want to use SuperBx with an external antenna or SuperB with the built-in antenna. Unless you are looking for long distance connection or are using a metal enclosure, SuperB works pretty well.

I’ve personally seen thousands of frames per second flowing into SavvyCAN via M2 over a USB cable. @CollinK - you’ve got some insight here, have you ever run up against any limits when capturing a LOT of data?

On a related note - we built P1 as sort of an “upgrade” to M2. It is a completely different approach (full Linux vs microcontroller) that happens to have a 1Ghz processor (compared to the 84Mhz on M2).

#7

Alright, I’ve gone ahead and purchased the M2. I was hoping that just in case I need more power, I’d be able to buy the PocketBeagle and swap it out, but it appears the P1 uses an adapter board that is not sold by itself…

#8

Right on, thanks. I bet if you ask nicely, we can work out an “upgrade” deal for you :slight_smile:

Good luck and feel free to show off your project/findings on this forum.

#9

Awesome :slight_smile: Thanks for all of your help! I’ll ask higher ups about making the code I write open source.

#10

As far as high traffic goes, the M2 should be capable of capturing at extremely high bus load with very little frame loss. I’ve tested right up to around 4000 frames per second and had a couple of frames drop. It’s tough to get zero loss at near 100% bus load but it’s fairly close. At normal traffic loads (1000-2500) it doesn’t drop any. Realistically, I don’t know that I’d say the P1 could be any better here. People always think that faster processors = better reliability but such isn’t entirely the case. Once you quit running bare metal and go to a full operating system you lose some of the ability to quickly respond to hardware events. Thus, a full linux machine isn’t necessarily faster at low level tasks than a slower processor with firmware running straight on the processor. The M2 uses a processor where the CAN module is straight on the MCU die. Access to it is at full processor speed. If it drops frames either the driver programmer messed up or there was a bus fault. The hardware itself is more than fast enough to handle full load of both CAN buses at 1M. It’s all down to software on an M2.

#11

I’m a bit surprised about the P1, I understand we pay a heavy price for the abstractions that a kernel and OS provide, but I’d expect that kernel drivers would still respond to interrupts promptly and buffer received frames until my code reviews them at its earliest convenience. In the P1 case, are the CAN modules on the little adapter board between the M2 interface board and the PocketBeagle?

That’s great to hear about the M2. Some might say I’m too good at optimizing…
optimization

#12

Keep in mind, I’m not disparaging the PocketBeagle here. It probably keeps up pretty well with CAN traffic. I’m just saying that sometimes people think that the use of a >1GHz processor is going to magically make things work super reliably and quickly and that’s not necessarily the case. But, the PocketBeagle has a lot more horsepower for processing so it’s still a great option. The PB is fast enough that you could run python on it and still probably get the kind of speed you’re looking for. That isn’t something I’d recommend trying on an M2. Probably the nicest thing about PB is that it does also have a CAN module on board and it runs linux so you can use any socketcan compatible program. Quite nice and I don’t see any reason it wouldn’t run sufficiently well. But, the M2 should run full speed too because it’s bare metal and the CAN module on it is built into the processor so sending and receiving frames is extremely fast and efficient. I guess all I’m really trying to say is that the ability to capture and send CAN traffic at high speed between an M2 and a PB with P1 is likely not as much as you might think. But, since the PB has so much else going for it it’s a great option.

1 Like
#13

One thing about the P1 that I don’t know if it is utilized or not is the dedicated co-processors. It has two dedicated Processors that can be used to do simple real time processing. These could be used to pull the data from the data stream and do some initial processing before sending it to the ARM processor for usage. Using these dedicated co-processors allows real time data to be grabbed at high rates of speed. Likely beyond the fastest times currently available.

#14

I’ve been using an M2/SuperB combo for my Tesla project for over a year now @froghorn, and the experience has been very good.

I log all activity to an SD card from 2 CAN buses using a single M2 with no problem at all (about 2k CAN msgs / sec, almost no jitter even for 10Hz msgs, and no drops). Simultaneously, I’m doing some decoding on the M2, answering commands to monitor and transmit messages received from “clients” over the SuperB’s BLE or wifi connections, and of course transmitting message data to clients in real time.

The SuperB is pretty finicky, and running both BLE and Wifi is taxing for it. A big downer is that it doesn’t have enough horsepower to run TLS in wifi mode, and maintain the ~100 msgs / sec no latency I need in car. When I had it doing secure web socket early on, the lag and jitter was terrible. That said, it’s the only XBee BLE device I found that you can write your own BLE protocol, which was something I wanted to do. For now, I’ve disabled the wifi and have stellar performance from BLE.

The M2 on the other hand seems to take everything in stride. It’s so nice to be so close to the metal.

The developer experience is really good too (which I think is important for a hobby!).