Khaled H.

Senior embedded firmware engineer. 10+ years, 100% Job Success across 27 contracts, specializing in BLE, motor control, and industrial firmware on STM32, Nordic nRF52, ESP32, PIC, and TI MSP430. Clients hire me when the firmware decisions matter — when a wrong choice on BLE connection parameters costs weeks of battery life, when a motor control loop needs to be stable across temperature, or when an OTA update has to work on every device already in the field. Shipped products my firmware runs in: — Range React VRT — commercial shooting-sports trainer on ESP32 (see portfolio): shot detection, servo-positioned laser, BLE streaming to iOS/Android — Production BLE tire-pressure monitor on nRF52832 (nRF5 SDK/SoftDevice) — pressure + IMU over I²C, low-power BLE streaming — Commercial smart lock rebuilt from TI CC2640 onto nRF52 — BLE + NFC, plus a custom OTA/DFU host: when Nordic's DFU controller docs fell short, I reverse-engineered the protocol from live BLE logs and reimplemented it on ESP32 — STM32WB55 dual-BLDC controller — closed-loop PID with encoder feedback, live tuning over Web Bluetooth — 10-zone fire alarm panel on PIC18F/XC8 — the client still returns with new requirements every time he lands a customer — USB HID input device on PIC16F1455 — 3-switch keyboard HID (F13–F15) + rotary encoder volume/mute control for Windows (see portfolio) — Register-level i.MX RT1062 (Teensy): 8 phase-synchronized FlexPWM outputs via XBAR, no vendor SDK Beyond the above: Wi-Fi, RFID/NFC, custom GATT profiles, multi-peripheral BLE architectures, ADC tuning and sensor bring-up, interrupt-driven design, and clean firmware porting between MCU families. Currently also working in nRF Connect SDK / Zephyr. Hardware-level debugging with oscilloscope and logic analyzer — when the datasheet and reality disagree, I find out which one is lying. On one contract, the transmitter didn't actually follow its own protocol spec — the scope proved it, and I adapted the receiver to the real signal instead of the document. I also review schematics and board files from the firmware side: MCU pin assignments, boot and strapping pins, reset behavior, input protection, and JLCPCB BOM/placement files. I work in KiCad. On one client sensor board I caught a floating chip-select line on the accelerometer in the schematic. Most of my contracts start small and grow — my work history shows client relationships lasting 3–5 years and 200+ hours. I also work daily as an ATC automation engineer under ICAO standards — including network protocol analysis with Wireshark on live operational systems. That background shapes how I write firmware: defensive coding, fault tolerance, watchdog discipline, and the assumption that field conditions will eventually find every weakness in the design. For safety-adjacent, industrial, or always-on products, it matters. Toolchains: Keil uVision5, SEGGER Embedded Studio, STM32CubeIDE, MPLAB X, Code Composer Studio, Arduino IDE, XC8, Proteus,KiCad. If you have hardware in hand and need firmware that ships correctly the first time, send me the details — happy to discuss scope before you commit. Keywords: nRF52832, nRF52840, SoftDevice, BLE GATT, Secure DFU, OTA firmware update, BLDC, PID, Teensy, i.MX RT1062, FlexPWM, PIC18F, PIC16F1455, USB HID, XC8, STM32WB55, Web Bluetooth, sensor integration, IMU, I2C, low power, logic analyzer, oscilloscope debugging, protocol analysis, Wireshark, wearable firmware, IoT firmware, KiCad