Ford Nugget LINBUS – part 3: Devices and Hella IBS

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

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/ 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.

The actual code is not pushed to github yet.

Ford Nugget LINBUS – part 1: A first look

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:

Frame identity

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

start time
/ ms
0 (=360)C101
500C06no response
609717no response
70D818no response
809919no response
1305B1Bisolated spike, no response
180C101called a second time
1904202called a second time
210E222Hella IBS
2202525Hella IBS
230A626Hella IBS
2407838no response
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.

Receive Buienradar BR-1800 weather station on RFM69 and Lora modules

My local sailing club has a Buienradar BR-1800 weather station with its indoor unit in the start/finish venue. There it is inaccessible to the sailors. I have some past experience in weather stations. I was the first to receive FSK signals from a WH1080 weather station. Before that time OOK was the modulation of choice. As sailor I actually want to be able to read the local wind and direction, preferable also from home. So I set out to make this weather station internet connected.

I started googling on to my surprise I found only questions of people who wanted to connect this to for example Domoticz but no easy solutions that I could reuse. Later I learned that there is an implementation which is copied by one or two others. That was after the fact!. Googling on reverse engineering or rf protocol for the BR-1800 I found two useful pieces of information. The first indicated that the BR-1800 is a Fine Offset WH-2300 and it had two spreadsheets with the RF protocol (RF properties and packet format). Searching of WH-2300 did not result in more knowledge. The second interesting information was a picture of the internal PCB that showed a footprint of the radio module used. I quickly recognized that as a HopeRF RFM22.  


The FSK signals are compatible across a range of HopeRF radio’s. Together with the protocol spreadsheet there was enough information to get me started. I pulled a STM32-based Jeenode Zero with RFM69 radio form the box and set up a PlatformIO environment using the jeelabs/Jeeh library as a lib_deps. With reusing some code and register settings form my earlier WH1080 work I was able to quickly make a receiver implementation.

So I went to the sailing club (sailed a bit first), opened my laptop and after a few minutes I had received the raw data of several packets. Back home! After studying a bit and comparing to the expected protocol I noticed that the payload was too short and I actually recognized it. I hooked up the WH1080 packet decoder and indeed, WH1080 / WS400 signals. There is another station at the club, maybe on a boat. But I should have received Buienradar BR-1800 signals as well. Same frequency and bitrate.

The next day I went back to the club and decided to inspect the indoor unit. It had no reception of the outdoor unit. So I took a long ladder and removed the outdoor unit and brought it home. checking the batteries learned that the rechargeable NiM-hydrides were completely flat. So much for a solar recharging system. After fixing this and hooking up the Jeenode Zero again I started receiving the signals. After tweaking a bit with preamble and syncword detection settings I was receiving over 80% of the transmitted packages. Next step: Decoding.

As the format is clearly related to the WH-1080 and using the rf protocol spreadsheet it was not too difficult to write the decoding algorithm. The CRC turned out to be the same as for the WH-1080. By now I had realized that this outdoor unit “architecture” is actually better known as WH24. There are some FCC records for clearance in the USA. Searching on WH24 I finally found  source code in Benjamin Larsson repository. In this file details of the protocol and decoding can be found. I used this to “compare notes” and copied code to derive the UV-index. In the end it turns out that the BR-1800 uses a different UV-index scale. 

After hooking up the Jeenode Zero with RFM69 I started to receive some packets. With some tuning of preamble and syncword detection I receive over 80% of the transmissions. At this point in time I have a working implementation. 

RF69 #17: 24 3c ce 62 19 63 0f 03 00 02 00 00 00 00 00 a9 c9
r 116 l 2 a-1525

checksum  ok crc  ok
ID: 3C, T=13.7°C, relH=99%, Wvel=2.1m/s, Wmax=3.4m/s, Wdir=206°, Rain=0.6mm, UV=0, UVindex=0, Light=0.0, battery ok

The final goal is to connect the Buienradar BR-1800 with wifi to the internet. ESP32 is a very useful solutions. They are available with HopeRF (RFM95/RFM96) and SemTech (SX1276/SX1278) Lora modules. So would a Lora module be able to receive the FSK modulated signals. The answer is yes which I will explain in a next post.

Source code will become available on github/sevenw after finishing the project and some cleanup.


Innr SmartPlug for Philips Hue – part 2


Do not work on the SmartPlug while powered with 230V. The author accepts no responsibility or liability for any adverse effects. This includes but is not limited to potential damage of the device itself, other equipment or personal harm, injury or dead. Working on electrical mains appliances can be dangerous. 230V is dangerous. If you decide to open such a device and work on it, never plug it into mains, until the device is closed again. If you do not feel comfortable with this, or want to experiment while powered with 230V: Do not proceed!


To program the smartplug, a few wires have to be connected. Only three wires need to be soldered to the JN5168 module. GND and +5V can be taken from the main PCB. Remember the disclaimer. Never work on the smartplug when it is connected to a 230V socket! The following diagrams show how to connect a USB-serial dongle to the smartplug.

Read More

Innr SmartPlug for Philips Hue – part 1

Philips Hue – Great, only E27 ad GU10 lights?

Great system, but what about the E14 lights that I have around the house, and some others where the bulbs can’t be replaced with one of the Hue lights? It seems that the Osram Lightify Plug can be connected. A solution without soldering and flashing firmware would take the fun out of it. The new brand Innr offers a SmartPlug, that uses the Zigbee HA protocol. Could it also be used with the Zigbee ZLL protocol used by Hue? The answer is yes. It only requires flashing a custom firmware. Read More

RFM69 OOK – DAGC, Sensitivity Boost and Modulation index

As a final step in exploring the optimal settings for receiving “foreign” OOK signals with the RFM69, the settings for DAGC, Sensitivity Boost and the effect of the Modulation index are explored. The modulation index is actually a FSK aspect, and no effect should be expected for OOK. However, as it can be programmed to High or Low, it is included in the exploration.

Foreign OOK refers to signals that are not natively produced by an RFM69, but are originating form various sensors or remote controls.

From the first results, it can be concluded that Sensitivity Boost has a clear advantage, and also DAGC enabled helps in icreasing sesnitivity:
Read More

RFM69 – Energy Count 3000 / ELV Cost Control

Conrad Energy Count 3000 and ELV Cost Control are wireles 230V electricity consumption measuring plugs Thomas Schulz has cracked the RF protocol of these device back in 2011 on the JeeLabs forum. The signals are FSK encoded and use the 868Mhz band. Thomas was able to receive them with a RFM12B module. Together with a JeeLink V3, it has found popular use with the German home automation software FEHM.

In this post I describe how the RFM69 can take over a task that earlier had to be performed in software.

One of the complications of the protocol is that the preamble of a series of 0x55 is scramble (whitened), and therefore more difficult to recognize. However, after scrambling it is still identical for all packets.

raw data 25 8A F9 59 DA 02 7E 15 ED 67 13 F1 85 D3 AC D2   [payload]   13 E6 84 A8 3B 
descramb 48 BB 55 55 55 55 55 55 55 55 55 55 55 55 55 7E   [payload]   7E 55 55 55 55 
               -------------------------------------- --   ---------   -- -----------
                             preamble                 HDLC  payload  HDLC  postamble

The original Jeelib-based RFM12B programs detection of valid packets was clumsy. Read More

RFM69 OOK compare antenna’s

The antenna design of a module like the RFM69 is important for the sensitivity to sognal and noise. Also antenna positioning is important. Putting an Nucleo STM32 with RFM69CW very close to a PC will result in a increase of several dBm’s in noise floor.

Gain 7 dB sensitivity with JeeNodes

The basic antenna design commonly used is a quarter wavelength wire antenna with ground plane.
From this informative paper from HopeRF, the manufacturer of the RFM69. Such an antenna has a 1/4 wavelength monopole, and a ground plane that serves to reflect (mirror) the wire so that one gets a half-wavelength dipole effect.

The 86mm wire (at 868MHz) connected to small JeeNode like devices is actually not having much of a ground plane. So this can probably be improved. There are very nice commercial designs for this at 868MHz and 433MHz. A.o from Conrad. So lets putthree 1/4 wavelength antenna’s to the test. The wire is compared to a home build and a commercial 1/4-wavelength with groundplane antenna. (See picture above this article, the blue wire crossing the Nucleo is the wire-antenna). Read More