search

eclipse-kuksa / kuksa-hardware

Apache License 2.0
18 stars 7 forks source link

STN2120 not produced anymore #11

Open lebuni opened 1 year ago

lebuni commented 1 year ago

As already mentioned in issue #10, the STN2120 is difficult to get.

I contacted OBD Solutions and unfortunately they're not producing the STN2120 anymore and also don't have stock left. What could be an alternative?

Hi, STN2120 is a bit of a challenge. It was over 5 usd a pice (but we only ordered small quantities).

Main issue is, there is no second supplier. I suggest contacting https://www.obdsol.com/ (the manufacturer) directly. Depending on their availability maybe some of their other variants may be available, if pin compatible (not sure)

CanoPi itself can boot without OBD chip as well, however it is one of the most accessible features for developers,to get data from OBD directly by just plugging the dongle in without having to „cut CAN Lines“. So just leaving it out is probably not a good option

Theroetically an ELM327 (clone) could be used, but that demands a change in PCB Layout, i.e. changing the Altium files. While the STN are software compatible with ELM327, they are not drop in replacements from hw layout perspective. We have so far never looked into this.

SebastianSchildt commented 1 year ago

Sorry for late answer, was unavailable the last 2 weeks. If STN2120 is really dead, I think this needs a hw change. I google a bit, but not yet a good solution. So all those ELM knockoffs on Ali & Co are based on pic18f25k80, the issue seems (except availability and quality), those are only are always complete hw solutions, not IC only. I did no find any vendors selling preprogrammed ICs only. When redesigning for the PIC only, we would need a firmware (and also an ability to flash it), and distribute or link it. That might be an issue, because I guess the origin of the firmware in those adapters is a bit shady.

As we currently only support CAN-based OBD we might also just add another CAn transceiver, or allow or rejumpering one of the existing CAN interfaces. The main issues is, for ELM327 adapters there is a LOT of software around, doing OBDII "by hand" via socketcan, has much less support, and I did not find a "ELM327 wrapper/emulator" on top of raw can interfaces, only found this https://github.com/ejvaughan/obdii but that is a bit old and untested, and NOT compatible with common Linux OBD tooling.

In both cases we would loose the deep powerdown/STN based wakeup capability I guess, but that is likely a feature we can live without.

But really searching for ideas/suggestions here

SebastianSchildt commented 1 year ago

Some things hence discovered

On a side note, this is interesting: https://www.upwork.com/freelance-jobs/apply/OBD-UART-Interpreter_~0137c6c1b584e62441/ Others having the same pain? This basically is asking for a reimplmentation/carbon copy of the STN things. Not sure, that is ok....

SebastianSchildt commented 1 year ago

We are looking into this https://github.com/uholeschak/ediabaslib/blob/master/docs/Replacement_firmware_for_ELM327.md#programming-elm327-adapter-with-deep-obd-firmware , they also provide a ELM compatible firmware (https://github.com/uholeschak/ediabaslib/tree/master/EdiabasLib/CanAdapterElm/CanAdapterElm.X)

Currently acquiring some off the shelf PIC18F25K80 based adapters to check whether fw is suitable/works. If successful, it might be an option to redesign that part of CANOPi with PIC18F25K80