[MTCB Android Head Units Q&A] darkspr1te:
Thanks, I had come across that one and apart from the logcan function most of the other stuff is not valid in this application.

I intend to aim primarily at the protocol between Head unit and CANBOX, not CANBOX to car (as i'am sort of covering that elsewhere) , the CANBOX to car part is one hell of a rabbit hole to go down , not only are varied high level terms thrown around incorrectly or misunderstood in a lot of articles but as soon as the document gets to a level of understanding the information drains off as the commercial applications come forward, imagine cartoon authors eye's turn to ($) ($).

Thats why you dont see much in the way of good open source OBD stuff thats not tied into a specific hardware circle or device type.

J2435 is sort of opening that up but in a poor way, they hiding the CAR part behind a device again so again we dont know what the device is saying to the car.

This is why i wont be really covering much on the car side but more in how we can replicate the canbox functions first of all.

I already have a POC that talks to a ELM327 device via wifi or BT, only the programming the esp2866 lacks full understanding of the car as i have JDM cars, not only is JDM protocols different from euro/US counterparts but the also have sub -divided protocols where a euro/us function will work on 2006-2007 model but not 2008-current, who knows why but that is the way of it.

I also do have some additional information on the protocol that i've have to digest, the last bytes are CRC8 EDIT:twos compliment crc see below, i've confirmed that, so we can calc on fly or use look up table for speed, I also have seen this protocol in my research before into another subject but i cannot place it yet, the $2e start byte is the giveaway and followed by function High byte and low bytes and then data and finally crc, Maybe i'll remember it before someone else does, but we have the base part of the protocol and i already have a POC code that is usable on many devices due to being arduino in nature(just not arduino ide but thats a coders choice),

Now as we already have a schematic floating around with full BOM we could in theory make our own canbox but when checking I found it's based on STM8 which is a older chip and I'am personally more familiar with STM32F series and atmega, sam4c etc so i may re-produce the board using that. Also all of my current in stock hardware that has canbus is all stm32f.

Now some of you might have spotted my glaring mistake, I want the code the to work on anything but i'am building it using stm, well thats only due to the fact i have a quite a few stm's to sacrifice , once i know the code works (HU to canbox & canbox to car) then i can introduce other brands of MCU once i have a validated test bench. What will vary device to device is how you Initiate the CAN, with stm32 chips they have bXcan drivers in f103 chips, for atmega we can use spi based canbus driver chips. Supporting those two functions will be enough to pull in esp/atmega/LT and many other chip makers should someone want to port to their fav brand of chip.

I would also like to support non-obd cars , sensing door open is not that hard and a simple arduino+level converter you can sense doors, speed and more. there's also a few after market steering wheels that have vol dials as wheel as custom car builder wanting to use a wheel from brand A on brand B , who am i to judge where you got your real Lotus F1 wheel from.

Now we do have to cover one subject thats often missed in these discussions, OBD and all it's cousins was ment as Diagnostic first, which means not all cars are happy having a dongle full time on the OBD port, I've seen cummings based vehicles refuse to start unless the OBD is unplugged first, that means the dongle is introducing noise on to the bus, be it in the form of legit data request, eronus data or real electrical noise from not having the BUS resistor .

edit: while trying to solve this "ive seen this before" problem I did find this, very similar,

https://www.peak-system.com/produktcd/Pdf/English/PCAN-LIN_ProtDef_eng.pdf

darkspr1te