Category: Hardware

Bridging the Gap: Connecting Huawei ESM Batteries to Deye Inverters with ESP32
Scaling to Remote Sites: Solving the Local Server Problem
One common limitation with DIY energy monitoring is the assumption that the hardware and the Home Assistant (HA) server live on the same local network. But what about rental properties? To solve this, I designed the bridge to work over a Remote MQTT Architecture. By leveraging MQTT’s “Hub and Spoke” model, the bridge can be deployed anywhere with a simple Wi-Fi connection, while the management server remains at a central location.
1. Firewall-Friendly Outbound Connections
Instead of requiring complex VPNs or port forwarding at the remote site (which is often impossible on LTE/5G CGNAT gateways), the ESP32 initiates an outbound connection to a central broker. In the init_mqtt() function, we simply point the client to a cloud-hosted URL:
```
mqtt_cfg.broker.address.uri = "mqtts://central.my-domain.com:8883"; mqtt_cfg.broker.verification.crt_bundle_attach = esp_crt_bundle_attach;
```
2. Security via TLS Encryption
Sending battery data over the open internet is a security risk. To mitigate this, I utilized the ESP-IDF CRT Bundle. This allows the ESP32 to verify the server’s SSL certificate using the same root CA logic as a modern web browser, ensuring the telemetry is encrypted and the source is authenticated.
3. “Zero-Touch” Remote Maintenance (OTA)
Deploying at a remote site means you can’t just plug in a USB cable to fix a bug. I implemented a remote Over-The-Air (OTA) update trigger via MQTT. By publishing a signed firmware URL to a specific command topic, the bridge can update itself anywhere in the world:
```
if (strncmp(event->topic, "BMS/command/ota", event->topic_len) == 0) { // URL received via MQTT, trigger update task xTaskCreate(ota_task, "ota_mqtt_task", 8192, (void*)ota_url, 5, NULL); }
```
4. Global Discovery
Because Home Assistant’s MQTT Discovery is topic-based rather than IP-based, the remote bridge “appears” in the HA dashboard as soon as it connects to the central broker. This creates a seamless experience where data from multiple remote sites can be aggregated into a single, unified energy dashboard. This architecture transforms the project from a simple local converter into a professional-grade, scalable monitoring solution for distributed energy assets.
Future Work
The project is currently stable and running in a production environment. Check out the source code and documentation on my GitHub.
Keywords: ESP32, Huawei ESM48100, Deye Inverter, Solarman V5, Modbus RTU, Pylontech Emulation, Home Assistant, Energy Management.
- - Modbus Master: Polls multiple Huawei ESM packs for voltage, current, temperature, and cell-level data.
- - Protocol Emulator: Acts as a Pylontech BMS slave to the inverter, “tricking” it into seeing a compatible battery bank.
- - IoT Gateway: Monitors the inverter itself via the Solarman V5 TCP protocol and pushes data to Home Assistant.
Technical Deep Dive: Solarman V5 Protocol
One of the more interesting aspects was implementing the Solarman V5 protocol over TCP. Unlike standard Modbus TCP, Solarman wraps Modbus frames in a proprietary header (starting with 0xA5) and uses a custom checksum.
Home Assistant Integration
To make the system user-friendly, I implemented MQTT Auto-Discovery. The bridge registers itself with Home Assistant the moment it connects to the network, creating sensors for everything from “Grid Power” to “Battery Cell Temperature” without any manual YAML configuration. This allows for beautiful dashboards and automation—like notifying me if a specific battery cell shows a voltage imbalance, or automatically adjusting load based on real-time solar production retrieved directly from the inverter’s logger.
Scaling to Remote Sites: Solving the Local Server Problem
One common limitation with DIY energy monitoring is the assumption that the hardware and the Home Assistant (HA) server live on the same local network. But what about rental properties? To solve this, I designed the bridge to work over a Remote MQTT Architecture. By leveraging MQTT’s “Hub and Spoke” model, the bridge can be deployed anywhere with a simple Wi-Fi connection, while the management server remains at a central location.
1. Firewall-Friendly Outbound Connections
Instead of requiring complex VPNs or port forwarding at the remote site (which is often impossible on LTE/5G CGNAT gateways), the ESP32 initiates an outbound connection to a central broker. In the init_mqtt() function, we simply point the client to a cloud-hosted URL:
```
mqtt_cfg.broker.address.uri = "mqtts://central.my-domain.com:8883"; mqtt_cfg.broker.verification.crt_bundle_attach = esp_crt_bundle_attach;
```
2. Security via TLS Encryption
Sending battery data over the open internet is a security risk. To mitigate this, I utilized the ESP-IDF CRT Bundle. This allows the ESP32 to verify the server’s SSL certificate using the same root CA logic as a modern web browser, ensuring the telemetry is encrypted and the source is authenticated.
3. “Zero-Touch” Remote Maintenance (OTA)
Deploying at a remote site means you can’t just plug in a USB cable to fix a bug. I implemented a remote Over-The-Air (OTA) update trigger via MQTT. By publishing a signed firmware URL to a specific command topic, the bridge can update itself anywhere in the world:
```
if (strncmp(event->topic, "BMS/command/ota", event->topic_len) == 0) { // URL received via MQTT, trigger update task xTaskCreate(ota_task, "ota_mqtt_task", 8192, (void*)ota_url, 5, NULL); }
```
4. Global Discovery
Because Home Assistant’s MQTT Discovery is topic-based rather than IP-based, the remote bridge “appears” in the HA dashboard as soon as it connects to the central broker. This creates a seamless experience where data from multiple remote sites can be aggregated into a single, unified energy dashboard. This architecture transforms the project from a simple local converter into a professional-grade, scalable monitoring solution for distributed energy assets.
Future Work
The project is currently stable and running in a production environment. Check out the source code and documentation on my GitHub.
Keywords: ESP32, Huawei ESM48100, Deye Inverter, Solarman V5, Modbus RTU, Pylontech Emulation, Home Assistant, Energy Management. In the world of residential solar and energy storage, mixing and matching components often leads to a common headache: communication protocol mismatch. Recently, I tackled a project to bridge the gap between high-capacity industrial Huawei ESM-48100 battery packs and a Deye Hybrid Inverter. The result is an ESP32-powered “BMS Bridge” that not only translates battery telemetry but also integrates deeply with Home Assistant via MQTT.
The bridge acts as a multi-protocol translator in real-time.

The Challenge: Industrial vs. Residential
Huawei ESM series batteries are robust, industrial-grade units, but they speak a specific flavor of Modbus RTU. On the other side, residential inverters like Deye or Sunsynk typically expect a Pylontech-compatible CAN or RS485 protocol to manage charging parameters (SOC, Voltage limits, etc.). Without a bridge, the inverter is “blind” to the battery’s state, leading to inefficient charging and safety risks.
The Solution: An Intelligent Protocol Bridge
Using the ESP32 and the ESP-IDF framework, I developed a firmware that performs three simultaneous roles:
- - Modbus Master: Polls multiple Huawei ESM packs for voltage, current, temperature, and cell-level data.
- - Protocol Emulator: Acts as a Pylontech BMS slave to the inverter, “tricking” it into seeing a compatible battery bank.
- - IoT Gateway: Monitors the inverter itself via the Solarman V5 TCP protocol and pushes data to Home Assistant.
Technical Deep Dive: Solarman V5 Protocol
One of the more interesting aspects was implementing the Solarman V5 protocol over TCP. Unlike standard Modbus TCP, Solarman wraps Modbus frames in a proprietary header (starting with 0xA5) and uses a custom checksum.
Home Assistant Integration
To make the system user-friendly, I implemented MQTT Auto-Discovery. The bridge registers itself with Home Assistant the moment it connects to the network, creating sensors for everything from “Grid Power” to “Battery Cell Temperature” without any manual YAML configuration. This allows for beautiful dashboards and automation—like notifying me if a specific battery cell shows a voltage imbalance, or automatically adjusting load based on real-time solar production retrieved directly from the inverter’s logger.
Scaling to Remote Sites: Solving the Local Server Problem
One common limitation with DIY energy monitoring is the assumption that the hardware and the Home Assistant (HA) server live on the same local network. But what about rental properties? To solve this, I designed the bridge to work over a Remote MQTT Architecture. By leveraging MQTT’s “Hub and Spoke” model, the bridge can be deployed anywhere with a simple Wi-Fi connection, while the management server remains at a central location.
1. Firewall-Friendly Outbound Connections
Instead of requiring complex VPNs or port forwarding at the remote site (which is often impossible on LTE/5G CGNAT gateways), the ESP32 initiates an outbound connection to a central broker. In the init_mqtt() function, we simply point the client to a cloud-hosted URL:
```
mqtt_cfg.broker.address.uri = "mqtts://central.my-domain.com:8883"; mqtt_cfg.broker.verification.crt_bundle_attach = esp_crt_bundle_attach;
```
2. Security via TLS Encryption
Sending battery data over the open internet is a security risk. To mitigate this, I utilized the ESP-IDF CRT Bundle. This allows the ESP32 to verify the server’s SSL certificate using the same root CA logic as a modern web browser, ensuring the telemetry is encrypted and the source is authenticated.
3. “Zero-Touch” Remote Maintenance (OTA)
Deploying at a remote site means you can’t just plug in a USB cable to fix a bug. I implemented a remote Over-The-Air (OTA) update trigger via MQTT. By publishing a signed firmware URL to a specific command topic, the bridge can update itself anywhere in the world:
```
if (strncmp(event->topic, "BMS/command/ota", event->topic_len) == 0) { // URL received via MQTT, trigger update task xTaskCreate(ota_task, "ota_mqtt_task", 8192, (void*)ota_url, 5, NULL); }
```
4. Global Discovery
Because Home Assistant’s MQTT Discovery is topic-based rather than IP-based, the remote bridge “appears” in the HA dashboard as soon as it connects to the central broker. This creates a seamless experience where data from multiple remote sites can be aggregated into a single, unified energy dashboard. This architecture transforms the project from a simple local converter into a professional-grade, scalable monitoring solution for distributed energy assets.
Future Work
The project is currently stable and running in a production environment. Check out the source code and documentation on my GitHub.
Keywords: ESP32, Huawei ESM48100, Deye Inverter, Solarman V5, Modbus RTU, Pylontech Emulation, Home Assistant, Energy Management.
July 20, 2026
Building a Real-Time AI Wildlife Monitor with ESP32-CAM and TensorFlow
Developing a real-time wildlife monitoring system is a challenging yet rewarding project that combines hardware, machine learning, and web development. My latest project, WildLife Monitor, is an end-to-end solution designed to monitor safety conditions using an ESP32-CAM and a custom-trained Convolutional Neural Network (CNN).

The Vision

The goal was to create a system that doesn’t just “watch” but “understands.” Whether it’s monitoring a backyard for curious pets or ensuring an area is clear of hazards (like snakes), the WildLife Monitor provides real-time visual feedback and automated alerts based on what it sees.

The Tech Stack
- Hardware: ESP32-CAM (for low-cost, Wi-Fi-enabled video streaming).
- Backend: Flask (Python) to manage the stream, data, and dashboard.
- Computer Vision: OpenCV for frame processing and TensorFlow/Keras for the CNN model.
- Messaging: MQTT for real-time safety alerts.
- Frontend: A responsive web dashboard for monitoring and active learning.
Key Features

1. Real-Time AI Inference

The system captures an MJPEG stream from the ESP32-CAM. Each frame is preprocessed and passed through a CNN model (model_cnn.h5). The dashboard overlays real-time predictions—identifying if a subject is present and whether the situation is “Safe” or “Unsafe.”

2. Active Learning Pipeline

One of the most powerful features of this project is the Active Learning workflow. When the model encounters a frame it isn’t confident about, or when I manually flag a frame, it’s saved into a review folder.
- Manual Labeling: I built a dedicated interface to quickly categorize these “unknown” frames.
- One-Click Retraining: Once labeled, I can trigger a model retraining session directly from the dashboard. This creates a feedback loop that constantly improves the model’s accuracy.
3. Real-Time Alerting with MQTT

Safety is the priority. When the system detects an “Unsafe” condition, it immediately publishes a message to an MQTT broker. This can be used to trigger physical alarms or send phone notifications.

The Code Behind the Magic

The backend handles the stream and runs inference in real-time. Here is a look at how the frames are processed:
```
if model:
    try:
        input_data = preprocess(frame)
        preds = model(input_data, training=False).numpy()
        idx = np.argmax(preds[0])
        conf = np.max(preds[0])

        if idx < len(TRAIN_CLASSES):
            label = TRAIN_CLASSES[idx]
            color = (0, 255, 0) if "safe" in label else (0, 0, 255)
            cv2.putText(frame, f"{label} ({conf:.2f})", (10, 30), 
                        cv2.FONT_HERSHEY_SIMPLEX, 1, color, 2)
    except Exception as e:
        print(f"Inference error: {e}")
```
What’s Next?

Building this project highlighted the importance of data quality over quantity. In the future, I plan to:
- Optimize for Edge: Move some of the inference directly onto the ESP32 to reduce latency.
- Async Processing: Implement background threading for inference to maintain a high-FPS video feed.
Conclusion

WildLife Monitor is more than just a camera; it’s a smart assistant that learns from its environment. It bridges the gap between simple video surveillance and intelligent, reactive monitoring.
July 20, 2026
Building a Snake Deterrent with ESPHome
Snakes are highly sensitive to ground vibrations, interpreting them as signs of nearby predators or large animals. This natural behavior can be leveraged to create a humane deterrent system: instead of relying on chemicals or barriers alone, we can generate irregular seismic signals that encourage snakes to move away.

This project explores how to build a low‑cost, programmable vibration driver using an ESP8266 microcontroller and ESPHome firmware. By switching a 12 V hammer actuator in randomized bursts, the system produces unpredictable vibration patterns that mimic footsteps or animal movement. The result is a practical demonstration of how embedded systems, simple electronics, and open‑source firmware can be combined into a real‑world solution.

Why Random Bursts?

A steady metronome‑like vibration quickly becomes background noise. Random clusters of strikes, separated by unpredictable pauses, feel more “alive” and unsettling. This project uses ESPHome on an ESP‑01S relay board to generate those bursts automatically.

Why 12 V Matters

One important design choice was to keep the system at 12 V DC. Many garden devices unfortunately operate directly from 230 V mains, which introduces unnecessary electrical hazards in outdoor environments. By standardizing on 12 V, the system remains low‑voltage and touch‑safe, significantly reducing the risk of shock during installation, maintenance, or accidental contact.

Hardware Setup
- ESP‑01S WiFi relay board with external voltage regulator 12V -> 5V.
- 12 V Selenoid Lock, used as hammer actuator mounted to a metal stick pushed into the ground
- Shared 12 V supply: powers both the hammer and the relay board
The relay switches the hammer coil, while ESPHome firmware handles the random timing.

ESPHome Configuration

Here’s the YAML configuration that runs the random burst script at boot, with a manual switch to enable/disable it:
yaml
esphome: name: esphome-relay2 friendly_name: esphome relay2 snake hammer on_boot: priority: -10 then: - if: condition: switch.is_on: random_enabled then: - script.execute: random_burst esp8266: board: esp01_1m switch: - platform: gpio pin: GPIO0 name: "Relay2" inverted: true id: relay2 - platform: template name: "Random Burst Enabled" id: random_enabled optimistic: true restore_state: true turn_on_action: - script.execute: random_burst turn_off_action: - script.stop: random_burst script: - id: random_burst mode: restart then: - while: condition: switch.is_on: random_enabled then: - lambda: |- int burst = random(2, 5); // 2–4 strikes for (int i = 0; i < burst; i++) { id(relay2).turn_on(); delay(200); // hammer ON id(relay2).turn_off(); delay(random(300, 1000)); // random pause } - delay: !lambda "return random(5000, 15000);" // random gap before next burst
How It Works
- Burst clusters: 2–4 relay activations per cycle
- Random intra‑burst delay: 300–1000 ms between strikes
- Random inter‑burst gap: 5–15 s before the next cluster
- Control switch: Exposed in Home Assistant and the ESPHome web UI, so the system can be disabled remotely
Results

The hammer delivers irregular seismic signals through the ground near entry points. Combined with perimeter lighting and physical barriers, this creates a layered deterrent system. It’s not a silver bullet, but it reduces surprise encounters and adds peace of mind.

Final Thoughts

This vibration deterrent system is no longer just a concept on paper — it is currently undergoing real‑world testing. The ESPHome‑driven relay board and hammer actuator are deployed and running continuous randomized bursts, allowing me to observe how the design performs outside of the lab. Early results are promising, but the ongoing field trials will provide the most valuable insights: durability of the hardware, consistency of the randomization, and, most importantly, the behavioral response of snakes to irregular seismic signals.

By documenting this project as it evolves, I aim to demonstrate not only the technical implementation but also the practical effectiveness of combining embedded systems with behavioral cues in a real environment. This piece highlights the journey from idea to deployment — and the testing phase is where theory meets reality.
July 20, 2026

Reading a Huawei Battery BMS with an ESP32 and ESPHome

A deep dive into reverse-engineering RS485 Modbus communication to bring industrial battery telemetry into Home Assistant.

Background

The Huawei ESM-48100 is a 48V 100Ah LiFePO4 energy storage module originally designed for telecom sites. It’s a well-built, high-density battery — but like most industrial hardware, it was never meant to talk to a home automation system. It exposes data over a 4-wire RS485 interface using Modbus RTU, and Huawei’s official protocol documentation sits behind an enterprise support portal.

This project was about bridging that gap: taking a piece of industrial-grade battery hardware and making its internal data — state of charge, cell voltages, temperature, alarms — visible in Home Assistant through a $5 ESP32 and a $1 MAX485 transceiver.

The Hardware Stack

The physical layer is straightforward but required careful attention to the details.

Components used:

ESP32-WROOM development board
MAX485 RS485 transceiver module
RJ45 cable terminated to the ESM-48100’s COM port

The ESM-48100’s COM port is a standard RJ45 connector carrying 4-wire RS485 on pins 1, 2, 4, and 5, alongside CAN bus signals on pins 7 and 8. Only the RS485 lines were used for this project.

Wiring the MAX485 Module

The MAX485 chip has two sides — one facing the microcontroller, one facing the RS485 bus. A naming confusion that trips up many people: the module’s pins are labeled DI (Driver Input) and RO (Receiver Output), which reflect the chip’s own perspective, not the ESP32’s. DI connects to the ESP32’s TX line, and RO connects to the ESP32’s RX line.

Some MAX485 modules expose separate DE and RE pins for flow control — these need to be tied together and driven by a GPIO on the ESP32. Others tie them internally, handling flow switching automatically. Both variants work at 9600 baud with Modbus RTU, though the manual DE/RE approach is more deterministic at higher speeds.

A 120Ω termination resistor was placed across the A and B lines at the far end of the RS485 bus, as required by the Modbus standard to prevent signal reflections.

Wiring Summary

ESP32 GPIO16 (TX) → MAX485 DI
ESP32 GPIO17 (RX) ← MAX485 RO
ESP32 GPIO4       → MAX485 DE + RE (if exposed)
3.3V              → MAX485 VCC
GND               → MAX485 GND
MAX485 A+  →  ESM-48100 RJ45 Pin 1 (RS485 T+)
MAX485 B-  →  ESM-48100 RJ45 Pin 2 (RS485 T-)

The Software: ESPHome and Modbus RTU

ESPHome is a firmware framework for ESP32/ESP8266 that lets you define hardware integrations entirely in YAML. It natively supports Modbus RTU via its modbus_controller component, which handles framing, CRC, request queuing, and register parsing — so there’s no need to implement the protocol manually.

The configuration defines:

A UART component on GPIO16/GPIO17 at 9600 baud, 8N1
A Modbus component that references the UART
A Modbus Controller targeting slave address 0x01 with a 10-second poll interval
Individual sensors mapped to each holding register

Register Map

Sensor	Register	Scale
Battery Voltage	0x0000	0.01 V/bit
Battery Current	0x0001	0.01 A/bit (signed)
State of Charge	0x0002	0.1 %/bit
State of Health	0x0003	0.1 %/bit
Remaining Capacity	0x0004	0.1 Ah/bit
Max Cell Voltage	0x0005	1 mV/bit
Min Cell Voltage	0x0006	1 mV/bit
Max Cell Temp	0x0007	0.1 °C/bit
Min Cell Temp	0x0008	0.1 °C/bit
Average Cell Temp	0x0009	0.1 °C/bit
Status Flags	0x000A	bitmask
Alarm Flags	0x000B	bitmask
Cycle Count	0x000C	1 cycle/bit

ESPHome Configuration (excerpt)

uart:
  id: uart_modbus
  tx_pin: GPIO16
  rx_pin: GPIO17
  baud_rate: 9600
  stop_bits: 1
  data_bits: 8
  parity: NONE
  flow_control_pin: GPIO4

modbus:
  id: modbus_esm
  uart_id: uart_modbus
  send_wait_time: 250ms

modbus_controller:
  - id: esm_bms
    address: 0x01
    modbus_id: modbus_esm
    update_interval: 10s

sensor:
  - platform: modbus_controller
    modbus_controller_id: esm_bms
    name: "Battery SOC"
    register_type: holding
    address: 0x0002
    unit_of_measurement: "%"
    device_class: battery
    value_type: U_WORD
    filters:
      - multiply: 0.1

Derived Sensors

Beyond the raw registers, template sensors were added to derive useful secondary values:

Battery Power — calculated as voltage × current (W)
Cell Voltage Delta — max minus min cell voltage (mV), a key indicator of cell imbalance
Battery State — text sensor decoding the status bitmask into Charging / Discharging / Idle
BMS Alarm Active — binary sensor that fires whenever any alarm bit is non-zero

The Hard Part: Finding the Register Map

This was the most significant challenge of the project. Huawei’s Modbus protocol document for the ESM-48100 series is not publicly accessible without an enterprise support account. Community documentation is sparse, and what exists is scattered across energy storage forums.

The ESM-48100 is documented as complying with the YDN1363 protocol over RS485. The register layout used in this project was sourced from community reverse-engineering efforts, not from the official Huawei document — which means it carries some uncertainty. A key caveat discovered during research: some firmware revisions use a 0x1000 base offset for all registers. If sensors return zeros or errors, shifting every address up by 0x1000 is the first thing to try.

This kind of ambiguity is common when working with industrial hardware in hobby contexts. The approach taken here was to be explicit about what is verified and what is inferred, rather than presenting unverified information as confirmed fact — a discipline that matters when the output is a real electrical system.

What This Enables in Home Assistant

Once running, the ESP32 joins the home network and appears in Home Assistant as a device with 15+ entities. From there, the data feeds into:

Energy dashboards tracking charge and discharge cycles over time
Automations that respond to low SOC, high cell temperature, or active alarms
Long-term statistics on SOH degradation and cycle count growth
Notifications when the BMS alarm register goes non-zero

The cell voltage delta sensor is particularly useful — a widening gap between max and min cell voltages over time is an early indicator that cells are drifting apart, which typically precedes a significant SOH drop.

Reflections

This project sits at the intersection of embedded systems, industrial protocols, and home automation. The hardware side — RS485 wiring, termination, flow control — required understanding the physical layer of the Modbus standard. The software side required navigating ESPHome’s component model, register types, and value scaling. And the research side required distinguishing between what Huawei officially documents and what the community has inferred.

The result is a reliable, OTA-updatable, WiFi-connected BMS monitor that costs under $10 in hardware and runs indefinitely without any cloud dependency.

Built with ESPHome and Home Assistant on an ESP32 with a MAX485 RS485 transceiver.
Hardware: Huawei ESM-48100B1 LiFePO4 48V 100Ah energy storage module.

July 20, 2026

MCHP PIC p18f4431: Motor Control, 3-Ph, IGBT

Development of a 3-Phases motor speed control via PWM controlling IGBTs.

+ Technology watch and R&D.

+ Electronics Hardware (schematics, BOM, PCB layout including SMPS) .

+ Embedded software in bare metal C on Microchip PIC p18f4431.

+ 1KW 3-phases motor.

+ Current sensing.

+ H-bridge regenerative breaking.

+ Flyback DCDC power supply.

(2006 – 2008)

August 24, 2017
The Popcorn Effect on MSL 1

A little break in Firmware development to help my client, an IoT start-up, diagnosing The Popcorn Effect. Something I’ve never seen with my own eyes before. The Popcorn Effect is a direct consequence of Moisture entering the IC before the reflow process. A common problem in Electronics Manufacturing.

Production and Testing

It all started on the assembly line, the IoT product is a kind of thermometer. The production has just started and the first pieces have arrived, ready for testing. One of the test consists of heating the thermometer up to 95°C, repeated 3 Times. It all worked fine up to 40°C when suddenly the software indicated 0°C for 9 of the devices. You would think they all worked fine until they reached that temperature. Some even recovered when cooling down.

Inspection

A first visual inspection of the PCBA by microscope doesn’t show any defect, all components are populated properly.

Measuring the power supplies: it seems like it’s all fine.

The sensor

The temperature sensor is the TI TMP-100-Q1, connected to the host controller via I²C.

Next step, how does the I²C CLK and DATA look like?

They both look fine, except the data is always HIGH. So returning 0xFFFF to the app which represents -0.0625°C and then displays the nearest integer, 0°C.

A closer look

A closer look with the microscope and yes, here we go. The IC is cracked at its base. Some chips present a slight crack between 2 pins, others show a very clear crack around the corner.

The Popcorn Effect

Because moisture found it’s way into the package and expanded in the reflow process, the IC pops like a popcorn.

Manufacturers deliver the ICs in a sealed package if they are sensitive to moisture. MSL is the Moisture Sensitivity Level, provided by the manufacturer. This indicates how many hours an IC can be exposed to the ambient air before it needs to be baked to escape the trapped moisture in preparation of the reflow.

The TI TMP-100-Q1 has an MSL 1, which generally means no particular precautions need to be taken. Despite this, level 1 does specify some limits. This example proves that from the chip production to the PCB reflow in Asia, moisture can affect the production even with a MSL 1 rated chip.

Consequences

In our case, most ICs stopped working, some only at higher temperatures, some recovered when cooling down. Imagine how many hours could be spend looking for a software bug on something as sporadic as that!

Action

The PCBA manufacturer has been notified of the issue and will cook all of these ICs before reflow. This is a standard process that consists of extracting moisture / drying the ICs for many hours at moderate temperature.

April 4, 2017
Hands on TI CC2640R2F
This is my first experience with CC2640R2F and also with TI more generally so I thought I’ll write down my feelings after a week as it might be of interest to someone else.

Background

I should mention that this was my very first time developing with TI, which means most of the comments concern TI more than the CC2640R2F specifically. I have been developing with other brands like Atmel, Microchip, Motorola and Cypress so there will be some kind of comparison with them.

Goal and expectations

I’ve been given a week to evaluate the CC2640R2F and try to estimate the required time for achieving the corresponding project. The accent is put on the capacity to connect up to 4 peripherals and one client. The connection needs to automatically be established and reconnected if disconnected.

The chip

The TI CC2640R2F is an improved version of the famous TI CC2640. The main difference is that the radio stack stays in an added ROM memory. This leaves more flash space for the user application. The chip is also ready for Bluetooth 5.0 once the Stack and SDK will be released. The main difference on this is a reduced link budget for an extended range, perfect for IoT.

LAUNCHXL CC2640R2 LaunchPad demo board

I have been using the Launchpad which contains the Smart Bluetooth CC2640R2F controller, a Serial over USB chip also used for ISP and debugging, 2 leds and 2 user buttons.

Installation

Installation was long, on my computer it took a few hours for
- BLE SDK and
- code composer studio 7 (CCS 7).
I made the mistake of choosing my own install directory, this is strongly unadvertised so after some errors I reinstalled everything again. this was on my “old” laptop so it might be quicker for you.

CCS7

Code Composer Studio 7 is based on eclipse that I already know from Android Apps development. However, the default view doesn’t show all the features I am used to have but that’s just a matter of configuration.

Hello World

As a hello world project I choose the “simple central” example project because it is close to my needs. Later I found the “multi role” project that’s even closer.

Firstly impossible to compile : missing xxx files. Surely they are not in the directory, but how to get them in? I searched the forum but couldn’t find the answer so I asked for it. One user was quite quick for replying. It turns out you have to import the project API too, called “project name api”. Unfortunately CCS7 does not give you any hint why the files might be missing.

Help

I anticipated the problem that comes with every new IDE and system and ask for help. Tutor XYZ* who’s a professional that’s been working closely with and for TI briefly introduced me to the chip family and helped me to start. It is so much more convenient with someone’s help 🙂

I asked my tutor and several other people, where is the documentation for the “simple central” or “multi role” examples. Surely there is. To that I got only very generic answers, “there isn’t any”, there’s a wiki and there’s a forum just ask everything there.

The good news is that there is documentation, the bad news, it’s all over the places. So let’s list them:

– SimpleLink academy. Learn about Smart Bluetooth applied to TI’s stack.

– TI SDK user guide. I first discarded this document because I don’t understand what examples are doing in the SDK user guide. Still, this is where you will find the most complete and valuable information.

– c:/ti/sdk_xxx/ directory. Mainly a doxygen help but does also provide information.

– The forum e2e. This chip family has been around for years, so there should be a lot of common questions already answered. Unfortunately the search tool is not so good.

– GitHub. Yes, there’s quite a lot of codes and guides that can’t be found anywhere else. I avoided GitHub at first because CCS7 has a cloud based Explorer so the content should be the same. The code is probably but the doc is definitely present in GitHub and missing in CCS7. FAIL. The search results is the best because it is looking into projects from similar controllers too. This brings us to the last point.
https://github.com/ti-simplelink/ble-sdk-210-extra/tree/master/Projects/ble/multi_role

– CC2640. Of course most of the examples and documentation for the CC2640R2F is the same as for the CC2640, make sure your searches include both.

*XYZ. I prefer not to disclose the person’s name until I get approval to do so.

EDIT 21.03.2017: It seems like TI read in my mind (or got my feedback via XYZ?), they now provide a description for each example directly in CCS’s cloud! It’s however not at the root but you should find it at two parent level from it.
February 25, 2017
Cypress PRoC vs PSoC 4 BLE

As for many new starters with Cypress Semi, I didn’t really know the major differences between PRoC and PSoC 4 BLE. In fact I didn’t even realise there was a difference. Yes there is. Luckily enough it is very simple!

Cypress PRoC vs PSoC 4 BLE

Cypress’ PRoC (Programable Radio On Chip) can be seen as a subset of PSoC 4 BLE (Programable System On Chip). They have a similar core but PSoC offers a lot more analog blocks than PRoC. In fact PRoC provides only very basic analog blocks; There is no UDB, OpAmps nor Comparator. A simple comparison table can be seen on their Bluetooth Low Energy (BLE) Connectivity Solutions Overview. As an ex-Silicon Company Employee I would immediately think that the chips have actually the same DIE, but this is unlikely, because the ADCs are very different: SAR-ADC for PRoC vs Sigma Delta on PSoC 4 BLE.

Why I use PRoC?

I started a development with PSoC 4 BLE and as it turned out the IoT device doesn’t need much analog part. In this case there’s a great price benefit to move to a PRoC module. These totally certified Bluetooth 4.x modules are some of the cheapest on the market in 2016 – 2017. What I really liked is that this ARM®-based chips have been around since 2015. This means it’s up and running, no Beta testing surprises. There’s also a community that can assist should you need it! I’ll go more deeply into my thought in a later post about my choice of Cypress and if this was a good plan or not.

Thoughts for some hack

It might be nice to point out that PRoC still has an SAR-ADC and a Capacitive Delta Sigma (CDS) block. The SAR-ADC has a 1Kohm equivalent serial resitor so might not be the best out there. However, could this CDS be hacked for fast analog acquisitions? I would think so, as long as you switch off all the auto-tune mechanism. It is essentially an excellent SNR ADC. To be explored!

January 3, 2017
PCB layout with Target3001!

After validating the feasibility of my IoT idea, I wanted to start drawing the schematic. There are plenty of PCB layout CAD software. Target3001 was in the list.

Why Target3001?

I did not own a licence and prices are high, you better choose the right tool. Fortunately most of them have a free trial, perfect for evaluation before buying. This is how I ended up discarding my first choice: Element14 Circuit Studio made by Altium was a FAIL.

My second choice went to Target3001 made by IBF in Germany. I used to work a lot with this software at the start of my career. It is not really popular but it is a serious electronic schematic and layout CAD tool. I don’t recall using Kikad or any other open source version because I consider them to be too basic or not professional enough.

This was back in 2010 and Target3001 already featured the famous 3D view. I remember it to be average and buggy but wanted to see if IBF did any improvement.

How did it go?

While the design software is not so beautiful, it is mature and implements a lot of advanced functions. I did experience a few bugs but nothing to worry about.

Eventually, I ended up drawing the whole electronic schematic and started the layout. The weakest point was applying changes, pushing a track doesn’t automatically push its neighbors as it does in some other CAD tools. In fact, it doesn’t even keep the angles or anything. So if you move things around for any reason the resulting work is very heavy.

Creating a component is easy once you understand the philosophy, where the coordinates are etc. If you decide to give Target3001 a try you will need to create a component; the default library is lacking of SMT components, but there shouldn’t be any problem concerning through holes.

I was rather unhappy with the default silk screen of the provided library of SMT components, it is way too large. The solution was quite simple. I draw my own silk screen layer, smaller and thinner. I produced the red PCB with PCBGOGO and the result looked nice on the board.

My PCB designed in Target3001!

Would I recommend Target3001?

I am not sure how easy it is to learn using Target3001 from scratch because I new it already. That said, if you want a cheaper and good electronic design software to design your IoT device, I suggest giving it a try and let me know your thoughts.

January 3, 2017
PCB design with Altium Circuit Studio. FAIL.

Altium Circuit Studio sold by Element14 (Farnell) is a stripped down and cheaper version of the famous Altium Designer.

I thought I’ll give it a try as they just reduced the price to about 1000$. This makes it competitive with others in the same feature and price range.

I installed the 30 days trial and started to design the schematic of my IoT project. I have used Altium Designer and even Protel during my studies so not so difficult to remember basic usage.

I quickly noticed a lot of bugs, crashes and very bad user experience (UX). It finally went to a point that the whole software became unusable due to constant crashes.

I reported a rather long list of issues that was left without answer. Until another user raised the same major issue on the Element14’s forum: the minimal screen resolution shall be at least 1280 x 1024. Following my complain they finally got in touch but the conclusion is pretty deceiving for Digital Nomads using an ultra portable:

For any customers using lower res laptops, they get around this limitation by using sw that allows scrolling of the screen. I know it is not the answer the customer is looking for but we do appreciate the candid feedback.

Altium via Farnell, 2016-11-04

Altium also assured that the crashes are not common but they don’t have a solution. Trying Circuit Studio was a FAIL for me. I wish it would work as it looks nice and I recommend you to try it. I’ll certainly give it another try with a new computer. But for now it led me to go back towards IBF Target3001 which I used to work with when I started my career.

December 28, 2016