Building ELM/STN/lawicel 2.0 support

Developer Projects
#1

I wanted to start a fresh thread on this since with J1850VPW now working I want to start looking towards full ELM327 / STN compatibility. At the same time I will be building in full Lawicel 2.0 support as I go.

For those that don’t know the difference. STN is an extension from the standard ELM327 protocol. The reason for this is that with this compatibility the M2 will work with ANY ODBII software.

This thread is to track that progress.

So I want to compile information about the different protocols in this thread as I research the work I will need to do. My ultimate goal is to be able to use an M2 in place of my Scantool cable to run the software I already own. This can be expanded upon once it is done.

I am looking for links to working projects so I can look at implementing them.

Canbus/Swcan will be taken from Collin’s github at collin88
J1850VPW I will put up my own repository based off Ben’s modified library at redheadedrod/j1850

Any others?
Thanks ahead of time!

Probably should have a wiki page somewhere or something that has links to all known projects related to the M2 to make it easy to track them.

#2

Are these all of the known protocols that now work?

http://showcase.macchina.cc/libraries.html

#3

They are! We are working on cleaning up the showcase.macchina.cc pages to organize a little better, but this is where we’re keeping track of libraries and projects.

Feel free to do a pull request if you want to add or change anything:

1 Like
#4

Feel free to make pull requests: http://showcase.macchina.cc/projects.html :slight_smile:

#5

Here is a project that is somewhat related. Although it is not directly compatible, maybe it will be helpful:

#6

Ok now that I have verified CANBUS IS working on my lab now along with J1850VPW and I have the ESP32 unit working I can start working on this.

After thinking this through I am going to try to accomplish this goal in the listed steps… Some may overlap a little…
And where M2RET and ELM/STN/Lawicel support conflict I will have to discuss with Collin how to best handle the conflict.

  1. Build ESP support into M2RET. Hopefully BT will just show up as a COM port on the PC which makes it real simple to have SavvyCAN support.
  2. Make sure Lawicel 2.0 support is in place and expand it if necessary for CANBUS/SWCAN first since it is already there.
  3. I believe Collin started working on ELM support but I will insure it is fully supported. Once ELM support is done I will continue on and add full STN support as well. To quickly develop this I will start with just the already integrated CANBUS/SWCAN.
  4. Start adding other protocols. J1850 VPW will likely be first but the current driver will have to be modified to work.
#7

Hey Rod, are you still working on this? I would be very interested in helping out with getting the STN emulation up and running.

#8

I have to finish some class related work but I have a direction I am going if you want to discuss offline.

My intent is to take the current firmware and build a system of plugins that will allow one to easily add new protocols and such. Going on Vacation for a week the first week in May. When I get back I will be digging into this more again. I also have been working 50-60 hours a week for the past 2 months.

I have a basic structure built and hope it will only take me a month of dedicated time to build the framework to a point to duplicate what the main system does now. I can discuss this with you what I plan to do if you want to work on the emulation stuff now. Atleast get it working to a point it will be easy to add into the system I am doing.

The idea with the different protocols is to build a class which will have basically 4 main features.
Data in from the user, from the car, settings change, startup.
Everything else will be handled within the class using these four external functions.

Data from the car will be reformatted for the user and sent to them based on the protocol.
Data from the User will be looked at for commands and those commands will be handled within the class. Any sort of settings changes would be kept within class variables.
The settings is to allow the firmware to change settings if necessary.

Upon initialization of the program it will take any user data and sent it to the startup function which will look for compatible commands to the protocol.If no commands are compatible it will return a negative. If they are it will return a positive response. This will allow support for multiple protocols by simply watching for what its doing. Once it finds a compatible protocol it will use that for the rest of the time the unit is powered up.

I have in mind like 4 different protocols that can be included initially. And if you were to build the ELM stuff to be compatible it will likely just plug in with little modification. But we can discuss offline. Should be able to make work with current software and be able to just plug it into the new stuff I am doing.

#9

Sounds good Rodney. Happy to help however I can. You can catch me at perrymail2000 at yahoo.