openXC support?

Developer Projects
#1

Is anyone here interested in OpenXC support? And is this even possible?

At some point soon I am considering trying to build in OpenXC support either directly into the M2RET or a separate unit that JUST replaces the M2RET.

Just beginning research on this and would be after I have at least something going with the J1850 stuff.

With OpenXC the interface device basically stores the PID’s and does all of the heavy lifting. There are different modes but the simpliest mode basically the OpenXC asks for something and the interface returns the result for it. A little higher level than what we normally are used to. But allows a manufacturer to normally embed the proprietary information within the firmware.

I am considering different options with this and probably would set it up with support for the generic PID’s up front and load the vehicle specific PID’s from the MicroSD card upon initial startup after a Vin check. Concerned this might make a pause prior to the device running but hopefully there might be a way to load one unit into memory by default. (May store Vin and default ID of library to load in non-volatile memory but not sure if the effort would be worth it. )

#2

Is it possible? Sure, the OpenXC code is open source so you could look at that and port it over to the M2 hardware. Or, at least look that the communications protocol and copy it so that an M2 device appears to be a valid OpenXC device to OpenXC compatible applications.

Am I personally interested? No. The M2 already has an OBDII library that does the heavy lifting for you and polls PIDs in the background. With that you can do most of what OpenXC does. The only catch is that we don’t know any of the proprietary Ford PIDs so none of that is available unless someone figures it out.

I don’t mean to discourage you though. Maybe other people would like to see this. And, maybe it’s something you really want to do. By all means, if it seems like a good idea to you then give it a whirl. But, I think you might find that working with the ArduinoDue_OBD_FreerunningCAN library will be faster. The only advantage (that I can see) in making it OpenXC compatible would be so that you can use OpenXC enabled apps on tablets and phones with the M2. That might be something you really want to do.

#3

At this point I am only kicking around the idea of providing OpenXC support. Having some unexpected issues I am dealing with then back to the J1850 stuff which I intend to get at least up and running before pursing anything else.

My attraction to the OpenXC system is due to the fact it is a high level extraction. If you get the interface to work with the API on a particular vehicle then any OpenXC program should work. This is the only high level setup like this I have come across. The documentation on their site that I have seen shows it is intended for CANBUS usage but there is nothing in their documentation that I have seen that would prevent older ODBII or possibly even ODBI protocols such as ALDL to work.

I see a lot of traffic on the OpenXC mail group of people wanting to get it working with their older car which isn’t possible with any of the current solutions. So it is limited to vehicles roughly 10 years or newer.

How this would work is yet to be seen.
I suspect there will be two major decisions for anyone looking to add this support:

  1. Extend M2RET, or replace M2RET with totally new OpenXC based code.
  2. Building new code from ground up that supports the OpenXC, or port as much of the current setup as possible.

I suspect I would choose the new OpenXC code and porting as much as possible. But this is yet to be seen. May not pursue this but at least researching it for now.

Rodney

#4

If people are talking about wanting to use OpenXC with older cars then perhaps there really is a use for running OpenXC on the M2. After all, it can connect to those older cars. The best option probably is to create an arduino sketch that brings in the various bus protocol libraries and then implements the same protocol over bluetooth as the base OpenXC devices use. I’m not sure I’d extend M2RET as we’ve already kind of gunked that code up with 14 different protocols already - it has GVRET ascii, GVRET binary, LAWICEL, LAWICEL2, logging to SDCard. I think I started to add bluetooth support too. That’s a lot of communications options in a single sketch. :wink: So, it’s probably best to build from the ground up or fork M2RET and tear out all the existing comm options, replacing them with the OpenXC comm protocol.

#5

I guess I need to get the J1850 stuff going first and then start digging into M2RET. I think I understand the Canbus driver decently now.

I may evaluate restructuring M2RET with the M2 in mind and go from there. I know how small projects end up as big clunky projects after you keep adding just one more feature… Might be the best path to getting other things working such as OpenXC and allow end users to strip out unnecessary features for their projects.

For me the J1850 is important as I want to build an interface to control my truck with it. I have an integrated Scantool STN device currently that is to be hardwired into my truck but I could certainly piggy back the M2 onto this too. Eventually replacing the STN device.

I will be looking more into this though in the future as I get more familiar with the M2 hardware. I think it could be a great addition to the M2 stuff. I also want to expand the ELM emulation to incorporate the superset STN command set too so I can use my STN based software with my M2.

#6

Started peaking at the M2Ret stuff in more depth. I can see where portions should probably be stripped out but not 100% sure what I should do for them yet. I am looking at potentially splitting the M2RET into parts that can be used on their own.

The Logging, Serial Console, EEPROM are candidates right now to strip out on their own.

The sys_io module MAY be something to move to its own as well. I have to look at it more.

Basically I want to isolate items that can be used by other setups and partition them off and simplify M2RET. I want to peel off the serial connection and isolate if necessary to make it easier to tie in support for the BLE and other devices. I am still looking through the code when I can to learn what its doing so it will be easier to integrate code when I get other interfaces working.