Gripless

Pretty much. The board and chip can read any can up to 1Mb/s speed what you do with it is open to how much coding you can do. The ESP32 that it’s based one has built in canbus support so it’s not as complex as it appears. I’ll have some basic framework coding for it, along with the web config examples. That way there is no need for an app as the ESP32 can be a wifi access point and you connect to it, and it shows the settings. I have two prototypes running on the OEM stock canbus. One does rpm shiftlight the other is DCCD display. The tire pressure one hasn’t got off my desk yet as it has an annoying mounting system but it works, mostly. There is no discovery scan yet, you have to know the max addresses of the sensors. There is another bigger display that is popular CYD 2.8” with touch control for NZD$15-30 as well, that seems like it maybe a good idea to do as well. Power and canbus would be 1/4 to 1/3 that board the rest could be holes for whatever other electronics.

Have a week or two before the first version turns up and no improvements to make until I can test the board. In the meantime I had the idea I could adapt what I have to a board that plugs into this… https://www.aliexpress.com/item/1005008877505362.html that way it’s really cheap to have a canbus connected mini display. Anyone can cut or print a custom front panel or mount it behind a small cutout. Only a few screws hold it together which makes it simple to assemble. Being shipped from China as DIY no need for certification like CE or FCC for radio(wifi) devices. That board already has 3 usable buttons (plus reboot) and 3 spare in/out with serial port. 2 is enough for canbus board. It has place for power in so I just need to do a 12v to 5v section and the protection circuit.

Boards have the pins labelled and aren’t locked to custom firmware so can be reprogrammed by anyone. So far estimate around NZD$50 with the LEDs in case as shift light. Main 3 chips are around USD$9

Well ordered the first circuit boards for prototype 4. WTF cost was USD10 shipped for 10 custom boards. It is insane what you can fit into a tiny space. The board is 20x76mm and max 5mm high with all these features: now 1cm longer and added reverse polarity protection. Plus no need to replace diodes for 24v vehicles. fuse, self resetting short-circuit aka reverse polarity protection 12/24v switch mode power supply for low heat 90% efficiency Just need to swap the fuse for use in 24v vehicles Optional ign switch input to power up Electrical power noise filtering Electrical filtering ADC pins Spare 5v and 3v3 volt outputs 4x static (ESD)protection for buttons and knobs etc 12 general purpose input/outputs Current generation CAN 2.0 controller with listen real listen only mode. CAN bus noise filtering, ESD and voltage spike (TVS) protection optional canbus termination for aftermarket ecu 2nd bus use. ESP32 module with dual core cpu, wifi and Bluetooth connector for firmware update and Arduino IDE supported This is massive overkill and parts are high spec low tolerance ones. board can run as almost anything, supports full LCD displays etc. Adding web configuration for colour of each led and rpm it triggers at, mostly done. You can set can ID and bytes via web to look at so supports most cars and aftermarket ecus. Also want to add an aftermarket mode that allows ecu to do some cool things that I have seen any other product do.

Surprising those alpine units should sound pretty good on their own.

Ramble CAN bus Data is only what is needed for other devices to know. Eg ECU sends RPM as dash and transmission needs this data. The ECU won’t send fuel trim or timing data as nothing else needs this. There are different versions of canbus originally for higher speed, but they added fault tolerance and then flexible data rates. most Subarus run at 500Kb per second for the main canbus, newer models can be faster and also have a secondary slow fault tolerant canbus. The connections design is a single main path with short branches to each device, so everything on the bus can gets every message. This is becoming a problem as since everything shares and talks at once things get saturated and messages between lost. You see this mostly when adding OBD2 devices to 2014/16 or newer cars. There are also audio and video over canbus as options. Each message, packet or frame as it’s all just the same as any other network has an address and data. Nearly every device on the network that sends or receives data has an ID or address. Some devices have no address and passively listen eg a canbus sniffer to usb or Bluetooth often does this. This is called: normal - send, receive and acknowledge message etc no ack - send and listen, but don’t acknowledge messages received. listen only - mostly true where data is passively read and nothing sent it only applies to regular can messages. Many transceiver chips still send error state etc on boot up without any input. Different parts have different options. This isn’t much of an issue if the device starts with the ignition as 0.3 seconds of errors on a bus won’t be a problem as nothing much is happening when you turn on the ignition. Once running starting devices is not as ideal and starting a few is sequence could though unlike cause fault codes. The cost increase can be USD$1 per chip to support true passive listen only compare to the older chips. Physically similar to balanced audio it runs on a pair or wires with one the signal and the other the same signal inverted. The wire are twisted around each other the same as balanced audio so any external electrical interference or noise gets applied to both wires at the same time and intensity as possible. At the other end the inverted signal is flipped back to normal and added to the signal. This doubles the signal, but any noise is mostly cancelled out. Really the inverted signal is still positive but the zero point is 2.5v and signal is +-1v OBD2 Is often send over canbus in the same way as other messages just that they have a set ID they should be and a set ID to send messages to, eg ECU. Depending on the car it can go over the other K or L lines on the diagnostic port. This isn’t passive the OBD2 device requests data, firstly it should ask what the ECU supports eg timing, fuel trim etc etc. Then it can request some or all of that data. Many aftermarket devices spam this request as fast as they can up to the limit of I think 100 times per second. The data supported is a standard agreed list and only part of the data the ecu etc may have. To get all the data Now this is allowed and in spec, but if you add more that one ODB2 device eg a gauge or scanner along with say a stereo that also shows data you can overload the canbus which will then give you random fault codes and make life hard. Chasing these faults will cost you a lot as unless the tech is looking for OBD2 stereo and multiple gauges etc they will replace expensive modules trying to eliminate the fault. SSM Subaru’s own protocol for communication over whatever bus is in the car. Newer cars it’s over canbus, older over K or L lines. It has access to data from most bigger devices eg ECU, abs, body module etc, where OBD2 standards don’t apply. Eg eyesight or radar etc. This can also program devices with new codes eg keys, or unlock features like cruise control in the ecu. The benefit other than key coding is most data the device/module has can be requested. You may what per injector trimming or pulse time for an injector details not in OBD2. Maybe even the temperature or load on the processor in the module, whatever Subaru wanted to add or know for diagnostics or testing is there. K and L lines These are basically serial ports over a single wire commonly called LIN. They are slow and old but can be very useful. Depending on the car a standard serial port wired for both send and receive to the same wire can send data. Just don’t expect a modern laptop or USB converter handle the voltage. Serial ports for PC is 25v but mostly it is 5v with modern devices. Both OBD2 and SSM can use this bus for communications. Gateways and filters Newer cars don’t allow the diagnostic port to connect directly to the ecu or other modules. They have a device in between that limits the rate and type of request that you can make. This mostly protects the car from damage and theft, but also limits the owner from running diagnostics and clearing codes. Eg it may allow OBD2 requests for RPM and fault codes, but block the ability to clear them, or not even allow fault codes to be read at all. These are often easy to bypass and not really an issue.

Only sti specific stuff I know of is DCCD and G-force sensors. working on some PCB design bits and updating to use the newer canbus chips. Adding a thermocouple circuit as a test and they cost way to much.

Likely the alternator has a replaceable rectifier unit inside. some can even be disassembled and individual diodes replaced.

How old is the battery? then there’s always the rectifier on the alternator, they can go bad. either of those only show up under load to start with.

Do you get high idle when cold start or when moving power steering at idle? if that works then maybe it isn’t bad. sounds like a bitch to deal with too. https://forums.nasioc.com/forums/showthread.php?t=781242 i haven’t done the Subaru one but mid nineties mitsi had those same screws and I had to drill them as the screw heads failed.

1) What’s the battery resistance when you unplug the ecu? 2) what’s the idle stepper motor resistance like? If it’s off throttle coast th ecu should be adjusting the stepper motor to keep rpm on target. You should get matching resistance between the pair of pins that are coils.

Ok… 1) what sensor do you have for the TPS and idle stepper do you have the pin out diagram so you can test them correctly. 2) are you following the TPS install procedure if the sensors are secondhand? Depending on the model they can rotate too far or past full or zero. That can upset the ecu it the tps reads closed but the switch reads open. When you test drive are you only using low throttle? Once fitted test the resistance stays nice and linear from closed to open, and then retest the closed to open the closed switch is only when closed. 3) have you cleaned the connector and if needed put small cable tie around plug and sensor. You need to check the ecu end as well. Plus check the ecu end run an extra wire to the sensor plug and shake the wires incase there’s a break that gets exposed. 4) for the battery are you sure the terminal isn’t touching something while it’s pushed back like that?

Made a few little changes and fixes. better canbus ID filtering imcreased processing speed watchdog timer that reboots if no can rpm data for 10 seconds Small memory leak found that caused issues after 4-5 hours at 2000 packets a second. added tiny 1cm wide OLED screen for status information. Looks like prototype 2 will be viable for use. The only remaining issue is triggering the power on and off, but that could be all software sleep. After that is for other people to try it and get feedback

Tested and working. 25x225mm with 40 led 17x182mm with 32 led options to set via wifi redline flash warning after redline flash rate/speed minimum rpm to turn on eg off until 3000rpm. Rescales led so still uses al of them. pattern. Single line, inside to out, outside to in. colour palette thinking of adding canbus id via wifi so can be any ID, plus can send messages from aftermarket ecu telling it how many LEDs to turn on. That way a table or math block in ecu can control it.

Working on prototype 2 for shiftlight. Prototype 1 was a bench top proof of concept and was just wires with alligator clippers connecting everything. This one is fully cased with OBD2 connector, and buttons to activate wifi for settings and turn off display etc. There are 3 options on how to connect the display and sensor to the control box, and where the button(s) are. This one is 3 buttons in the back of the led bar.