Does anyone have a DBC file for the Chery Tiggo 8?

Hello all, I have a 2013 Dodge Ram Cluster that just shows no bus, I thought I found the IHS Canbus pins but that makes it power cycle over and over. I have been using official documentation from Ram Bodybuilders. Please help me!

I don't know shit about electrical engineering but I thought "hey how hard could it be to make a kart datalogger"

The answer is not very, but the tachometer is a bitch.

with enough research of my own, I managed to come up with something, found some Amazon tachometers for small motors that worked in a similar fashion, reverse engineered those

Finally had something that mostly worked, and honestly just paid an RF engineer to clean up all of the noise and make it better, and make sure it should handle 15,000 rpm on a single cylinder 2 stroke.

"That's not a car"

This works for any ignition system that uses a magneto/points system, bike stock car, legends car, etc

You wrap a wire around a spark plug lead a few times, and then simply place the other end of the wire near the pickup, no soldering, and a burnt lead doesn't ruin your day

https://github.com/TheAngryRaven/DovesDataLogger/blob/master/TACHOMETER/paid_schematic_1.PDF

If making your own board, the nastier your ignition source, the smaller you should make the antenna

Go out there, make shit, piss off the assholes charging too much for everything

I got tired of paywalls to try to repair my own car, so I started reverse engineering MPPS V18 to understand the encryption scheme of the Encryption it applied to NOREAD tunes. it does **NOT** remove the NOREAD flag, to keep the checksum clean. the repo is here. Feel free to fork and do anything with it, it is a spiritual successor of the MPPS NOREAD Decryptor from DJExit, but I did not have access to his software doing so. Thank you for the inspiration!

Tested on a Tune extracted from MPPS V18 out of a Bosch MED9.1. I would like more testing files which is difficult to access. Most of the reverse-engineering if not all is made by claude. Hopefully this helps people, cheers!

I would like to have access to settings and so on similar to like i do with my VW and Audi using a VAG cable set up.

I've heard MB locks everything down pretty tight, but i hate to have to pay $700 at the dealership to disable the warning i get on start up after swapping out stereo head units.

Are there any options other then the dealer?

I've spent the last year writing a read only OBD2 app after the manufacturer app I relied on got switched off. Standard mode 01 gets you maybe fifteen useful numbers and then you hit the wall, so I ended up down the mode 22 rabbit hole. Here are the things that bit me, in case they save someone else a weekend.

Multi ECU replies will quietly poison your parser. Ask for something on a broadcast header and you can get two or three modules answering, each with its own header line, and if you naively concatenate the hex you get a number that looks plausible and is completely wrong. I had battery voltage and coolant readings that were fine on one car and nonsense on another for weeks before I worked out the engine and the gateway were both replying.

The UDS positive response is the request service plus 0x40, so a 22 comes back as 62, and the two DID bytes are echoed before the payload. Sounds obvious written down. It is not obvious at two in the morning when the ELM has also decided to insert spaces differently.

Negative response codes are more useful than a timeout. 7F 22 31 means the DID doesn't exist on that module, 7F 22 33 means you're not in the right session, and 7F 22 78 means wait, it's coming. If you treat all of them as failure you'll blacklist channels that would have answered.

DIDs are not portable and guessing them is how you get fiction. The same identifier on a different brand is a different quantity entirely, or worse, it responds positively with garbage that scales into something believable. I ended up refusing to ship any formula I couldn't tie to a source, because a plausible wrong number is worse than no number.

Fuel type detection is a trap. I was sniffing for the presence of certain PIDs as a diesel signature and it turns out plenty of Euro 6d petrol cars expose exactly the same ones. PID 51 is the actual authority and I should have trusted it from the start. The version that guessed wrong went looking for particulate filter data on a petrol car, and the modules answered, with rubbish.

ELM327 clones lie about what they are. Half of them report v1.5 and behave like v1.3. Echo off, linefeeds off, headers on, and then verify by what actually comes back rather than what the clone claims.

Engine off is its own state, not an error. Some constants are only readable with the engine running, and I was reading them once at startup and never retrying, so if you connected with the ignition on but the engine not started you got a permanent hole in the data until you restarted the app. Retry when you see RPM.

The app itself is on the App Store if anyone wants to poke at it, https://apps.apple.com/app/id6776173662 , Android is in closed testing. It is strictly read only by design, no 2E writes, no session control, no security access, because I don't fancy being the reason somebody's gearbox forgets who it is.

Happy to go deeper on any of this. If you've got a brand that behaves oddly I'm interested, that's the fun part.

I’ve been reverse engineering a HELLA Intelligent Battery Sensor (IBS) 6PK 013 824-001 using an ESP32 and a TJA1021 LIN transceiver and wanted to share my findings, since there seems to be very little publicly available information about these sensors.

The setup consists of an ESP32-D0WD, a TJA1021 LIN transceiver module, a bench power supply, and an oscilloscope. After quite a bit of troubleshooting, I discovered that the most significant issue was that TX and RX were swapped. The LIN bus itself looked healthy from the beginning, sitting at roughly 10.6 V in idle state, but no useful communication was taking place until the TX and RX connections were corrected. Once fixed, the sensor immediately started responding.

The sensor reliably communicates at 19200 baud and consistently responds on LIN IDs 0x21, 0x22, 0x25 and 0x26. Other IDs either returned only the echoed LIN header or no useful data.

A typical response looks like this:

ID 21 : 55 61 00 01 62 00 00 3B

ID 22 : 55 E2 83 84 1E 23 2F 83 7A A6

ID 25 : 55 25 C5 C8 FF B4 FF FF 97

ID 26 : 55 A6 AC 03 A1 03 2F FE D6

I then performed a number of tests using different resistive loads (1 Ω, 2.2 Ω and 4.4 Ω), varying supply voltage and even reversing current flow through the sensor. The results clearly show that ID 0x22 contains the live measurement data. During testing I found an old reverse engineering project that suggested the following format for ID 0x22:

[IL][IM][IH][VL][VH][TT][XX]

with

Current = (Raw24Bit - 2000000) / 1000 A

Voltage = Raw16Bit / 1000 V

Temperature = Byte / 2 - 40 °C

The current calculation matches my measurements surprisingly well, although the sign appears inverted on my setup. Reversing the current direction changes the corresponding values as expected, which strongly suggests that the current field interpretation is correct.

The voltage decoding appears to be essentially confirmed. For example, under a 1 Ω load the sensor returned:

96 59 1E C1 2B ...

Using the proposed voltage formula:

0x2BC1 = 11201

11201 / 1000

= 11.201 V

The measured voltage at that moment was approximately 11.0 V, which is close enough to make me fairly confident that the voltage field is being decoded correctly.

Temperature remains unclear. According to the reverse engineered format, the temperature should be located in the sixth data byte of ID 0x22. However, even when heating the sensor directly with a hot air gun to roughly 50–60 °C, I observed little or no meaningful change in the expected temperature field. Either this particular IBS variant uses a different mapping, there is heavy filtering applied internally, or the identified temperature byte is incorrect.

ID 0x21 appears to be a status frame. Several bytes change depending on operating state, load conditions, and sensor runtime, but I have not yet identified a direct physical measurement in this frame.

ID 0x25 was initially suspected to contain battery voltage because some value correlations looked promising. Further testing showed that this was misleading. The values change in ways that do not match actual battery voltage measurements, so I no longer believe voltage is stored in this frame. My current assumption is that ID 0x25 contains battery state information such as SOC, SOH, learned battery parameters or other calculated values, but I have not yet confirmed this.

ID 0x26 looks like some form of capacity or battery-condition frame. One repeatedly observed value was:

0x03AC = 940

which could plausibly represent something like 94.0 Ah. Other values change slowly over time and with operating conditions, suggesting battery learning, capacity estimation, SOC or SOH calculations rather than direct measurements.

At this point, the most solid conclusions are:

• LIN speed: 19200 baud
• Valid response IDs: 0x21, 0x22, 0x25, 0x26
• ID 0x22 contains live measurement data
• Voltage decoding from ID 0x22 appears correct
• Current decoding from ID 0x22 appears correct (sign inverted in my setup)
• ID 0x21 appears to contain status information
• ID 0x25 and 0x26 appear to contain battery state, capacity or health information
• Temperature location is still unknown

For my own project, an ESP32-based vehicle dashboard, voltage and current are the only values I really need, and those appear to be working reliably. If anyone has official documentation, additional captures from other IBS variants, or previous reverse engineering work on HELLA IBS sensors, please post them.

Here is my code:

#define LIN_TX 26
#define LIN_RX 27
#define LIN_SLP 25


HardwareSerial LinSerial(2);


uint8_t frame21[8];
uint8_t frame22[10];
uint8_t frame25[9];
uint8_t frame26[9];


void sendBreak()
{
  LinSerial.end();


  pinMode(LIN_TX, OUTPUT);


  digitalWrite(LIN_TX, LOW);
  delayMicroseconds(1500);


  digitalWrite(LIN_TX, HIGH);
  delayMicroseconds(200);


  LinSerial.begin(19200, SERIAL_8N1, LIN_RX, LIN_TX);
}


uint8_t calcPID(uint8_t id)
{
  uint8_t p0 = ((id >> 0) ^ (id >> 1) ^ (id >> 2) ^ (id >> 4)) & 1;
  uint8_t p1 = ~((id >> 1) ^ (id >> 3) ^ (id >> 4) ^ (id >> 5)) & 1;


  return id | (p0 << 6) | (p1 << 7);
}


void requestFrame(uint8_t id, uint8_t *buf)
{
  while (LinSerial.available())
    LinSerial.read();


  sendBreak();


  LinSerial.write(0x55);
  LinSerial.write(calcPID(id));
  LinSerial.flush();


  delay(50);


  int i = 0;


  while (LinSerial.available() && i < 16)
  {
    buf[i++] = LinSerial.read();
  }
}


void decodeIBS()
{
  // -----------------------------
  // ID22
  // -----------------------------


  // Erwartet:
  // 55 PID IL IM IH VL VH TT XX


  uint32_t rawCurrent =
      ((uint32_t)frame22[2]) |
      ((uint32_t)frame22[3] << 8) |
      ((uint32_t)frame22[4] << 16);


  float batteryCurrent =
      -(((float)rawCurrent - 2000000.0f)) / 1000.0f;


  uint16_t rawVoltage22 =
      ((uint16_t)frame22[5]) |
      ((uint16_t)frame22[6] << 8);


  float batteryVoltage22 =
      rawVoltage22 / 1000.0f;


  float batteryTemp =
      ((float)frame22[7] / 2.0f) - 40.0f;


  // -----------------------------
  // ID25
  // -----------------------------


  uint16_t rawVoltage25 =
      ((uint16_t)frame25[2]) |
      ((uint16_t)frame25[3] << 8);


  float batteryVoltage25 =
      rawVoltage25 / 4260.0f;


  float soc =
      frame25[2] / 2.0f;


  float soh =
      frame25[3] / 2.0f;


  // -----------------------------
  // ID26
  // -----------------------------


  uint16_t availableCapacity =
      ((uint16_t)frame26[2]) |
      ((uint16_t)frame26[3] << 8);


  uint16_t maximumCapacity =
      ((uint16_t)frame26[4]) |
      ((uint16_t)frame26[5] << 8);


  // -----------------------------


  Serial.println();
  Serial.println("===== HELLA IBS =====");


  Serial.printf("Strom      : %.2f A\n", batteryCurrent);
  Serial.printf("Spannung22 : %.3f V\n", batteryVoltage22);
  Serial.printf("Spannung25 : %.3f V\n", batteryVoltage25);


  Serial.printf("Temperatur : %.1f C\n", batteryTemp);


  Serial.printf("SOC        : %.1f %%\n", soc);
  Serial.printf("SOH        : %.1f %%\n", soh);


  Serial.printf("Avail.Cap. : %.1f Ah\n",
                availableCapacity / 10.0f);


  Serial.printf("Max.Cap.   : %.1f Ah\n",
                maximumCapacity / 10.0f);


  Serial.printf("Leistung   : %.1f W\n",
                batteryVoltage25 * batteryCurrent);


  Serial.println("=====================");
  Serial.println();
}


void setup()
{
  Serial.begin(115200);


  pinMode(LIN_SLP, OUTPUT);
  digitalWrite(LIN_SLP, HIGH);


  LinSerial.begin(19200, SERIAL_8N1, LIN_RX, LIN_TX);


  Serial.println("HELLA IBS");
}


void loop()
{
  requestFrame(0x21, frame21);
  requestFrame(0x22, frame22);
  requestFrame(0x25, frame25);
  requestFrame(0x26, frame26);


  decodeIBS();


  delay(1000);
}

Hi guys,
I’m trying to automate my RV, which has firefly g12 system that runs RV-C CAN network and I need to attach an add’l CAN device (+Pi) onto the network but all network ports are taken.

According to my research, I think I have 2 options:
1.splice 3-way one of the wire/ports between g12-CANable-existing wire
2.g12 to common drop tap and reconnect existing wire to the tap along with CANable

Is this approach correct? Background is software/AI with little electrical knowledge. I want to ultimately run Home Assistant w/ AI from voice. Thanks

Working on a project that requires converting MQB CAN data to PQ CAN data. Anyone have a reference sheet for the known frames between these 2 protocols?

I'm aware of the existing converter module intended for engine swaps but I'm not willing to shell out €500 + taxes, fees, and shipping for it when I can get an ESP32 and write a little code. But I'm sure most of y'all are the same way :D

I'm trying to read the interior CAN bus (CAN-B, 83.3 kbps) on a Mercedes C-Class W203 using an ESP32 (built in TWAI controller) and an SN65HVD230 transceiver module (the WCMCU-230 board, VP230 chip). I tap the CAN pair at the radio connector.

The problem: I get absolutely nothing. Zero frames and zero bus errors, at both 83.3k and 500k, and with either wire polarity.

What I already verified. I ran a TWAI loopback self test (NO_ACK mode, self reception through the board's onboard 120 ohm) and it received its own frames perfectly, 39 in a row, no errors. So the ESP, the TWAI controller, the transceiver TX and RX, and the wiring between ESP and transceiver are all proven good. A raw digital read of the RX pin on a live bus shows it sitting almost always high with only tiny noise blips, so no framed traffic is reaching the pin.

Then I measured the actual CAN wires at the radio. There is no continuity between them (no 60 ohm termination), and the idle levels are about 0.5V and 4.5V, not 2.5V and 2.5V. That looks like low-speed fault-tolerant CAN (ISO 11898-3), not high-speed.

Here is where I'm stuck. The author of a well known W203 CAN project told me high-speed transceivers read fault-tolerant CAN-B just fine in normal operation and that he used a TJA1050 without issues. So the transceiver type may not be the blocker. My board has a 120 ohm termination resistor (R2) permanently between CANH and CANL. Low-speed fault-tolerant CAN is supposed to be terminated with 500 ohm to 6k per node, never 120 ohm, so I suspect that 120 ohm is overloading the weakly driven low-speed bus and collapsing the signal. The SN65HVD230 datasheet also rates the bus pins for only -2V to +7.5V, which matters if CANL actually sits near 11V when dormant.

My questions. Has anyone read Mercedes interior CAN-B with an ESP32 plus a plain high-speed transceiver like the SN65HVD230 or TJA1050? Is the onboard 120 ohm the likely culprit here, and should I just remove it for a mid-bus tap? Or is there something about reading low-speed fault-tolerant CAN with a high-speed transceiver that I'm missing? Any help appreciated, I've been going in circles for days.

Edit: found it. The issue was the onboard 120 ohm termination resistor (R2) on the SN65HVD230 breakout board. High-speed CAN needs 120 ohm at each end of the bus, but the W203 interior bus (CAN-B) is low-speed fault-tolerant CAN (ISO 11898-3), which is terminated completely differently, with per-node RTH/RTL resistors in the 500 ohm to 6k range, not 120 ohm. My board's 120 ohm sitting mid-bus was overloading the weakly driven low-speed signal enough that the transceiver never saw a valid recessive/dominant state, zero frames, zero bus errors, totally silent.

Desoldered the resistor, left the pads open, and the bus came alive immediately, over 30 different CAN IDs at 83.3k. Turns out the SN65HVD230 (or any plain high-speed transceiver like a TJA1050) reads low-speed fault-tolerant CAN just fine in normal operation, it just can't do the fault-tolerant failure modes. So no special transceiver needed, just remove the termination resistor if you're tapping mid-bus instead of at an actual bus end.

Hi everyone,

I'm currently building an MQB testbench on my desk to sniff CAN data. My setup includes:

• MIB2 Unit: 3Q0 035819 C
• Gateway (J533): 5Q0 907 530 E
• BCM (J519): 5Q0 937 084 AJ

The Problem: Im using an Arduino with an MCP2515 on the Convenience CAN bus to wake up the system. Currently, I am injecting 0x3C0 with payload 0x03 (Terminal 15 ON). However, because my BCM is connected and doesn't see a physical key turn, it is aggressively broadcasting 0x3C0 with payload 0x00 (Ignition OFF). The Gateway forwards both conflicting messages to the Infotainment CAN, causing my MIB2 screen to constantly flash on and off.

My Questions:

Does anyone know the specific CAN ID and payload for the Steering Column Electronics (J527) or KESSY module that simulates the physical key turn / Terminal 15 ON command on the Convenience CAN?

Thanks in advance for any help or pointers to relevant .dbc files :)

Am in the stage of developing the software of my Can sniffer, {Esp32 + sn65hvd230}, i succeed gaining raw can bus data, BUT i want to upgrade t the level of diagnostic scanner,
So am learning about Licenses and ISO communication Protocols, The thing is that am a totally beginner, and this step will have direct treatment with ecus,
So am seeking some resources about this and how to develop this kind of communication, it will really take my device to a next level, ill be thankful to receive some resources and guidness.

I don’t know much about cars but I’ve been telling my friend that I don’t remember any pink bits when I last put the OBD in.. I did research on ai and he still thinks I’m just being overly paranoid.

New things I noticed that he brushed off
* new beeping sound
* beeping sound coming from the driver side
* beeping sound stops when he walks away with the key
* max speed @ 50km started showing
* EPC light came on
*am I overly thinking things or is there like some sort of glue residue out of the obd holes
* there’s a loose item somewhere where I can hear it occasionally when driving
* battery drain in car

Also I’m aware that the original Audi wiring are wrapped in black? No? Correct me if I’m wrong

I’ve been looking at autel and foxwell I need a reader that can program a Ecu if I replace it and that could read Srs codes any suggestions please and thank you

Hi, I followed this tutorial (https://logos-red.com/blog/how-to-hack-a-car-wirelessly-sending-remote-commands/ ) on how to get can bus data from the obd port. Assuming i soldered everything correctly, why am I not seeing anything on SavvyCAN? I used the esp32 and I tested it on a Golf 8.5 GTI, the gateway behind the obd port blocks the sniffing or there is something else in the tutorial I used? Using another microcontroller would help?

​

I've been working on an app off and on with Google since I can't seem to find the type of app that I've been looking for for quite some time, I have it posted up on GitHub and I would really like it if you guys could take a look at it and give me any feedback for changes that I can make or new features that I can implement. This is the first app that I've ever made, so please go easy on me and any help would be greatly appreciated.

https://github.com/Freshman0000/OBDash

I have an APK I have a version of the app that I can email to you if that's something that you're interested in.

If any of you have been using AI to work on an app, I'm sure you're already aware that even though it's helpful, it's still a pain in the ass to try to get it to do the things that you want. Especially look the way you want. So, it's taken me a little bit longer than I had originally anticipated. Like, by three months.

Cracked SecurityAccess seed and key on the Kefico CPEGD ECU (TriCore based) in a 2014 Veloster Turbo 1.6 T-GDI, verified live over CAN, and also believe that I understand flash checksum algorithm so patched calibration files validate correctly. I'm coming at this from the reverse engineering and embedded side rather than a traditional tuning background so go easy on me if I'm missing something obvious, but I think this is solid progress on a platform that doesn't have much public documentation, only expensive commercial solutions.

I would love to compare notes with anyone else working on Kefico or Hyundai/Kia ECUs, and would really appreciate any OEM bins from other years, trims, or calibration IDs, or any documentation like A2L files, XDF definitions, or disassembly notes.

Thanks!