Tag: ESP32

Ford Nugget LINBUS – part 3: Devices and Hella IBS

Frank 1 Comment

The following list contain all observed device ID’s that are addressed on the bus. Several of the device IDs can be attributed to particular equipment or sensors.

ID      Device
0x01    Central Electronics or LCD Display
0x02    Central Electronics or LCD Display
0x04    Unknown
0x05    Unknown
0x06    no response
0x0C    no response
0x17    no response
0x18    Dometic PerfectCharge SMP439A
0x19    Dometic PerfectCharge SMP439A
0x1B    Unknown
0x20    Votronic MPP440CI solar regulator
0x22    Hella IBS
0x25    Hella IBS
0x26    Hella IBS
0x38    no response
0x39    Eberspacher diesel heater
0x3A    Eberspacher diesel heater
0x3B    Unknown

Some of them do never respond. Those are probably provisions that this Ford nugget is not equipped with, such as an electric sliding door step or an airco. Others have never changed a value in the data of the frame.

The Hella Intelligent Battery Sensor LINBUS protocol has been decoded before as mentioned in part 1 of this series.

--------------------------------------------------------------------------------
Hella IBS Current Volt Temperature
ID  : 0x22 
data: AB 84 1E F4 2E 84 7A
       |  |  |  |  |  |  |
      IL IM IH  |  |  |  |     = Ibat (x-2000000)/1000 Ampere, Ibat>0: charge 
               VL VH  |  |     = Vbat x/1000 Volt
                     TT  |     = Tbat x/2-40 °C
                        ??     = 0x7A and 0x7C observed, correlates to unknown6?
                                 0x7C associated to voltage drop to certain point

--------------------------------------------------------------------------------
Hella IBS State of charge, state of health
ID  : 0x25
data: 81 80 E9 B8 BB 00
       |  |  |  |  |  |  
      CC  |  |  |  |  |        = State Of Charge x/2 in Procent
         HH  |  |  |  |        = State Of Health x/2 in Procent
            ??  |  |  |        = unknown4 / correlation to Cap_Available or SOC?
               ??  |  |        = unknown5 / no direkt link to unkown 4?
                  ?L ?L        = unknown6 / corelation to Cap_Available or SOC?

--------------------------------------------------------------------------------
Hella IBS Capacity
ID  : 0x26 
data: C5 04 CD 04 5F FF
       |  |  |  |  |  |  
      ML MH  |  |  |  |        = Max seen Capacity x/10 Ah (=SOH ?)
            AL AH  |  |        = Available Capacity x/10 Ah (=SOC)
                  CC  |        = Configured Capacity
                     ??        = CalibByte, maybe filled with stuffing bits?
                      |        = b0: CalibrationDone flag, 1=ok, 0=uncalibrated

--------------------------------------------------------------------------------

The Hella IBS can respond to requests on several other IDs, such as 0x21, 0x23 and 0x24. The central electronic module of the Nugget however only requests for the above described three frame types.

Ford Nugget LINBUS – part 2: Hardware and IDE

Frank Leave a comment

An Heltec ESP32 module with OLED screen was chosen for the ease of having a (tiny) OLED screen besides the standard capabilities of Wifi and Bluetooth connection and a USB interface for easy programming. An Heltec 32 Wifi Lora V3 was used. In this project I don’t expect to use the Lora radio. 

To interface the 3.3V based microcontroller to the harsh +11V to +16V car environment, a dedicated LINBUS interface using the TJA1021 chip was selected. This takes care of all the level shifting between the voltages and splits the one-wire LIN bus into a two-wire standard serial interface TX/RX. The LIN-BUS<->UART board can be found on amazon or from Chinese webshops.

 

Currently a standard DC jack 5.5/21.mm is connected to the the LIN-interface voor the power supply and the blue LIN bus wire connects to an available LIN bus spade connector behind the campervan-side batteries of the Nugget. The ESP32 is powered through a USB cable. Eventually when making a more permanent design it can powered form the car battery side with an additional DC/DC convertor.

 

As Software Development Environment I use Visual Studio Code and the PlatformIO plugins. Within PlatformIO I make use of the Arduino framework for ESP32 and installed the ESP32 and Heltec libraries. The latter for OLED support. The code will eventually end up at github. 

An introduction to coding and programming the ESP32 is beyond the scope of this post. Many good tutorials can be found, for example those:

PlatformIO tutorials or Random Nerds Tutorials

To interface with the LIN bus I forked two repositories of Mestrode. The first is a library to drive the dedicated functions of the TJA1021, and the second is the generic implementation of the LIN bus protocol using a serial interface of the ESP32. Both I had to fork as I needed to extend them. The transceiver library was using hard-coded TX/RX pins and for the Heltec board those pins were occupied by other functions. And for the interface library there was no spy-mode reading function implemented. I need to listen-only to the bus, while it is not in sleep mode. A new frame can come at any moment.

https://github.com/SevenW/Lin-Transceiver-Library

https://github.com/SevenW/Lin-Interface-Library

The actual code is not pushed to github yet.

Ford Nugget LINBUS – part 1: A first look

Frank Leave a comment

connecting the oscilloscope

After installing solar panels on the roof of the campervan I wanted to see whether the solar voltage regulator was providing electrical potential and current data at the solar panel and battery side. The Votronic MMP solar regulator is connected to the LIN bus of the campervan. So I build a “sniffer” for the LIN bus and did some programming on an ESP32 board. To get it all working the oscilloscope came in handy. For example to figure out the baud rate of the LIN-bus.

LinBus trace of 1000ms showing a repeating pattern of approximately 360ms

The baud rate appears to be 19200 and it appears to be a repeating pattern every 360ms. Zooming in on the data reveals that

  • There is a single “spike” of about 3ms
  • After 47ms it is followed by a train of 10 frames
  • After 82ms it is followed by a second train of  frames
  • Finally after 47ms the single spike is detected again.

Individual frames

The short frames (called spikes before) are requests from the master on the LIN bus that remain unanswered, because the device is offline or just not build into the campervan. They contain typically the byte sequence 00 55 xx where xx = the Protected ID:

Master request that remains unanswered to Protected ID = 0x5B

The frame always start at nice 10ms time slots,. An example of a regular frame comes form the campervan living part batteries intelligent battery sensor:

Hella IBS frame PID = 0x25 (State of Charge SoC)

The Hella IBS sensor LIN bus protocol is well documented in those github repositories:

https://github.com/frankschoeniger/LIN_Interface

https://github.com/mestrode/IBS-Sensor-Library

Frame identity

Finally, the complete overview of the frames with Protected and normal ID’s:

start time
/ ms		PID
(hex)		ID
(hex)		comment
0 (=360)C101
104202
20C404
308505
40FB3B
500C06no response
609717no response
70D818no response
809919no response
1305B1Bisolated spike, no response
180C101called a second time
1904202called a second time
2002020
210E222Hella IBS
2202525Hella IBS
230A626Hella IBS
2407838no response
2503939
260BA3A
2704C0Cno response

Several Frame IDs do not have a response. Device ID 01 and 02 are called twice in a cycle and three of the ID’s are known to be from the Hella IBS and for the better part the data is decoded. More posts will appear among others on the LINBUS listener based on an ESP32 and decoding of the frames of some of the connected devices.