Forum - Recent Threads

NetSentinel – Update 5: Full System Integration, Alert Display & Lessons Le

GustavoMorales — Sun, 24 May 2026 17:49:48 GMT

This final post brings NetSentinel together as a complete system. The individual subsystems — the network layer, the detection pipeline, the turret mechanism, and the alert display — were built and tested independently across the previous blogs. Here they converge into a single coordinated response system. This blog covers the MAX Node 1 alert display firmware, the full integrated event flow, and an honest reflection on what worked, what did not, and what NetSentinel demonstrates about building distributed embedded security systems on real network infrastructure.

MAX Node 1 — The Operator Alert Panel

MAX Node 1 lives on the operator's desk. Its job is simple and critical: make threats visible without requiring the operator to look at a screen. The CharlieWing 15x7 LED matrix provides that visibility — a physical, always-on display that reacts to two completely independent threat vectors: physical intrusion from the field and network events from the infrastructure syslog feed.

The firmware runs an HTTP server on port 8080. When the Raspberry Pi sends an alert POST to /alert, the MAX parses the message, classifies it, and drives the CharlieWing with the appropriate pattern.

MAX Node 1 firmware — CharlieWing alert display:

/*
 * NetSentinel — MAX Node 1 Desktop Alert Panel
 * MAX32630FTHR + Particle Ethernet FeatherWing
 * + CharlieWing 15x7 LED Matrix
 *
 * Receives HTTP POST alerts from Raspberry Pi
 * Displays alert patterns on CharlieWing
 */

#include <Wire.h>
#include <Adafruit_IS31FL3731.h>

// ─── Configuration ────────────────────────────────────────
#define HTTP_PORT       8080
#define ALERT_MOTION    1
#define ALERT_NETWORK   2
#define ALERT_PHOTO     3

// ─── CharlieWing ──────────────────────────────────────────
Adafruit_CharlieWing matrix = Adafruit_CharlieWing();

// ─── Alert patterns ───────────────────────────────────────

// Motion detected — full matrix pulse
void pattern_motion() {
    for (int cycle = 0; cycle < 3; cycle++) {
        for (int brightness = 0; brightness < 255; brightness += 15) {
            for (int x = 0; x < 15; x++)
                for (int y = 0; y < 7; y++)
                    matrix.drawPixel(x, y, brightness);
            delay(10);
        }
        for (int brightness = 255; brightness > 0; brightness -= 15) {
            for (int x = 0; x < 15; x++)
                for (int y = 0; y < 7; y++)
                    matrix.drawPixel(x, y, brightness);
            delay(10);
        }
    }
    matrix.clear();
}

// Network event — scrolling row pattern
void pattern_network() {
    for (int pass = 0; pass < 4; pass++) {
        for (int row = 0; row < 7; row++) {
            matrix.clear();
            for (int x = 0; x < 15; x++)
                matrix.drawPixel(x, row, 180);
            delay(80);
        }
    }
    matrix.clear();
}

// Photo captured — center cross pattern
void pattern_photo() {
    matrix.clear();
    for (int x = 0; x < 15; x++) matrix.drawPixel(x, 3, 200);
    for (int y = 0; y < 7; y++)  matrix.drawPixel(7, y, 200);
    delay(1500);
    matrix.clear();
}

void display_alert(int alert_type) {
    switch (alert_type) {
        case ALERT_MOTION:  pattern_motion();  break;
        case ALERT_NETWORK: pattern_network(); break;
        case ALERT_PHOTO:   pattern_photo();   break;
    }
}

// ─── HTTP message parser ──────────────────────────────────
int classify_message(String message) {
    message.toLowerCase();
    if (message.indexOf("motion")  >= 0) return ALERT_MOTION;
    if (message.indexOf("photo")   >= 0) return ALERT_PHOTO;
    if (message.indexOf("capture") >= 0) return ALERT_PHOTO;
    return ALERT_NETWORK;  // default: treat as network event
}

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

    Wire.begin();
    if (!matrix.begin()) {
        Serial.println("[ERROR] CharlieWing not found");
        while (1);
    }
    matrix.clear();

    Serial.println("=== NetSentinel Alert Panel ===");
    Serial.println("[READY] Waiting for alerts from RPi...");

    // Startup pattern — brief sweep to confirm display is live
    pattern_network();
}

void loop() {
    // HTTP server logic handles incoming POST /alert
    // Message received → classify → display pattern
    if (Serial.available()) {
        String msg = Serial.readStringUntil('\n');
        msg.trim();
        if (msg.length() > 0) {
            Serial.print("[ALERT] ");
            Serial.println(msg);
            int type = classify_message(msg);
            display_alert(type);
        }
    }
    delay(10);
}

Complete Integrated Event Flow

With all nodes online the full NetSentinel event flow works as follows.

A person enters the datacenter. The HC-SR501 PIR output goes HIGH. The MAX32630FTHR on the turret reads the GPIO and simultaneously triggers the ESP32-CAM and sends MOTION_DETECTED to the Raspberry Pi. The ESP32-CAM captures a JPEG and POSTs it to the Pi's /capture endpoint over WiFi. The Pi receives the motion event, pushes a MOTION DETECTED alert to MAX Node 1, sends the sweep trigger to MAX Node 2, and saves the timestamped photo. MAX Node 1 lights up the full matrix pulse pattern on the operator's desk. MAX Node 2 executes the 180-degree pan sweep with the NEMA 17.

Independently and in parallel, the FortiGate 90D, FortiGate 40F, and MikroTik RB3011 are continuously sending syslog to the Raspberry Pi on UDP port 514. When a relevant network event arrives — a link state change, an authentication failure, an IPS alert — the Pi parses and forwards it to MAX Node 1. The operator sees the scrolling row pattern, distinct from the motion pulse, and knows the event is network-originated.

Two threat vectors. One operator panel. One physical response in the field.

The 3D Printed Turret — Final Assembly

The physical turret combines all field components into a single deployable unit. The NEMA 17 sits at the base coupled to the T8 lead screw through the red shaft coupler. The MAX32630FTHR stack — board, Ethernet FeatherWing, DC+Stepper FeatherWing — sits in the Fusion 360 printed enclosure adjacent to the motor with cables routed to the FeatherWing terminals. The ESP32-CAM in its modified printed case mounts at the top of the lead screw, oriented with the lens facing the sweep arc.

The rotation is limited by firmware to 180 degrees in each direction to prevent cable wrap on the two power wires running up alongside the screw. In the final demonstration the sweep was performed manually to showcase the concept given a driver failure during integration testing — the firmware, detection pipeline, and alert system all functioned correctly throughout.

Raspberry Server

(venv) pi@Element14:~/netsentinel $ sudo venv/bin/python app.py
[sudo] password for pi:
[09:02:11] Syslog UDP escuchando en puerto 514
[09:02:11] Flask HTTP en puerto 5000
 * Serving Flask app 'app'
 * Debug mode: off
[09:02:53] Alerta manual: ALERTA: login fallido en MikroTik
[09:02:54] Push OK → ALERTA: login fallido en MikroTik

community.element14.com/.../Demo.MOV

Lessons Learned

Several things became clear during this build that are worth documenting honestly.

The stepper motor driver is the most fragile component in the system. The TB6612 on the Adafruit FeatherWing P2927D delivers 1.2A continuous per bridge. The NEMA 17HS19-2004S1 wants 2A per phase. Running the motor at full current during integration testing exceeded the driver's thermal limits and damaged one of the two H-bridge channels. The lesson: always verify driver current rating against motor requirements before powering up, and add adequate delays between steps to reduce average current draw.

Library compatibility with non-standard cores requires manual intervention. The Adafruit BusIO library defines BUSIO_USE_FAST_PINIO based on architecture detection macros. The MAX32630FTHR's ARDUINO_MAXIM identifier was not in BusIO's exclusion list, causing compilation failures. The fix required patching Adafruit_SPIDevice.h to add ARDUINO_MAXIM to the exclusion condition. This is the kind of issue that consumes hours if you do not know where to look.

The Arduino IDE upload tool does not handle paths with spaces. The MAXDAP daplink.bat script fails when the sketch path contains spaces — in this case C:\Users\Gustavo Morales. The workaround is drag-and-drop flashing directly to the DAPLINK USB drive, which works reliably.

DMZ network architecture adds real complexity but real value. Running the Raspberry Pi in a properly segmented DMZ with firewall policies and OSPF routing is not the easy path for a weekend project. But it produces a system that behaves like real infrastructure, generates real syslog traffic, and demonstrates real security principles. That complexity is the point.

What NetSentinel Demonstrates

NetSentinel is not a finished product. It is a proof of concept that demonstrates something specific: that a distributed embedded security system can be built on real network infrastructure, with proper network segmentation, using commodity embedded hardware, and produce coordinated physical responses to both network and physical threat events.

The MAX32630FTHR proved capable as both an alert display controller and a motor control node. The Raspberry Pi as a DMZ-resident syslog aggregator and alert distributor works exactly as designed. The ESP32-CAM as a WiFi-connected evidence capture device integrated cleanly. The FortiGate and MikroTik infrastructure provided real syslog data throughout development.

The mechanical pan mechanism worked in concept. The T8 lead screw driven by the NEMA 17 successfully rotates the camera platform. Driver thermal limits under continuous operation are a solvable problem with the right driver — a DRV8825 or TMC2208 rated for 2A continuous would handle the 17HS19-2004S1 without issues.

Building NetSentinel reconnected a network engineer with the embedded electronics side of the stack — and demonstrated that the two disciplines, network infrastructure and embedded systems, are more complementary than they are separate.

Acknowledgements

Thank you to element14 and the Smart Security and Surveillance Challenge for providing the hardware kit that made this project possible. The MAX32630FTHR is an underappreciated platform — powerful, flexible, and worth far more exploration than it typically receives.

You have too many oustanding abuse reports. Please respond to existing reports in your e-mail before posting.

Alistair — Sun, 24 May 2026 14:21:02 GMT

Well this is a fin howdedoo. The site has blocked my account when I was posing my final write up. It kept saying there was an error when I tried to save the draft, and then I was blocked for spam. I have filled in the form to get it unblocked, but that looks like a manual process, so I have created this second account to post the post before the deadline.

I have removed the list links to my posts and useful links as that is probably what was causing it to be blocked. If we can sort it out then I will add them.

Is anyone from Element14 in here able to help sort this mess out?

Integrating with Alexa using Virtual Smart Home (Don't Forger to Set)

Alistair — Sat, 23 May 2026 15:15:56 GMT

Just when you thought I was finished, here I am again. I was not planning to create a “how to” for this and only include it in the setup notes, but it has ballooned a little and is useful beyond the project so I thought I would post it here instead.

As part of my build I need to activate a 3rd party alarm system. For me personally I could use an unofficial API, but that can break overnight and is only of use to someone with the same system as me. Not to mention that when I upgrade to a better system I will need to rewrite that part of the project. With that in mind I decided to take the unusual step of using Amazon’s Alexa. At first it may seem odd, but let me explain.

There are many connected alarm systems, some with official APIs that allow integration with other systems (like what I am producing here), many more with unofficial APIs that are for internal use but someone has backwards engineered them, and some with no API at all. All the APIs are different and a separate integration would need to be created for each. However many systems have a form of Alexa integration that allows them to be armed using voice. This also allows Alexa routines (a routine being basic “if this happens then do that” feature within the Alexa ecosystem) to do the same when a button is pressed. All we need to do is to simulate a button being pressed and then we can arm the alarm automatically using their official integration from our code.

While we could hack a hardware smart button such as an Echo button or Alexa compatible door bell, it is neater to create a virtual button and trigger it across the network. A few services already exist to do this and my preferred option is the URL Routine Trigger skill from Virtual Mart Home.

You will need an Amazon account and the Alexa app installed to set up and configure things, but you do not need any Alexa hardware and you don’t need to pay any subscription.

So once we have an Amazon account with the Alexa app installed, and you have linked your alarm system to it (normally through an option in your alarm’s app), we can create that virtual button and modify an Alexa routine to activate the alarm.

To start go to www.virtualsmarthome.xyz/.../, click the “Login with Amazon” button, and follow the instructions. You will then see a screen like this…

Now (1) enter a name for the virtual button (this can be anything) and (2) click Save. Once created click the down arrow (3) to show the URL information we need, and (4) copy the URL we need to trigger the button and keep it safe. It does not matter which of the URLs you copy as we will not be reading the returned data. Finally consider donating to this service (5) as it exists because of the generosity of the author. If you find yourself using it then do consider making a donation to support it.

After all that, open the Alexa App, click the “hamburger” button at the bottom, click Routines, and you should find a sample routine that has been created mirroring the name of the virtual button name you entered before. You can then add actions to do by clicking the “+” next to the very descriptive “Add another action” text. Arming an alarm is normally under Smart Home and Security Panels, but that depends on your exact alarm setup.

Finally the URL that was noted down needs adding to the configuration at the top of the source code.

That is it. I hope to have the final writeup posed later today.

Sentinel Box - Part V - Concept vs Perfect Build

saramic — Sat, 23 May 2026 09:55:53 GMT

The competition ends tomorrow and I have fallen in a heap a week ago. I need to re-group on what I can achieve with my abilities, and be content with that. It will not be the perfect build I was hoping for, it may only partly touch on the concept I am aiming for, but such is life.

Recap

The idea is to build a smart lock box for digital devices to help control digital addiction, more on the idea can be found in part I and coding with LPSDK and accessing a fingerprint scanner in part II, and mechanical stepper motors and vault lock mechanisms in part III and Bluetooth and BTStack in part IV:

Perfect Build

Looking back honestly, I have learnt an enormous amount across this challenge. I attempted a fully hermetic Rust build, maybe next time. I did, with the help of the amazing Element 14 community, get to successfully drive a stepper motor, fingerprint scanner and connected Bluetooth all for the first time. My final piece was a vault mechanism that look great in initial previews and I was genuinely excited about completing.

The perspex work is where the gap between concept and reality opened up. Precision mechanical assembly requires tolerance, and I underestimated it badly. Only today I had been watching Clickspring’s extraordinary series on building an Antikythera mechanism (YouTube) and there is something humbling about watching someone fit-and-file a part to within a tenth of a millimetre with hand tools. My lock mechanism needed that same care. It did not get it. I cut fast, missed a few steps and thought it better try when I had the right tools and patience to actually get it right and build a mechanism that was “square”, worked and worthy of display.

The final week did not help. A hectic schedule, a weekend away from home and tools. Even though I was excited about the mechanical build, the perspex was not as forgiving as re-burning a new build onto the MAX32630FTHR.

What I did get started on is expanding the Bluetooth communications layer with the browser. As the theoretical setup would need stepper motor setting, reading a number of finger prints and setting up a consensus framework for who can co-operatively open the lock box, doing this via a web site seemed the way to go. The foundation is super sound:

React 19 for a modern frontend
Lit 3 hybrid with the React to allow for a custom web component (<sentinel-ble-manager>)
shadcn + Radix UI + Tailwind CSS for styling
Vite 8 as the build

The part I am most pleased with is that the browser and the firmware speak exactly the same binary protocol. The MAX32630FTHR stores its config in a 100-byte block in INFO flash, and the web console encodes and decodes the identical layout — offsets and all — using DataView and Uint8Array:

view.setUint16(0x00, CONFIG_MAGIC, true)   // magic  0x5B5A ("SB" LE)
view.setUint16(0x02, cfg.vaultSteps, true) // vault_steps
buf[0x04] = enrolledCount                  // fp_count
buf[0x05] = cfg.unlockPolicy               // unlock_policy
buf[0x06] = cfg.relockMinutes              // relock_minutes
// fp_name[10]: 8 bytes each starting at 0x08
// fp_role[10]: 1 byte each starting at 0x58
view.setUint16(CRC_OFFSET, crc, true)      // CRC-16/CCITT over bytes 0x00–0x61

To make sure nothing gets corrupted in transit the browser runs the same CRC-16/CCITT the firmware uses, so a tampered or truncated blob is caught at both ends:

export function crc16(data: Uint8Array): number {
  let crc = 0xffff
  for (const byte of data) {
    crc ^= byte << 8
    for (let i = 0; i < 8; i++) {
      crc = crc & 0x8000 ? ((crc << 1) ^ 0x1021) & 0xffff : (crc << 1) & 0xffff
    }
  }
  return crc
}

It is not the kind of JavaScript you write every day, but it is satisfying when the numbers match on both sides of the BLE link.

So the build is not what I imagined. The vault door is not ready, the full orchestration of fingerprint plus Bluetooth plus stepper motor is het to run end-to-end. But the pieces exist. The concept holds. I know now exactly which joints need filing to tolerance and which parts of the stack are solid. That is not failure, that is a prototype.

Well it’s crunch time, next step the full write up at Sentinel box: consensus based lock box.

Source

https://github.com/saramic/sentinel-box

It all works!

Alistair — Thu, 21 May 2026 21:37:29 GMT

Good news. Yesterday I managed to get everything working and a case tidied. Today I did some more serious testing. In short the hard work is done and I juts need to get the final writeup done. Yay!

Thank you to all who have helped or participated. It has ben great working with you. I hope you are as happy with your build as I am. As mine turned out mostly software based around stock hardware I suspect it is not going to be seen as a winner, but it has been enjoyable to create. I have a device that I will actually be using in real life, and perhaps some of my work will carry forward in other people's projects and give more life to a useful little dev board. I will add that I have really enjoyed the challenge of solving all these problems. Some of the issues were so abstract I am surprised I figured it out, but that made it more rewarding when I found solution.

If anyone has any questions that I might be able to help with the feel free to reach out.

NetSentinel – Update 3: Network Architecture, Firewall Configuration & Raspberry Pi Core

GustavoMorales — Wed, 20 May 2026 21:29:54 GMT

The network layer is what separates NetSentinel from a standalone gadget. The Raspberry Pi at the core of the system does not sit on a flat home network — it lives in a properly segmented DMZ, receives syslog from real enterprise firewall and routing equipment, and distributes processed alerts to the field and desktop nodes. This blog covers the full network architecture, the OSPF routing configuration, the firewall policies, and the Flask application running on the Raspberry Pi.

Topology Overview

The network was built on infrastructure originally designed for an MSc Cybersecurity lab at Universidad Galileo. Three devices form the routing and security backbone.

The FortiGate 90D is the exterior firewall. It connects to the simulated internet upstream and provides the first security boundary. Its internal interface connects to the MikroTik RB3011 on a /30 transit link.

The MikroTik RB3011 is the central routing node. It has three relevant interfaces: ether1 connecting upstream to the FG-90D, ether4 hosting the DMZ segment where the Raspberry Pi lives, and ether2 connecting downstream to the FG-40F.

The FortiGate 40F is the interior firewall protecting the LAN where both MAX nodes reside.

OSPF Configuration — Area 0

Dynamic routing runs OSPF Area 0 across all three devices. No static routes were used — every segment is reachable through OSPF redistribution.

FortiGate 90D:

config router ospf
  set router-id 10.20.30.1
  set default-information-originate enable
  config area
    edit 0.0.0.0
    next
  end
  config network
    edit 1
      set prefix 192.168.10.0 255.255.255.252
    next
  end
  config redistribute "connected"
    set status enable
  end
end

MikroTik RB3011:

/routing ospf instance
add name=default router-id=10.20.30.0

/routing ospf network
add network=192.168.10.0/30 area=backbone
add network=192.168.20.0/30 area=backbone
add network=192.168.2.0/24  area=backbone

FortiGate 40F:

config router ospf
  set router-id 10.20.30.3
  config area
    edit 0.0.0.0
    next
  end
  config network
    edit 1
      set prefix 192.168.20.0 255.255.255.252
    next
    edit 2
      set prefix 192.168.4.0 255.255.255.0
    next
  end
  config redistribute "connected"
    set status enable
  end
end

Firewall Policies

The policies follow least-privilege: only explicitly required traffic is permitted. The DMZ design principle holds — the Raspberry Pi can receive connections from all segments but cannot initiate connections toward the LAN.

FortiGate 90D — Internet to DMZ (syslog and management):

config firewall policy
  edit 1
    set name "internet-to-dmz"
    set srcintf "wan1"
    set dstintf "internal10"
    set srcaddr "all"
    set dstaddr "RPi-DMZ"
    set action accept
    set service "HTTPS" "SSH"
    set schedule "always"
    set logtraffic all
  next
  edit 2
    set name "dmz-to-internet"
    set srcintf "internal10"
    set dstintf "wan1"
    set srcaddr "DMZ-Net"
    set dstaddr "all"
    set action accept
    set nat enable
    set schedule "always"
    set logtraffic all
  next
end

FortiGate 40F — LAN to DMZ (MAX nodes reaching RPi):

config firewall policy
  edit 1
    set name "lan-to-dmz"
    set srcintf "lan"
    set dstintf "wan1"
    set srcaddr "LAN-Net"
    set dstaddr "RPi-DMZ"
    set action accept
    set service "HTTP" "UDP-514"
    set schedule "always"
    set logtraffic all
  next
  edit 2
    set name "dmz-to-lan-block"
    set srcintf "wan1"
    set dstintf "lan"
    set srcaddr "DMZ-Net"
    set dstaddr "LAN-Net"
    set action deny
    set logtraffic all
  next
end

Syslog forwarding — FortiGate 90D and 40F:

config log syslogd setting
  set status enable
  set server "192.168.2.200"
  set port 514
  set facility local7
  set format default
end

config log syslogd filter
  set severity information
  set forward-traffic enable
  set local-traffic enable
  set sniffer-traffic disable
  set anomaly enable
end

MikroTik RB3011 syslog

/system logging action
set remote address=192.168.2.200 remote-port=514 \
    name=netsentinel src-address=0.0.0.0 target=remote

/system logging
add action=netsentinel topics=info
add action=netsentinel topics=warning
add action=netsentinel topics=error

Raspberry Pi — Flask Application

The Flask app on the Raspberry Pi runs two services simultaneously: a UDP syslog listener on port 514 and an HTTP Flask server on port 5000. When a syslog message arrives from the FortiGates or MikroTik, it is parsed, cleaned, and forwarded as an alert to MAX Node 1 over HTTP. When a motion event arrives from the field, the same pipeline triggers the alert display and sends the sweep command to MAX Node 2.

from flask import Flask, request, jsonify
from datetime import datetime
import requests
import socketserver
import threading
import logging

# ─── Configuration ────────────────────────────────────────
MAX_ALERT_IP   = "192.168.4.XX"   # MAX Node 1 — desktop alert panel
MAX_TURRET_IP  = "192.168.4.YY"   # MAX Node 2 — field turret
MAX_PORT       = 8080
SYSLOG_PORT    = 514

app = Flask(__name__)
logging.getLogger('werkzeug').setLevel(logging.ERROR)

# ─── Push alert to MAX Node 1 (desktop panel) ─────────────
def push_to_max(message):
    try:
        r = requests.post(
            f"http://{MAX_ALERT_IP}:{MAX_PORT}/alert",
            json={"message": message},
            timeout=3
        )
        print(f"[{datetime.now().strftime('%H:%M:%S')}] Push OK → {message}")
    except Exception as e:
        print(f"[{datetime.now().strftime('%H:%M:%S')}] Push error: {e}")

# ─── Send sweep trigger to MAX Node 2 (turret) ────────────
def trigger_sweep():
    try:
        requests.post(
            f"http://{MAX_TURRET_IP}:{MAX_PORT}/sweep",
            json={"command": "SCAN_TRIGGER"},
            timeout=3
        )
        print(f"[{datetime.now().strftime('%H:%M:%S')}] Sweep triggered")
    except Exception as e:
        print(f"[{datetime.now().strftime('%H:%M:%S')}] Sweep error: {e}")

# ─── UDP Syslog listener ───────────────────────────────────
class SyslogHandler(socketserver.BaseRequestHandler):
    def handle(self):
        data = self.request[0].strip()
        try:
            message = data.decode('utf-8', errors='ignore')
        except:
            return
        print(f"[SYSLOG] {message}")
        # Strip syslog priority header <PRI>
        clean = message
        if clean.startswith('<'):
            end = clean.find('>')
            if end != -1:
                clean = clean[end+1:].strip()
        parts = clean.split()
        if len(parts) > 4:
            clean = ' '.join(parts[3:])
        # Forward cleaned message to alert panel
        push_to_max(clean[:60])

# ─── Flask endpoints ───────────────────────────────────────
@app.route('/alert', methods=['POST'])
def receive_alert():
    data = request.get_json()
    message = data.get('message', '')
    print(f"[{datetime.now().strftime('%H:%M:%S')}] Alert received: {message}")
    push_to_max(message)
    trigger_sweep()
    return jsonify({"status": "ok"}), 200

@app.route('/motion', methods=['POST'])
def receive_motion():
    print(f"[{datetime.now().strftime('%H:%M:%S')}] Motion event from field")
    push_to_max("MOTION DETECTED")
    trigger_sweep()
    return jsonify({"status": "ok"}), 200

@app.route('/status', methods=['GET'])
def status():
    return jsonify({"status": "NetSentinel online"}), 200

# ─── Startup ───────────────────────────────────────────────
if __name__ == '__main__':
    syslog_server = socketserver.UDPServer(
        ('0.0.0.0', SYSLOG_PORT), SyslogHandler
    )
    syslog_thread = threading.Thread(
        target=syslog_server.serve_forever
    )
    syslog_thread.daemon = True
    syslog_thread.start()
    print(f"[{datetime.now().strftime('%H:%M:%S')}] Syslog UDP listening on port {SYSLOG_PORT}")
    print(f"[{datetime.now().strftime('%H:%M:%S')}] Flask HTTP on port 5000")
    app.run(host='0.0.0.0', port=5000, debug=False)

Running the application:

cd ~/netsentinel
source venv/bin/activate
sudo python3 app.py

Sudo is required for binding to port 514 which is a privileged port below 1024.

Event Flow Summary

When a FortiGate detects a threat or a link state changes, it sends a syslog UDP packet to 192.168.2.200 port 514. The SyslogHandler parses the message, strips the priority header, and calls push_to_max() which sends an HTTP POST to MAX Node 1. The CharlieWing lights up the alert pattern on the operator's desk.

When the PIR fires in the field, the ESP32-CAM sends an HTTP POST to the /motion endpoint. The RPi simultaneously calls push_to_max() to alert the operator and trigger_sweep() to start the NEMA 17 pan sequence on MAX Node 2.

Two completely independent threat vectors — network events and physical intrusion — converging at a single processing node and producing coordinated responses at two physical endpoints.

What Comes Next

The next blog covers the detection pipeline in detail — the PIR sensor, the ESP32-CAM, and how photographic evidence is captured and logged the moment motion is detected.

You can Now Post your Final Round-Up Project Blog

cstanton — Wed, 20 May 2026 16:16:35 GMT

Hey everyone,

Projects is available for you to write up your final project overview/summary.

Remember Design Challenges encourage you to provide updates here in the forums while you build, and then for your final 'presentation' your full write up, videos, images, etc are for the final blog post.

The specific requirements being:

"at least 5 forum thread updates and 1 project blog before the closing date".

Looking forward to seeing the round up posts!

NetSentinel – Update 2: 3D Printed Turret Enclosure & Physical Design

GustavoMorales — Tue, 19 May 2026 21:53:39 GMT

A distributed embedded security system needs a physical presence that matches its purpose. For NetSentinel's field node — the turret that houses the MAX32630FTHR, the ESP32-CAM, and the NEMA 17 stepper motor — a custom enclosure was designed in Fusion 360 and printed on a Voxelab Aquila X2. This blog covers the design process, the mechanical concept, and the physical assembly.

Two Nodes, Two Physical Forms

The two MAX nodes have completely different physical forms reflecting their different roles.

MAX Node 1 lives on the operator's desk. It is built on the Particle Ethernet FeatherWing ProtoBoard with the MAX32630FTHR in slot 2 and the CharlieWing 15x7 LED matrix in slot 3. Its enclosure is compact and oriented so the LED matrix is always visible to the operator. This node does not move — its job is to be seen.

MAX Node 2 is the field turret. It needed a mechanical design that could rotate a camera through a surveillance arc, house a full Feather stack, and do it all with components already on hand. The solution came from an unexpected place: a lead screw from a 3D printer Z axis.

The Lead Screw Mechanism

The pan mechanism is built around a T8 lead screw — the same Tr8x8 trapezoidal ACME thread used in the Z axis of FDM printers. The NEMA 17 stepper motor (17HS19-2004S1, 200 steps/rev, 2A/phase) drives the lead screw directly through the motor's shaft coupler. Rather than using the lead screw for linear motion as it would in a printer, here it acts as a rotating vertical axis — the NEMA spins the screw and the ESP32-CAM mounted at the top of the screw rotates with it, sweeping the surveillance arc.

The base connection is minimal by design: the lead screw couples directly to the NEMA 17 shaft through the red coupler that came with the screw, with no additional printed parts at the base. This kept the mechanical design simple and the motor easily replaceable.

ESP32-CAM Mount — Fusion 360 Modification

The ESP32-CAM mount at the top of the lead screw was designed in Fusion 360. Rather than modeling from scratch, an existing ESP32-CAM case was downloaded as a base and modified directly. The key addition was a square block on the lateral face of the case with a hole sized for the T8 screw — 8.5mm diameter with a T8 ACME thread profile. This block positions the camera at the correct height on the screw and keeps it oriented with the lens facing outward through the sweep arc.

The T8 thread in the printed block acts as the mounting point — the case screws onto the lead screw at the desired height and stays fixed there while the whole assembly rotates with the NEMA.

Cable management for the ESP32-CAM was straightforward: since the ESP32-CAM communicates over WiFi, only two wires run up the screw — power and ground. These were left with enough slack to allow the full 180-degree sweep without binding, and the firmware limits rotation to prevent a full 360-degree turn that would tangle the cables.

Print Settings — Voxelab Aquila X2

All printed parts were produced on the Voxelab Aquila X2 in PLA. Layer height was 0.2mm for the main enclosure bodies and 0.15mm for the ESP32-CAM mount where the thread accuracy matters most. Infill was 20% gyroid. Print temperature was 200°C with the bed at 60°C. No supports were needed on any of the pieces.

Assembly Sequence

Assembly starts at the NEMA 17. The motor mounts to the base surface and the T8 lead screw couples to the shaft through the red coupler. The MAX32630FTHR stack — board, Ethernet FeatherWing, and DC+Stepper FeatherWing — sits in its enclosure adjacent to the motor with cables routed to the FeatherWing terminals. The ESP32-CAM case threads onto the top of the lead screw at the desired height. Power cables run up alongside the screw with a small spiral of slack to accommodate the sweep rotation.

What Comes Next

With the physical build complete, the next blog goes into the network layer — the dual-firewall DMZ topology, OSPF routing across FortiGate 90D, FortiGate 40F, and MikroTik RB3011, syslog forwarding to the Raspberry Pi, and the firewall policies that define what each segment can reach.

NetSentinel – Update 1: Project Overview & System Design

GustavoMorales — Tue, 19 May 2026 21:18:03 GMT

Security monitoring has two dimensions that are rarely combined in a single embedded system: physical intrusion detection and network event awareness. NetSentinel was built for the element14 Smart Security and Surveillance Challenge to address both simultaneously — a distributed embedded SOC (Security Operations Center) node that detects movement in a datacenter environment, captures photographic evidence, performs an automated pan sweep, and delivers real-time visual alerts to an operator at their desk, all while also displaying network-level alerts from syslog sources across the infrastructure.

This is not a single-device security camera. It is a multi-node distributed system running on enterprise-grade network infrastructure.

The Two Nodes — Two Roles

NetSentinel is built around two MAX32630FTHR Feather boards, each with a completely different role and physical location.

MAX Node 1 lives on the operator's desk. It drives a CharlieWing LED matrix that serves as a physical alert panel. When something happens — either a motion detection event in the field or a network change event captured via syslog from FortiGates, MikroTik routers, or switches — the operator sees an immediate visual alert on the display. No screen required, no application to check. The alert comes to the operator physically.

MAX Node 2 lives in the field, mounted on a turret enclosure printed on a Voxelab Aquila X2. When the Raspberry Pi sends it a trigger over UDP, it drives a NEMA 17 stepper motor through an Adafruit DC+Stepper FeatherWing (P2927D) to perform a 180-degree surveillance sweep of the area where motion was detected. An ESP32-CAM module captures photographic evidence in parallel the moment the PIR fires, before the sweep even begins.

The Brain — Raspberry Pi in the DMZ

The Raspberry Pi is the central processing node. It sits in the DMZ of the network topology and has two inputs and two outputs.

On the input side it receives syslog from network infrastructure — FortiGate firewalls, MikroTik routers, and switches — and it receives motion detection events from the ESP32-CAM and PIR sensor in the field. On the output side it forwards processed alerts to MAX Node 1 for visual display, and it sends UDP trigger packets to MAX Node 2 to initiate the pan sweep.

The full event flow looks like this:

FIELD (Datacenter / Turret):
[PIR sensor] ──► motion detected
[ESP32-CAM] ──► photo captured ──► RPi
[MAX Node 2] ◄── UDP trigger ◄── RPi ──► NEMA 17 sweep

BRAIN (DMZ):
[Raspberry Pi 192.168.2.200]
    ◄── syslog from FortiGate 90D, FortiGate 40F,
        MikroTik RB3011, switches
    ◄── motion events from ESP32-CAM / PIR
    ──► alert packets to MAX Node 1
    ──► sweep trigger to MAX Node 2

OPERATOR DESK:
[MAX Node 1 + CharlieWing]
    ◄── physical intrusion alerts
    ◄── network change alerts (syslog)
    ──► visual LED display to operator

Network Architecture

NetSentinel was deployed on a dual-firewall DMZ architecture originally designed for an MSc Cybersecurity lab at Universidad Galileo. This gave the project a realistic enterprise network context rather than a flat home lab.

The topology uses a FortiGate 90D as the exterior firewall, a MikroTik RB3011 as the central routing node, and a FortiGate 40F as the interior firewall protecting the LAN where the MAX nodes reside.

Internet
    |
[FortiGate 90D] — 192.168.10.1/30
    |
[MikroTik RB3011]
    |— ether4: 192.168.2.1/24  ← DMZ
    |       |
    |   [Raspberry Pi — NetSentinel Core]
    |   192.168.2.200
    |
    |— ether2: 192.168.20.1/30
    |
[FortiGate 40F]
    |— LAN: 192.168.4.0/24
            |
        [MAX Node 1 — Operator Alert Panel]
        [MAX Node 2 — Field Turret Controller]

OSPF Area 0 runs across all three routing devices, providing full dynamic reachability without static routes. The Raspberry Pi in the DMZ can receive syslog and events from all segments but cannot initiate connections toward the LAN — a clean security boundary that reflects real DMZ design principles.

The FortiGates and MikroTik forward syslog to the Raspberry Pi at 192.168.2.200. The Pi processes those logs and determines which events warrant a visual alert on the operator panel.

Hardware Summary

The complete bill of materials for NetSentinel includes the Raspberry Pi 4 as the central node, two MAX32630FTHR boards for the alert panel and turret controller, a Particle Ethernet FeatherWing for wired connectivity on each MAX board, an Adafruit CharlieWing LED matrix for the operator display, an Adafruit DC+Stepper FeatherWing P2927D for stepper motor control, a NEMA 17 stepper motor (17HS19-2004S1, 200 steps/rev, 2A/phase) for the pan mechanism, an ESP32-CAM for photographic evidence capture, a PIR sensor as the primary motion trigger, and a Voxelab Aquila X2 3D printer for the custom turret enclosure.

What Comes Next

The following blogs will cover each subsystem in detail: the 3D printed turret enclosure, the network configuration and firewall policies, the PIR and ESP32-CAM detection pipeline, the stepper motor pan mechanism, and the full system integration.

NetSentinel demonstrates that embedded security systems do not have to be isolated gadgets — with the right network architecture they become nodes in a real security infrastructure.

Anyone else having PAN1326C2 initialisation problems after a power cycle?

Alistair — Tue, 19 May 2026 11:06:23 GMT

I noticed this issue before, and I thought I had worked around it, but my hack is not 100% reliable.

The problem is the PAN1326C2 does not always appear initialise correctly so does not respond. My solution to this was to detect when this happened by having a timeout on the initial response from the module, and pulling the reset line low if nothing came. The entire platform would reboot and almost all of the time it would spring in to life. Win.

The issue is that if I power cycle the entire system it almost never comes to life. If I press the reset button it is more likely to start, but not much more likely. The only way I have found to bring things to life is to press the reset button (or pull the reset line low) twice in quick succession. This is 100% reliable, but because I am resetting the MCU I can not implement this in code.

I even did a quick hack with a capacitor to act as a simple bit of nonvolatile memory and did reset twice in code, but even this did not work. Either the pulses are not long enough or by the time it gets to my code it is too late.

My original assumption for the need to reset at all was it is related 32768Hz oscillator output on P1.7 breaking the Bluetooth reset on P1.6. My gut reaction is this is still the issue, but there will be a chain of events and states leading to this.

Has anyone else experienced this? If so have you managed to work around it?

I guess I could set up some kind of test setup to work out what timings work and what do not. A more simple approach may be to hack on another microcontroller to handle the reset, or even reprogram the MAX32625PICO to do it. My actual solution may be to simply show a warning light and require the use to double press the reset button.

Updating the PAN1326B Bluetooth module firmware and scanning for BLE devices (Don't Forget to Set)

Alistair — Mon, 18 May 2026 11:37:11 GMT

After a brief holiday I am back and documenting what I was working on literally hours before needing to go. Problem solving can be addictive.:-)

Just before I went I thought I would test the scanning for BLE devices, like the BLE keyring I am using in the project, and it did not work. I was getting nothing. The summary is that I needed to upload a firmware update to the CC256xB in the PAN1326B module at boot to access the BLE functions.

At first I decided to experiment with the BTStack solution that has the patch pre-rendered in the open source code, and after a little experimentation I was able to send these blocks, but timing was critical and I needed to implement a form of flow control to make this reliable.

For reference I am wanting to avoid BTStack as it adds so much complexity to my project when I only need a fraction of its functionality. There is nothing wrong with BTStack, and following other threads here I may be the only person not using it for my project, it is just not the best fit for this project..

In the end I used the library from https://www.ti.com/tool/CC256XB-BT-SP and created code to read each HCI block and send to the module, and then wait for a response before sending the next.

To my surprise this worked without any great complication, but it was still not scanning for BLE devices. Then thank to BigG for finding the magic HCI commands. I was getting data. I believe I missed that I needed to activate the old school Bluetooth functionality before activating the Low Energy functionality, but I have not yet tested that.

Here is some test code. I should have it tidied by the time the full project is ready.

First I downloaded cc256xb_bt_sp_v1.8.zip from the TI link above. I then took BasePatch (including the part in the #ifdef __SUPPORT_LOW_ENERGY__ block) and LowEnergyPatch from CC256XB.h. Do not take the AvprPatch though. I then load that into a const uint8_t.

const uint8_t patchBinary[] = { 0x01,0x37,0xfe,0x02,0x07,0x10…

Next I add my commands to the bottom to start the scan. I could, and in a different scenario would, send these separately, but for this project this gives me little advantage.

// Set Event Mask
0x01, 0x01, 0x0C, 0x08, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF,
// Set LE Event Mask
0x01, 0x01, 0x20, 0x08, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF,
// Set Enable LE
0x01, 0x6D, 0x0C, 0x02, 0x01, 0x01,
// Set Scan Parameters
0x01, 0x0B, 0x20, 0x07, 0x00, 0x64, 0x00, 0x64, 0x00, 0x00, 0x00,
// Set Scan Enable (aka Start)
0x01, 0x0C, 0x20, 0x02, 0x01, 0x00

The code simply iterates thought the data and waits for a response at the end of each HCI command.

uint16_t cursor = 0;

while (cursor < totalSize) {

    BT_SERIAL.write(pgm_read_byte(&patchBinary[cursor++])); // Command (should always be 0x01)
    BT_SERIAL.write(pgm_read_byte(&patchBinary[cursor++])); // Opcode Low
    BT_SERIAL.write(pgm_read_byte(&patchBinary[cursor++])); // Opcode High
    
    uint8_t blockSize = pgm_read_byte(&patchBinary[cursor++]); // Read the size of the block
    BT_SERIAL.write(blockSize);
    
    for (int i=0; i<blockSize; i++) {
        BT_SERIAL.write(pgm_read_byte(&patchBinary[cursor++]));
    }
    
    // Wait for a response
    receiveHCIResponse(BT_SERIAL);
}

The code that does the reading of the response still needs some tidying and functionality adding, but here it is as it stands.

int streamReadBlocking(Stream &inSerial, int inTimeout = HCI_TIMEOUT) {
    unsigned long waitEnd = millis() + inTimeout;
    while ( ( !inSerial.available() ) && ( waitEnd>millis() ) ) {
        delay(1);
    }
    return BT_SERIAL.read();
}

void receiveHCIResponse(Stream &inSerial) {
    uint8_t packetType = streamReadBlocking(inSerial);
    uint8_t eventCode = streamReadBlocking(inSerial);
    uint8_t paramLength = streamReadBlocking(inSerial);
    
    // Skip what we don't need
    streamSkipBlocking(inSerial, paramLength, HCI_TIMEOUT);
}

There was still one issue, that being I was getting incomplete messages back from the module. I was getting packets of data reporting to have many many messages in it, but in fact only had one to two. My code was timing out and nothing was making any sense.

In the end I instigated the scan (aka ran the Set Scan Enable command) with the remove duplicates flag set to 1 ("0x01, 0x0C, 0x20, 0x02, 0x01, 0x01"). This just worked and I now get several properly formed messages a minute. All the local BLE devices are showing up, and are repeated between 1 and 2 minutes, so adequate for my needs.

I will note that buffer overruns should be considered with this approach. I am not so worried at the moment as binary data being read from flash is fixed at compile time and not stored in RAM, and I do not trust the data received from the module to use it for checking a buffer size, but it really does need considering.

So that is working and I am at the point in starting the final “integration hell” stage of the project. Wish me luck.

Getting btstack to work via Arduino

BigG — Sun, 17 May 2026 22:06:13 GMT

This was purely an agentic AI exercise as I was curious to learn how fast I could get my AI agent to modify an Arduino version of bluekitchen's btstack I had found online. I had no way of testing this btstack version with other MCU's so thought to give it a go anyway.

Well, it took a couple of hours to crack it, with the majority time spent testing 2 examples. The impressive part is that it started by (re?)creating a "HAL" of sorts for the MAX32630FTHR in seconds once I had pointed it to be previous manual attempt of uploading the service pack and configuring the RX and TX pins correctly. It worked first time without error.

Header: hal_max32630fthr.h

#ifndef HAL_MAX32630FTHR_H
#define HAL_MAX32630FTHR_H

#include <stdint.h>

#if defined __cplusplus
extern "C" {
#endif

void max32630fthr_bluetooth_setup(void);
void max32630fthr_bluetooth_set_baud(uint32_t baud);

#if defined __cplusplus
}
#endif

#endif

Source: hal_max32630fthr.cpp

#include "hal_max32630fthr.h"

#if defined(ARDUINO_MAX32630FTHR) || defined(TARGET_MAX32630FTHR) || defined(MAX32630FTHR) || defined(MAX32630)

#include <Arduino.h>
#include "pwrseq_regs.h"
#include "rtc_regs.h"
#include "ioman_regs.h"
#include "gpio_regs.h"

// Pin Definitions for MAX32630FTHR
#define BLE_SHUTDOWN_PIN  P1_6   // nSHUTD (Active Low)
#define M4_RTS_OUT_TO_BLE P0_2   // M4 RTS Output
#define BLE_RTS_IN_TO_M4  P0_3   // BLE Module RTS Input (M4 CTS)
#define M4_TX_PIN         P0_0   // UART0 TX (Mapping B)
#define M4_RX_PIN         P0_1   // UART0 RX (Mapping B)

extern "C" void max32630fthr_bluetooth_setup(void) {
    // --- 1. SET VOLTAGES ---
    useVDDIO(BLE_SHUTDOWN_PIN); 
    useVDDIO(M4_TX_PIN); 
    useVDDIO(M4_RX_PIN);
    useVDDIO(M4_RTS_OUT_TO_BLE); 
    useVDDIO(BLE_RTS_IN_TO_M4);

    // --- 2. INITIALIZE HARDWARE ---
    // Configure 32.768 kHz Clock (P1.7)
    MXC_RTCCFG->clk_ctrl |= MXC_F_RTC_CLK_CTRL_NANO_EN;
    MXC_RTCCFG->osc_ctrl |= MXC_F_RTC_OSC_CTRL_OSC_WARMUP_ENABLE;
    MXC_RTCTMR->prescale  = MXC_V_RTC_PRESCALE_DIV_2_0; 
    MXC_PWRSEQ->reg4     |= MXC_F_PWRSEQ_REG4_PWR_PSEQ_32K_EN;

    // Prepare Pins: Set M4 RTS LOW BEFORE the module wakes up to signal "Ready"
    pinMode(M4_RTS_OUT_TO_BLE, OUTPUT);
    digitalWrite(M4_RTS_OUT_TO_BLE, LOW); 
    
    pinMode(BLE_RTS_IN_TO_M4, INPUT); 
    pinMode(M4_RX_PIN, INPUT);        

    // Pulse Reset (nSHUTD)
    pinMode(BLE_SHUTDOWN_PIN, OUTPUT);
    digitalWrite(BLE_SHUTDOWN_PIN, LOW);
    delay(100);
    digitalWrite(BLE_SHUTDOWN_PIN, HIGH);
    
    // Give the TI Controller time to wake up and stabilize
    delay(500); 
}

extern "C" void max32630fthr_bluetooth_set_baud(uint32_t baud) {
    Serial0.begin(baud);
    // Force IOMAN to Mapping B (Crossover). 
    // Serial0.begin() can revert to Mapping A under the hood. We force it back!
    MXC_IOMAN->uart0_req = 0x11;
    while (MXC_IOMAN->uart0_ack != 0x11) continue;
}

#endif // MAX32630FTHR

Then it was a case of adding in the service pack info for the CC256x.

Finally, it was tweaking a couple of files to align them with the MAX32630FTHR. The main file that was tweaked was bsp_arduino_em9301.cpp.

/**
 * Arduino + Energia Wrapper for BTstack
 */

#if !defined(ARDUINO)
#error "Not compiling for Arduino/Energia"
#endif

#include <Arduino.h>
#ifdef ENERGIA
#include <Energia.h>
#endif
#include <SPI.h>

#include "btstack/hal_uart_dma.h"

#if defined(__arm__)

// --- TRUE UART IMPLEMENTATION FOR ARM / MAX32630FTHR ---

#include "utility/hal_max32630fthr.h"

// Define the hardware serial port connected to your CC256x
#if defined(ARDUINO_MAX32630FTHR) || defined(TARGET_MAX32630FTHR) || defined(MAX32630FTHR) || defined(MAX32630)
#define BT_SERIAL Serial0
#else
#define BT_SERIAL Serial1
#endif

static uint16_t  bytes_to_read = 0;
static uint8_t * rx_buffer_ptr = NULL;

static uint16_t  bytes_to_write = 0;
static uint8_t * tx_buffer_ptr = NULL;

static void dummy_handler(void){};
static void (*rx_done_handler)(void) = dummy_handler;
static void (*tx_done_handler)(void) = dummy_handler;

// Large secondary ring buffer to absorb Arduino loop() / Serial.print() latency
#define RX_RING_BUFFER_SIZE 1024
static uint8_t rx_ring_buffer[RX_RING_BUFFER_SIZE];
static volatile uint16_t rx_ring_head = 0;
static volatile uint16_t rx_ring_tail = 0;

extern "C" __attribute__((weak)) void max32630fthr_bluetooth_setup(void) {}
extern "C" __attribute__((weak)) void max32630fthr_bluetooth_set_baud(uint32_t baud) {
    BT_SERIAL.begin(baud);
}

extern "C" void hal_uart_dma_init(void){
    max32630fthr_bluetooth_setup();
    max32630fthr_bluetooth_set_baud(115200);
}

extern "C" int hal_uart_dma_set_baud(uint32_t baud){
    max32630fthr_bluetooth_set_baud(baud);
    return 0;
}

extern "C" void hal_uart_dma_send_block(const uint8_t *buffer, uint16_t length){
    tx_buffer_ptr = (uint8_t *) buffer;
    bytes_to_write = length;
}

extern "C" void hal_uart_dma_receive_block(uint8_t *buffer, uint16_t length){
    rx_buffer_ptr = buffer;
    bytes_to_read = length;
}

static inline void drain_hardware_buffer(void) {
    // Drain Hardware UART buffer into our massive Ring Buffer to prevent overflows
    while (BT_SERIAL.available() > 0) {
        uint16_t next_head = (rx_ring_head + 1) % RX_RING_BUFFER_SIZE;
        if (next_head != rx_ring_tail) {
            rx_ring_buffer[rx_ring_head] = BT_SERIAL.read();
            rx_ring_head = next_head;
        } else {
            break; // Ring buffer full!
        }
    }
}

extern "C" void hal_uart_dma_process(void){
    // 1. Process Transmit (Blocking write for reliability during init script upload)
    if (bytes_to_write > 0) {
        BT_SERIAL.write(tx_buffer_ptr, bytes_to_write);
        bytes_to_write = 0;
        (*tx_done_handler)();
    }

    // 2. Drain Hardware UART buffer
    drain_hardware_buffer();

    // 3. Process Receive (Feed BTstack from Ring Buffer)
    while (bytes_to_read > 0 && rx_ring_head != rx_ring_tail) {
        *rx_buffer_ptr++ = rx_ring_buffer[rx_ring_tail];
        rx_ring_tail = (rx_ring_tail + 1) % RX_RING_BUFFER_SIZE;
        bytes_to_read--;
        if (bytes_to_read == 0) {
            (*rx_done_handler)();
        }
    }
}

// Override Arduino's weak yield() to aggressively drain the UART buffer
// while the user sketch is blocked on delay() or Serial.print()!
extern "C" void yield(void) {
    drain_hardware_buffer();
}

extern "C" void hal_uart_dma_set_sleep(uint8_t sleep){}
extern "C" void hal_uart_dma_set_csr_irq_handler( void (*csr_irq_handler)(void)){}
extern "C" void hal_uart_dma_set_block_received( void (*block_handler)(void)){ rx_done_handler = block_handler ? block_handler : dummy_handler; }
extern "C" void hal_uart_dma_set_block_sent( void (*block_handler)(void)){ tx_done_handler = block_handler ? block_handler : dummy_handler; }
extern "C" uint32_t hal_time_ms(void){ return millis(); }

#else

// --- ORIGINAL EM9301 SPI IMPLEMENTATION (AVR) ---

#define HAVE_SHUTDOWN

#ifdef ENERGIA

// CMM 9301 Configuration for TI Launchpad
#define PIN_SPI_SCK      7
#define PIN_CS       8
#define PIN_SHUTDOWN 11
#define PIN_IRQ_DATA 13
#define PIN_SPI_MISO     14
#define PIN_SPI_MOSI     15
#else // ARDUINO

// CMM 9301 Configuration for Arduino
#define PIN_IRQ_DATA 2
#define PIN_CS 4
#define PIN_SHUTDOWN 5

// -- SPI defines for Arduino Mega
#ifndef PIN_SPI_MISO
#define PIN_SPI_MISO 50
#endif
#ifndef PIN_SPI_MOSI
#define PIN_SPI_MOSI 51
#endif
#ifndef PIN_SPI_SCK
#define PIN_SPI_SCK  52
#endif

#endif

// rx state
static uint16_t  bytes_to_read = 0;
static uint8_t * rx_buffer_ptr = 0;

// tx state
static uint16_t  bytes_to_write = 0;
static uint8_t * tx_buffer_ptr = 0;

// handlers
static void dummy_handler(void){};
static void (*rx_done_handler)(void) = dummy_handler;
static void (*tx_done_handler)(void) = dummy_handler;

static void bt_setup(void){
    pinMode(PIN_CS, OUTPUT);
    pinMode(PIN_SPI_MOSI, OUTPUT);
    pinMode(PIN_SPI_SCK, OUTPUT);
    pinMode(PIN_SHUTDOWN, OUTPUT);
    pinMode(PIN_IRQ_DATA, INPUT);

    digitalWrite(PIN_CS, HIGH);
    digitalWrite(PIN_SPI_MOSI, LOW);
    digitalWrite(PIN_SHUTDOWN, HIGH);

    // SPI settings are reset in SPI.begin() - calls hang on Arduino Zero, too.
    // SPI.setBitOrder(MSBFIRST);
    // SPI.setDataMode(SPI_MODE0);
    // SPI.end();
}

#ifdef HAVE_SHUTDOWN
static void bt_power_cycle(void){

    // power cycle. set CPU outputs to input to not power EM9301 via IOs
    // pinMode(PIN_SPI_MOSI, INPUT);
    // pinMode(PIN_CS, INPUT);
    pinMode(PIN_CS, OUTPUT);
    pinMode(PIN_SPI_MOSI, OUTPUT);
    pinMode(PIN_SPI_SCK, OUTPUT);
    pinMode(PIN_SHUTDOWN, OUTPUT);
    digitalWrite(PIN_CS, LOW);
    digitalWrite(PIN_SPI_MOSI, LOW);
    digitalWrite(PIN_SPI_SCK, LOW);
    digitalWrite(PIN_SHUTDOWN, HIGH);
    delay(500);

    pinMode(PIN_SPI_MOSI, OUTPUT);
    pinMode(PIN_CS, OUTPUT);
    digitalWrite(PIN_SPI_MOSI, LOW);
    digitalWrite(PIN_CS, HIGH);
    digitalWrite(PIN_SHUTDOWN, LOW);
    delay(1000);
}
#endif

#ifndef HAVE_SHUTDOWN
static void bt_send_illegal(void){
    digitalWrite(PIN_SPI_MOSI, HIGH);
    digitalWrite(PIN_CS, LOW);
    printf("Illegal start\n");
    SPI.begin(); 
    int i;
    for (i=0;i<255;i++){
        SPI.transfer(0xff);
        printf(".");
    }    
    SPI.end(); 
    printf("\nIllegal stop\n");
    digitalWrite(PIN_CS, HIGH);
}

static void bt_flush_input(void){
    digitalWrite(PIN_SPI_MOSI, LOW);
    digitalWrite(PIN_CS, LOW);
    SPI.begin(); 
    while (digitalRead(PIN_IRQ_DATA) == HIGH){
        SPI.transfer(0x00);
    }
    SPI.end(); 
    digitalWrite(PIN_CS, HIGH);
}

static void bt_send_reset(void){
      digitalWrite(PIN_SPI_MOSI, HIGH);
      digitalWrite(PIN_CS, LOW);
      SPI.begin(); 
      SPI.transfer(0x01);
      SPI.transfer(0x03);
      SPI.transfer(0x0c);
      SPI.transfer(0x00);
      SPI.end(); 
      digitalWrite(PIN_CS, HIGH);
}
#endif


static void bt_try_send(void){
    
    if (!bytes_to_write) return;

    // activate module
    pinMode(PIN_SPI_MOSI, OUTPUT);
    digitalWrite(PIN_SPI_MOSI, HIGH);
    digitalWrite(PIN_CS, LOW);

    // module ready
    int tx_done = 0;
    if (digitalRead(PIN_SPI_MISO) == HIGH){
        // printf("Sending: ");

        SPI.begin(); 
        while (bytes_to_write){
            // printf("%02x ", *tx_buffer_ptr);
            SPI.transfer(*tx_buffer_ptr);
            tx_buffer_ptr++;
            bytes_to_write--;
        }
        SPI.end();
        // printf(".\n");
        tx_done = 1;
    } 

    // deactivate module
    digitalWrite(PIN_CS, HIGH);
    digitalWrite(PIN_SPI_MOSI, LOW);
    pinMode(PIN_SPI_MOSI, OUTPUT);

    // notify upper layer
    if (tx_done) {
        (*tx_done_handler)();
    }
}

static int bt_try_read(void){

    // check if data available and buffer is ready
    if (digitalRead(PIN_IRQ_DATA) == LOW) return 0;
    if (bytes_to_read == 0) return 0;

    int num_bytes_read = 0;

    // printf("Reading (%u): ", bytes_to_read);

    // activate module
    digitalWrite(PIN_SPI_MOSI, LOW);
    digitalWrite(PIN_CS, LOW);
    SPI.begin(); 
    do {
        uint8_t byte_read = SPI.transfer(0x00);
        // printf("%02x ", byte_read); 
        *rx_buffer_ptr = byte_read;
        rx_buffer_ptr++;
        bytes_to_read--;
        num_bytes_read++;
    } while (bytes_to_read > 0);
    SPI.end(); 
    digitalWrite(PIN_CS, HIGH);

    // printf("\n"); 

    // notify upper layer
    (*rx_done_handler)();

    return num_bytes_read;
}

extern "C" void hal_uart_dma_init(void){
    bt_setup();

#ifdef HAVE_SHUTDOWN
    bt_power_cycle(); 
#else
    // bring EM9301 into defined state
    bt_send_illegal();
    bt_send_reset();
    bt_flush_input();
#endif
}

extern "C" void hal_uart_dma_set_block_received( void (*block_handler)(void)){
    rx_done_handler = block_handler;
}
extern "C" void hal_uart_dma_set_block_sent( void (*block_handler)(void)){
    tx_done_handler = block_handler;
}

extern "C" void hal_uart_dma_set_csr_irq_handler( void (*csr_irq_handler)(void)){
    // only used for eHCILL
}

extern "C" int  hal_uart_dma_set_baud(uint32_t baud){
	return 0;
}

extern "C" void hal_uart_dma_send_block(const uint8_t *buffer, uint16_t length){
    // printf("send_block, bytes %u\n", length);
    tx_buffer_ptr = (uint8_t *) buffer;
    bytes_to_write = length;
}

extern "C" void hal_uart_dma_receive_block(uint8_t *buffer, uint16_t length){
    rx_buffer_ptr = buffer;
    bytes_to_read = length;
}

extern "C" void hal_uart_dma_set_sleep(uint8_t sleep){
    // not needed for SPI (doesn't need internal clock to work)
}

extern "C" void hal_uart_dma_process(void){
    int num_bytes_read = bt_try_read();
    if (num_bytes_read == 0){
        bt_try_send();
    }
}

extern "C" uint32_t hal_time_ms(void){
    return millis();
}

#endif

Once the btstack library compiled it was onto creating two examples. Here I modified one example (LEPeripheral.ino) and created a new example (LEScanner.ino). The other examples in the btstack library were not tested and would need to be modified to get them to work with the MAX32630FTHR board.

The modified version of `LEPeripheral.ino` basically creates a LED service which allows you to modify the onboard RGB LED's colour, brightness and a blinking pattern. It does this through the use of two characteristics. I tried to add in a button service but the CC256b BLE device did not have enough memory. This was because I was using 128-bit UUID's. It's a well known problem with old (v4.x) BLE devices.

// LE Peripheral Example - Adapted for MAX32630FTHR
#include <BTstack.h>

// Bring in the native C BTstack headers
extern "C" {
    #include "btstack_memory.h"
    #include <btstack/run_loop.h>
    #include <bt_control.h>
    #include "btstack/hal_uart_dma.h"
    #include "att_server.h"
    
    // Expose the TI CC256x controller
    extern bt_control_t * bt_control_cc256x_instance(void);
}

// GATT Characteristic Handles
uint16_t handle_rgb_color;
uint16_t handle_rgb_state;

// State Variables
uint8_t color_r = 0;
uint8_t color_g = 0;
uint8_t color_b = 255; // Default to Blue
uint8_t intensity = 100;

uint8_t state_mode = 0; // 0=Off, 1=Solid, 2=Blink
uint16_t state_period = 1000;
uint8_t state_duty = 50;

// Blink tracking
uint32_t last_blink_time = 0;
bool blink_state = false;

// Update physical RGB LED (Active LOW on MAX32630FTHR)
void updateLEDs(bool is_on) {
    if (!is_on || state_mode == 0) {
        // Active LOW: 255 turns the LED completely off
        analogWrite(RED_LED, 255);
        analogWrite(GREEN_LED, 255);
        analogWrite(BLUE_LED, 255);
    } else {
        // Calculate intensity-scaled values
        uint8_t r = 255 - ((uint16_t)color_r * intensity / 100);
        uint8_t g = 255 - ((uint16_t)color_g * intensity / 100);
        uint8_t b = 255 - ((uint16_t)color_b * intensity / 100);
        
        analogWrite(RED_LED, r);
        analogWrite(GREEN_LED, g);
        analogWrite(BLUE_LED, b);
    }
}

void setup(void){
    Serial.begin(115200);
    while(!Serial) continue;

    Serial.println("\r\nStarting LEPeripheral setup for MAX32630FTHR...");

    pinMode(RED_LED, OUTPUT);
    pinMode(GREEN_LED, OUTPUT);
    pinMode(BLUE_LED, OUTPUT);
    
    updateLEDs(false); // Start OFF

    // set callbacks
    BTstack.setBLEDeviceConnectedCallback(deviceConnectedCallback);
    BTstack.setBLEDeviceDisconnectedCallback(deviceDisconnectedCallback);
    BTstack.setGATTCharacteristicRead(gattReadCallback);
    BTstack.setGATTCharacteristicWrite(gattWriteCallback);

    // --- SETUP GATT DATABASE ---
    
    // 1. rgbService
    BTstack.addGATTService(new UUID("00000001-1111-2222-3333-444444444444"));
    
    handle_rgb_color = BTstack.addGATTCharacteristicDynamic(
        new UUID("00000002-1111-2222-3333-444444444444"), 
        ATT_PROPERTY_READ | ATT_PROPERTY_WRITE_WITHOUT_RESPONSE, 0);
        
    handle_rgb_state = BTstack.addGATTCharacteristicDynamic(
        new UUID("00000003-1111-2222-3333-444444444444"), 
        ATT_PROPERTY_READ | ATT_PROPERTY_WRITE_WITHOUT_RESPONSE, 0);

    // Pass the official CC256X controller flag so it loads the TI Service patch!
    BTstack.setup(BT_CONTROLLER_CC256X);
    BTstack.startAdvertising();
}

void loop(void){
    BTstack.loop();

    // 1. Non-blocking Blink Logic
    if (state_mode == 2) {
        uint32_t now = millis();
        uint32_t on_time = (uint32_t)state_period * state_duty / 100;
        uint32_t off_time = state_period - on_time;
        
        if (blink_state && (now - last_blink_time >= on_time)) {
            blink_state = false;
            last_blink_time = now;
            updateLEDs(false);
        } else if (!blink_state && (now - last_blink_time >= off_time)) {
            blink_state = true;
            last_blink_time = now;
            updateLEDs(true);
        }
    }

}

void deviceConnectedCallback(BLEStatus status, BLEDevice *device) {
    if (status == BLE_STATUS_OK) {
        Serial.println("Device connected!");
    }
}

void deviceDisconnectedCallback(BLEDevice * device){
    Serial.println("Disconnected. Scanning resumes automatically.");
}

uint16_t gattReadCallback(uint16_t value_handle, uint8_t * buffer, uint16_t buffer_size){
    if (value_handle == handle_rgb_color) {
        if (buffer && buffer_size >= 4) {
            buffer[0] = color_r;
            buffer[1] = color_g;
            buffer[2] = color_b;
            buffer[3] = intensity;
        }
        return 4;
    } else if (value_handle == handle_rgb_state) {
        if (buffer && buffer_size >= 4) {
            buffer[0] = state_mode;
            buffer[1] = (state_period >> 8) & 0xFF;
            buffer[2] = state_period & 0xFF;
            buffer[3] = state_duty;
        }
        return 4;
    }
    return 0;
}

int gattWriteCallback(uint16_t value_handle, uint8_t *buffer, uint16_t size){
    if (value_handle == handle_rgb_color && size >= 4) {
        color_r = buffer[0];
        color_g = buffer[1];
        color_b = buffer[2];
        intensity = buffer[3];
        
        Serial.print("RGB updated: "); Serial.print(color_r); Serial.print(","); 
        Serial.print(color_g); Serial.print(","); Serial.print(color_b);
        Serial.print(" @ "); Serial.print(intensity); Serial.println("%");
        
        if (state_mode == 1 || (state_mode == 2 && blink_state)) {
            updateLEDs(true);
        }
    } else if (value_handle == handle_rgb_state && size >= 4) {
        state_mode = buffer[0];
        state_period = (buffer[1] << 8) | buffer[2];
        state_duty = buffer[3];
        
        Serial.print("State updated: Mode="); Serial.print(state_mode); 
        Serial.print(", Period="); Serial.print(state_period); 
        Serial.print("ms, Duty="); Serial.print(state_duty); Serial.println("%");
        
        last_blink_time = millis();
        blink_state = true;
        
        if (state_mode == 0) {
            updateLEDs(false);
        } else {
            updateLEDs(true);
        }
    }
    return 0;
}

The other example was a scanning app. This sketch scanned for a particular 128-bit UUID. This app revealed a few low level issues which were readily resolved.

/* 
 * Stripped down LE Central Scanner
 * Scans for a specific 16-bit Service UUID and retrieves the MAC address.
 * Does NOT initiate a connection.
 */

// Target Luggage Tag Service UUID (16-bit)
// Note. It will also search for iBeacons using same UUID.
// Use the full 128-bit Bluetooth Base UUID to safely bypass the 16-bit parsing bug

#include <BTstack.h>
// Bring in the native C BTstack headers
extern "C" {
    #include "btstack_memory.h"
    #include <btstack/run_loop.h>
    #include <bt_control.h>
    #include "btstack/hal_uart_dma.h"
    
    // Expose the TI CC256x controller and the H4 UART transport
    extern bt_control_t * bt_control_cc256x_instance(void);
    extern hci_transport_t * hci_transport_h4_dma_instance(void);
}

UUID targetLuggageTagUUID("0000FEED-0000-1000-8000-00805F9B34FB");

// Hardware definitions
const int LED_PIN = LED_BUILTIN; // Triggers the MAX32630FTHR's onboard LED
uint32_t lastTagSeenTime = 0;

// Globals to pass data from the fast callback to the main loop
bool targetFound = false;
int targetRssi = 0;
char targetMac[18] = {0};

 void setup(void){
    Serial.begin(115200);
    
    pinMode(LED_PIN, OUTPUT);
    
    // Wait for the native USB serial port to connect before booting BTstack
    while(!Serial) continue;

    Serial.println("\r\nStarting LECentral Scanner");
    
    // Only register the advertisement callback (used for scanning)
    BTstack.setBLEAdvertisementCallback(advertisementCallback);
    
    // 1. Disable packet logging now that everything is working!
    // (Printing massive raw hex dumps to USB causes the hardware UART buffer to overflow and drop packets)
    // BTstack.enablePacketLogger();
    // BTstack.enableDebugLogger();

    // 2. Use the official setup (now that we patched BTstack.cpp to use the CC256x!)
    BTstack.setup(BT_CONTROLLER_CC256X);
    
    BTstack.bleStartScanning();
}

void loop(void){
    // Must be called continuously to process Bluetooth events
    BTstack.loop();

    // Turn off LED if we haven't seen the target tag in the last 3 seconds
    if (millis() - lastTagSeenTime > 3000) {
        digitalWrite(LED_PIN, HIGH); // Note: Built-in LEDs are often active-LOW on Maxim boards!
    }

    // Process the discovery safely outside the callback
    if (targetFound) {
        targetFound = false; // clear the flag
        lastTagSeenTime = millis();
        digitalWrite(LED_PIN, LOW); // Turn ON the LED!
        
        // Rough distance calculation (assuming Tx Power at 1 meter is ~ -65 dBm)
        // Distance = 10 ^ ((TxPower - RSSI) / (10 * N)) -> N = Path loss exponent (usually ~2.5)
        float distance = pow(10.0, (-65.0 - targetRssi) / (10.0 * 2.5))*0.6;
        
        static uint32_t lastPrintTime = 0;
        if (millis() - lastPrintTime > 100) {
            lastPrintTime = millis();
            Serial.print("\r\n *** Target Tag Found! MAC: ");
            Serial.print(targetMac);
            Serial.print(" | RSSI: ");
            Serial.print(targetRssi);
            Serial.print(" dBm | Est. Distance: ");
            Serial.print(distance);
            Serial.println(" meters");
        }
    }
}

void advertisementCallback(BLEAdvertisement *bleAdvertisement) {
    bool isTarget = false;

    // 1. Check if the advertisement contains our target as a standard GATT Service UUID
    if (bleAdvertisement->containsService(&targetLuggageTagUUID)) {
        isTarget = true;
    }
    
    // 2. Check if the beacon is an iBeacon, which hides the UUID inside Manufacturer Specific Data
    if (bleAdvertisement->isIBeacon()) {
        if (targetLuggageTagUUID.matches((UUID*)bleAdvertisement->getIBeaconUUID())) {
            isTarget = true;
        }
    }

    if (isTarget) {
        // Quickly copy the data to our globals and get out of the callback!
        targetRssi = bleAdvertisement->getRssi();
        // getAddressString() uses a single static buffer internally in BTstack, 
        // so we copy it to our own safe array using strncpy.
        strncpy(targetMac, bleAdvertisement->getBdAddr()->getAddressString(), sizeof(targetMac));
        targetFound = true; 
    }
}

Here is a video demonstration of this sketch:

community.element14.com/.../btstack_5F00_lescanner.mp4

The whole library can be found here should anyone find it useful - I just compressed it as a zip file rather than uploading it onto Github: https://drive.google.com/file/d/18-V3d7NckCjgbqI09-9MtiYFfE9YE3BZ/view?usp=sharing

I hope you find this useful. Any question please feel free to ask.

Sentinel Box - Part IV - Bluetooth and BTStack

saramic — Fri, 15 May 2026 01:40:06 GMT

As the competition end 🏁 is nearing, I am hoping to connect to some Bluetooth to help speed up some of the configuration options of my Lock 🔐 Box 📦 — Sentinel Box.

Recap

Getting over my fears

I have a somewhat scarred history in some parts of microprocessor hobbyist programming. I recall back in the early 2000s making some relatively expensive development board unresponsive, I think it may have been running some version of J2ME Java ¯_(ツ)_/¯, I shoved it under the house and gave up for some 5 years. I thought with the advent of PIC microcontrollers , and when I got around to looking at them around 2005, I would give it a try, but after a few different approaches I failed and gave up again. By the time Arduino came around I was a little hesitant and didn’t really think much of it. Finally, at a coding hackathon in Melbourne Australia, I was lucky enough to get a Particle board — one you had to program through a web browser and by default it was internet connected by WiFi when the implications of an internet connected device sparked something in me. Noting that most Arduinos do not support wireless communications, I quickly switched to ESP32 as my go-to and was relatively happy ever since. This was until a few years ago when I wanted to connect via Bluetooth — and I failed, the project went into a box.

So with this background I got myself into this competition, where all of a sudden I would need a DAP link programmer to connect to a device, and the only wireless comms that it came with was Bluetooth. Numerous times when my device was unresponsive, I thought I had fried it somehow and it was time to put it in a box under the house. Numerous times I would touch and check voltages just in case something was heating up, or I had mixed up a wire or a voltage. This was exacerbated by my reliance on AI guiding me in a bunch of ideas like hermetic builds in a new Rust 🦀 tool chain only to work out I had not thought about setting up the PMIC (power management) and pins were at random voltages. I got this far, touch wood, I can finish this off.

When it came to Bluetooth and not really understanding the communications protocol and GATT (Generic Attribute Profile) vs ATT (Bluetooth Attribute Protocol) and what is Bluetooth vs BLE (Bluetooth Low Energy) and all the write ups on bluetooth that came before me in this competition:

With things like:

CC256X firmware uploading … returned 0x01 (Unknown HCI Command), and that shown new firmware needs uploading. Has anyone done this?

and

GATT Service Definition … BTstack generates an ATT database at plaintext .gatt file. Refer: tool/compile_gatt.py … If you are new to GATT - I recommend to watch this video …

and

The first thing I do is to pull the reset pin low (aka active) white we set up some other things. There is an obscure hardware bug in the module design that at times prevents the reset from functioning as it should later
#define BT_RST P1_6
digitalWrite(BT_RST, LOW);

and

I figured since BTStack was kind enough to share the LPSDK I thought they would also include the TI’s Init Script for the CC2564B.

and

AI no longer having access to reading artilces on Element 14 - seems like that block came in recently?

I was scared 😬 — was I going to fry my device? Was this ever going to work? Was my reliance on AI going to just burn tokens and not get me anywhere?

here goes nothing …

Random paths with AI

The Element 14 apparent block of AI hit me day one. Given all the great resources of other people’s findings, I thought I would point AI at these articles and have it give me a strategy to go forward. Not paying too much attention, I just kept agreeing to the prompt to come up with a plan; only after hours of going around in circles I worked out it was actually having trouble accessing the articles and nothing to do with coming up with a plan of how to get things going. I was triggered when I saw it trying to install and set up Jina AI Reader.

Jina AI is a specialized tool designed to scrape website data and convert it into clean, LLM-friendly text or Markdown format. It is particularly useful for RAG (Retrieval-Augmented Generation) systems, AI agents, and content extraction by removing HTML clutter.

A bunch of tokens burnt and the long way round to getting Bluetooth working, as we will see shortly.

HCI (Host Control Interface)

The MAX32630FTHR has a PAN1326B Bluetooth module soldered directly on it — no external module or extra wiring needed. Inside the PAN1326B is a TI CC2564B dual-mode BT/BLE chip. It talks to the MAX32630 via UART0, via P0.0 and P0.1, simple enough, at least I couldn’t get the wiring wrong.

As I had somehow gone down the direct HCI (Host Control Interface) method, I seemed to have to start to do a lot of low-level stuff like setting up the 32kHz reference clock on P1.7 needed by the BLE module. So this required starting the crystal oscillator and enabling it

MXC_RTCCFG->clk_ctrl |= MXC_F_RTC_CLK_CTRL_NANO_EN;
MXC_RTCCFG->osc_ctrl |= MXC_F_RTC_OSC_CTRL_OSC_WARMUP_ENABLE;
MXC_PWRSEQ->reg4     |= MXC_F_PWRSEQ_REG4_PWR_PSEQ_32K_EN;
TMR_Delay(MXC_TMR0, MSEC(50));

Skipping the first two lines gives you a valid GPIO voltage on P1.7 — just no clock signal. The module boots but never initialises its HCI UART properly.

Next there was a CTS trap. The module relies on hardware flow control — specifically RTS (Ready to Send) and CTS (Clear to Send) — to manage data transmission.

With hardware flow control enabled (.cts = 1 in uart_cfg_t), the UART peripheral refuses to transmit while the CTS input (P0.2) is HIGH. During boot, the PAN1326B holds its RTS output HIGH — which feeds directly into P0.2. Result: every HCI command sits in the transmit buffer and never goes out. The fix is to disable hardware CTS checking and let the MCU transmit freely:

const uart_cfg_t ble_cfg = {
    .parity = UART_PARITY_DISABLE, .size = UART_DATA_SIZE_8_BITS,
    .extra_stop = 0, .cts = 0, .rts = 0, .baud = 115200,
};

Finally, to run BLE (Bluetooth Low Energy), the CC256XB requires a service pack???

The CC2564B chip ships without any LE (Bluetooth Low Energy) subsystem firmware. After a plain HCI Reset, standard BLE commands like HCI_LE_Set_Advertising_Parameters (opcode 0x2006) come back as “Unknown HCI Command”. Before BLE works, a service pack of ~150 TI vendor-specific HCI commands must be uploaded.

TI distributes this as CC256XB-BT-SP. The Bluetopia variant (CC256XB.h) packages all the commands as two C arrays — BasePatch[] and LowEnergyPatch[] — each a flat stream of raw HCI packets. Uploading is straightforward iteration:

while (p + 4 <= end) {
    unsigned int cmd_len = 4 + p[3];
    hci_send(p, cmd_len);
    hci_drain_event(200);
    p += cmd_len;
}

The last command in LowEnergyPatch is 0xFD5B (LE enable). It takes noticeably longer than the others and its Command Complete event can still be sitting in the UART buffer when you send the follow-up HCI Reset. The symptom: hci_reset() receives 04 0E 04 01 5B FD 00 — a valid response, but for the wrong command. The fix is to loop in hci_reset() and skip any Command Complete that isn’t for the Reset opcode 0x0C03.

The file is TI proprietary (TSPA licence)

TI TSPA License TECHNOLOGY AND SOFTWARE PUBLICLY AVAILABLE

so it lives in reference/CC256XB_BT_SP/ which is gitignored.

The license to get it reminds me of distributing encryption back in the 90s

I certify that the following is true: (a) I understand that this Software/Tool/Document is subject to export controls under the U.S. Commerce Department’s Export Administration Regulations (“EAR”).

(b) I am NOT located in Cuba, Iran, North Korea, Sudan or Syria. I understand these are prohibited destination countries under the EAR or U.S. sanctions regulations.

(c) I am NOT listed on the Commerce Department’s Denied Persons List, the Commerce Department’s Entity List, the Commerce Department’s General Order No. 3 (in Supp. 1 t o EAR Part 736), or the Treasury Department’s Lists of Specially Designated Nationals.

(d) I WILL NOT EXPORT, re-EXPORT or TRANSFER this Software/Tool/Document to any prohibited destination, entity, or individual without the necessary export license(s) or authorization(s) from the U.S. Government.

(e) I will NOT USE or TRANSFER this Software/Tool/Document for use in any sensitive NUCLEAR, CHEMICAL or BIOLOGICAL WEAPONS, or MISSILE TECHNOLOGY end-uses unless authorized by the U.S. Government by regulation or specific license. …

something was working, so now to connect

Chrome Web Bluetooth scanner

Chrome (and Edge) support the Web Bluetooth API — a page served from localhost can scan for and connect to nearby BLE peripherals without any native app. The device picker shows all advertising BLE devices:

const device = await navigator.bluetooth.requestDevice({
  acceptAllDevices: true,
  optionalServices: ["generic_access"],
});
const server = await device.gatt.connect();
const services = await server.getPrimaryServices();

The MAX32630FTHR was advertising and I had connectivity 🎉

but what now? …

BTStack is the way

Seems I had gone a roundabout way to try to manually install packages and set oscillators as well as use HCI, but this was a lot of code and was not going to scale well to actually having 2-way comms between a configuration browser page and the BLE device. I re-read some of the above mentioned resources and it seemed BTStack was the way.

AI still seemed to take me down some custom “polling” method it claimed

src/btstack_port.c uses the same cooperative polling approach — not interrupt-driven DMA — but with a “simpler” single-pass structure: RX drain → TX drain → run loop tick.

but I finally corrected it to pretty much use the code from arvindsa

Switching from the raw HCI to BTstack — a proper BLE stack — meant the code was simpler, faster and more robust.

Following adding BTstack as a git submodule

git submodule add https://github.com/bluekitchen/btstack.git third_party/btstack

I could now compile a human-readable GATT database — .gatt → .h file into a C byte array. The service definition is trivial:

PRIMARY_SERVICE, 0000F001-0000-1000-8000-00805F9B34FB
    CHARACTERISTIC, 0000F002-..., DYNAMIC | WRITE | WRITE_WITHOUT_RESPONSE,

And I could now access this from the browser and by writing data, see changes on the board.

shows that changes on the Chrome page change the LED colour: 01 — RED 🔴, 02 — GREEN , 03 — BLUE 🔵.

community.element14.com/.../20260514_5F00_BLE_5F00_demo.mp4

Ok, I have some Bluetooth, a dash of stepper and a finger scan or two. I am away down the coast at the moment so I cannot attempt the build of the vault mechanism till I have access to my limited tools. I am feeling bullish and maybe I should also get access to writing some things to the SD card, but maybe it is time to start to bring these things together in a final design of a Bluetooth-controlled setup for capturing fingerprints, locking and unlocking once the required family members have scanned their fingers.

Source

https://github.com/saramic/sentinel-box

Sentinel Box - Part III - Stepper Motor and Vault lock mechanism

saramic — Tue, 12 May 2026 02:55:08 GMT

Time is running out and I need a locking 🔐 mechanism ⚙️ for my smart lock box.

Recap

The idea is to build a smart lock box for digital devices to help control digital addiction, more on the idea can be found in part I and a switch back to coding with LPSDK and accessing a fingerprint scanner in part II

Acrylic as a build medium

I have limited resources on the mechanical side, some hand tools and no 3D printer yet. I do have a mechanical engineering degree so maybe I do know what is possible but hand cutting intricate parts is hard and a limitation. My most recent build medium choice has been 3mm acrylic sheet, it is relatively easy to cut and with a heat gun I can also shape it. Finally it gives things a very “skeletonized” see-through tech aesthetic.

As the core of my device is a “lock box” I looked around for some inspiration and found some vault door designs out there. I decided to come up with my own. First I drew a couple of ideas, then I extended it to what a full 5 pin vault door would look like with a simple HTML animation (I am sure there are some good engineering tools for this, keen to hear people’s thoughts) and finally to make sure I get my head around any tolerances and interferences I built a prototype of one arm.

Above are 5 “T-shaped” pins running through the motion of lock and unlock driven by a central round piece.

A perspex model to iron out tolerances and my construction limitations.

Stepper motor

I presume there are a number of ways I could power my vault door, but as I have never actually used a stepper motor, nothing like now being the right time. I got some ULN2003 based 28BYJ-48 4-Phase Stepper Motor running at 5V. The ULN2003 input threshold is 2.4 V so the MAX32630FTHR GPIO outputs 3.3 V should be fine. As each input draws ~1 mA through the built-in 2.7 kΩ base resistor — no translator required.

The other good thing is, the stepper is geared down, which means it will prevent being “forced open” ie the gears are 1 way and the vault door will stay shut unless the decision is made by the device to power the stepper. This is the case if I used a motor with a worm drive but not the case with most servos and they can be pushed into position.

As I am deep in C-land with LPSDK, I don’t get the benefit of just including a library like

// Includes the Arduino Stepper Library
#include <Stepper.h>

// Defines the number of steps per rotation
const int stepsPerRevolution = 2038;

// Creates an instance of stepper class
// Pins entered in sequence IN1-IN3-IN2-IN4 for proper step sequence
Stepper myStepper = Stepper(stepsPerRevolution, 8, 10, 9, 11);

Fortunately the library is open source so looking at the code

https://github.com/arduino-libraries/Stepper/blob/master/src/Stepper.h

shows me the details of controlling the various coils in the stepper motor. This is good as initially my guesses were wrong and I had it erratically turning in 1 direction and just buzzing on the spot when directed in reverse. Fortunately no smoke left the devices.

Finally I got the motor working once I worked out the delay to take between steps, 3 ms, and the correct coils to power at the correct time.

/* -------------------------------------------------------------------------
 * 28BYJ-48 stepper via ULN2003 driver board.
 *
 * Gear ratio: 32 internal steps × 63.68 ≈ 2037.9 → use 2038 full / 4076 half.
 * Reverse (-steps): table index retreats instead of advances.
 * Coils stay energised after a move — holds gearbox meshed for clean reversal.
 * ------------------------------------------------------------------------- */

static const uint8_t wave_step[4][4] = {
    { 1, 0, 0, 0 },   /* IN1        */
    { 0, 1, 0, 0 },   /* IN2        */
    { 0, 0, 1, 0 },   /* IN3        */
    { 0, 0, 0, 1 },   /* IN4        */
};

static const uint8_t half_step[8][4] = {
    { 1, 0, 0, 0 },   /* IN1        */
    { 1, 1, 0, 0 },   /* IN1+IN2    */
    { 0, 1, 0, 0 },   /* IN2        */
    { 0, 1, 1, 0 },   /* IN2+IN3    */
    { 0, 0, 1, 0 },   /* IN3        */
    { 0, 0, 1, 1 },   /* IN3+IN4    */
    { 0, 0, 0, 1 },   /* IN4        */
    { 1, 0, 0, 1 },   /* IN4+IN1    */
};

static const uint8_t (*active_table)[4] = half_step;
static int      table_len     = 8;
static uint32_t step_delay_us  = 2944;   /* 5 RPM – 60,000,000 / 4076 / 5 */
static int      steps_per_rev  = 4076;   /* 32 × 63.68 × 2 */

also some fine tuning on the delay settings based on the Stepper.cpp file

Half-step: 2,944 µs → 5 RPM (60,000,000 / 4076 / 5)
Wave drive: 1,963 µs → 15 RPM (60,000,000 / 2038 / 15)

and success

I am starting to bring a bunch of things together, the MAX32630FTHR connecting to a fingerprint reader, powering a stepper motor, being configured with a rotary encoder and displaying things on an LED matrix. Still I am not sure if that will be enough to enable a lock box that needs more than 1 person to verify for it to be unlocked. For that I am hoping to investigate BLE (Bluetooth Low Energy) and maybe a phone app to help configure it, that said the phone is likely to be locked into the lock box, so maybe only for configuring the lock box. Then there is connecting the stepper motor to the vault mechanism and only a few weeks left in the competition — 24th May 2026.

Source

https://github.com/saramic/sentinel-box

Guardian Sentinel - Sensor & Motor

meera_hussien — Mon, 11 May 2026 09:10:33 GMT

Guardian Sentinel - Sensor & Motor

<Part 5>

The sensor that i planned to use in this design is the SGP30 and SHT40 sensor.

What is SGP30 sensor?

The SGP30 is a digital multi-pixel gas sensor developed for simple integration into air purifiers, demand-controlled ventilation systems, and IoT-based applications. Sensirion’s CMOSens® technology combines a complete sensor system into a single chip, including a digital I²C interface, a temperature-controlled micro hotplate, and two preprocessed indoor air quality output signals. As one of the first metal-oxide gas sensors with multiple sensing elements integrated on a single chip, the SGP30 can provide more comprehensive information about indoor air quality.

Here is the simple infographic about the sensor

The one which i am using is from Seeedstudio. A grove based sensor

The sensor is connected to the

What is SHT40 sensor?

The Grove SHT40 digital sensor is built around Sensirion’s proven humidity and temperature sensing technology. It delivers reliable temperature and humidity measurements across a wide measurement range. With the Grove connector system, the SHT40 sensor can be easily connected and used with a wide range of microcontrollers, making it suitable for quick plug-and-play prototyping.

Here is the simple infographic about the sensor

Both the sensor is interfaced to the FTHR-PMD-INTZ Feather-to-PMOD via i2C. Figure below shows how the pinout for the i2C connection.

At the top we connect the SGP30 sensor and at the bottom we connect the SHT40 sensor as shown in the image below

Once the sensor are connected, we re-run the i2c scanner code to ensure that the sensor are detected by the MAX32630FTHR and also to get respective i2C address.

#include <Wire.h>

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

  Serial.println("MAX32630FTHR I2C Scanner");
  Wire.begin();
}

void loop() {
  byte error, address;
  int devices = 0;

  Serial.println("Scanning I2C bus...");

  for (address = 1; address < 127; address++) {
    Wire.beginTransmission(address);
    error = Wire.endTransmission();

    if (error == 0) {
      Serial.print("I2C device found at address 0x");
      if (address < 16) Serial.print("0");
      Serial.println(address, HEX);
      devices++;
    }
  }

  if (devices == 0) {
    Serial.println("No I2C devices found.");
  } else {
    Serial.print("Total devices found: ");
    Serial.println(devices);
  }

  Serial.println();
  delay(3000);
}

The serial output shows the sensor are detected and also the i2C address as well

Once we have the i2C address, we can now write the code the read both the sensor values

#include <Wire.h>
#include <Adafruit_SGP30.h>
#include <Adafruit_SHT4x.h>
#include <Adafruit_Sensor.h>

// Sensor objects
Adafruit_SGP30 sgp30;
Adafruit_SHT4x sht40 = Adafruit_SHT4x();

// I2C addresses
#define SGP30_ADDR 0x58
#define SHT40_ADDR 0x44

unsigned long lastReadTime = 0;
const unsigned long readInterval = 2000; // Read every 2 seconds

// Function to calculate absolute humidity for SGP30 compensation
// Input: temperature in Celsius, relative humidity in %
// Output: absolute humidity in mg/m^3
uint32_t getAbsoluteHumidity(float temperature, float humidity) {
  const float absoluteHumidity =
    216.7f *
    ((humidity / 100.0f) * 6.112f *
    exp((17.62f * temperature) / (243.12f + temperature)) /
    (273.15f + temperature));

  return (uint32_t)(absoluteHumidity * 1000.0f);
}

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

  Serial.println();
  Serial.println("SGP30 + SHT40 Sensor Test");
  Serial.println("-------------------------");

  Wire.begin();

  // Start SHT40
  if (!sht40.begin(&Wire)) {
    Serial.println("SHT40 not detected at address 0x44.");
    Serial.println("Check wiring and I2C connection.");
    while (1);
  }

  Serial.println("SHT40 detected at address 0x44.");

  // Optional SHT40 settings
  sht40.setPrecision(SHT4X_HIGH_PRECISION);
  sht40.setHeater(SHT4X_NO_HEATER);

  // Start SGP30
  if (!sgp30.begin(&Wire)) {
    Serial.println("SGP30 not detected at address 0x58.");
    Serial.println("Check wiring and I2C connection.");
    while (1);
  }

  Serial.println("SGP30 detected at address 0x58.");

  Serial.print("SGP30 serial number: ");
  Serial.print(sgp30.serialnumber[0], HEX);
  Serial.print(sgp30.serialnumber[1], HEX);
  Serial.println(sgp30.serialnumber[2], HEX);

  Serial.println();
  Serial.println("Allow the SGP30 to warm up for stable readings.");
  Serial.println();
}

void loop() {
  if (millis() - lastReadTime >= readInterval) {
    lastReadTime = millis();

    sensors_event_t humidityEvent;
    sensors_event_t temperatureEvent;

    // Read SHT40 temperature and humidity
    sht40.getEvent(&humidityEvent, &temperatureEvent);

    float temperature = temperatureEvent.temperature;
    float humidity = humidityEvent.relative_humidity;

    // Calculate absolute humidity for SGP30 compensation
    uint32_t absoluteHumidity = getAbsoluteHumidity(temperature, humidity);

    // Send humidity compensation to SGP30
    sgp30.setHumidity(absoluteHumidity);

    // Read SGP30 air quality values
    if (!sgp30.IAQmeasure()) {
      Serial.println("Failed to read SGP30.");
      return;
    }

    Serial.println("===== Sensor Readings =====");

    Serial.print("SHT40 Temperature : ");
    Serial.print(temperature);
    Serial.println(" °C");

    Serial.print("SHT40 Humidity    : ");
    Serial.print(humidity);
    Serial.println(" %RH");

    Serial.print("SGP30 TVOC        : ");
    Serial.print(sgp30.TVOC);
    Serial.println(" ppb");

    Serial.print("SGP30 eCO2        : ");
    Serial.print(sgp30.eCO2);
    Serial.println(" ppm");

    Serial.print("Abs Humidity      : ");
    Serial.print(absoluteHumidity);
    Serial.println(" mg/m3");

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

The output

Next we shall see how to interface the stepper motor. Below is the stepper motor i use in this project and the wiring diagram. I am using the stepper motor as shown in image below

The connection between the stepper FeatherWing and the stepper motor is done as shown in the image below

Coil 1 from stepper motor is connected to M3 and coil 2 is connected to M4. Since the FeatherWing has two port, please ensure you are connecting which port. Port 1 is connected with M1 and M2 and Port 2 is connected to M3 and M4. In my case i am using the Port 2. Once the wiring for the motor is complete, connect the external power to power up the stepper motor. And i run the code below to test if everything works fine.

#include <Wire.h>
#include <Adafruit_MotorShield.h>

#define MOTOR_ADDR 0x60
#define STEPPER_PORT 2
#define STEPS_PER_REV 200

Adafruit_MotorShield AFMS = Adafruit_MotorShield(MOTOR_ADDR);
Adafruit_StepperMotor *myMotor = AFMS.getStepper(STEPS_PER_REV, STEPPER_PORT);

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

  Serial.println("Stepper Smooth Test - M3/M4");

  Wire.begin();

  if (!AFMS.begin()) {
    Serial.println("Motor FeatherWing not found at 0x60.");
    while (1);
  }

  Serial.println("Motor FeatherWing found.");
  Serial.println("Using Port 2: M3/M4");

  myMotor->setSpeed(5);  // Try 5, 10, 20
}

void loop() {
  Serial.println("Forward MICROSTEP...");
  myMotor->step(200, FORWARD, MICROSTEP);
  delay(1000);

  Serial.println("Backward MICROSTEP...");
  myMotor->step(200, BACKWARD, MICROSTEP);
  delay(1000);
}

And the video below is the working demo

community.element14.com/.../video_5F00_2026_2D00_05_2D00_11_5F00_16_2D00_56_2D00_39.mp4

Now all are working fine. Next is the integration.

Part 2 Tracking Sentry: Components and Design Plan

adam_k — Sat, 09 May 2026 04:21:03 GMT

Bit late to get started, I know, but unavoidable given exams and travel commitments. Thankfully I’ve found myself with some free time and all the components I ordered have arrived so should be smooth sailing from now on (sarcasm).

This is my second post so I’ll start with a reminder of what my project is, walk through the components I’ve chosen for it, get into some specifics, then explain my action plan and potential challenges ahead.

The Project

My project is essentially a two-node autonomous security system. Node A includes a camera and stepper motor to pick up movement and follow a target. It also uses the board’s in-built IMU to detect when it is being tampered with. This data is then sent via Bluetooth to Node B – the ‘command station’. This receives the alert (movement or tampering), and outputs the relevant signal on the LED board. It should also log the incident to the main computer using a simple Python server.

The Components

I was lucky enough to win the nomination and receive many components for free. My proposal was based around this and I try to incorporate as many elements of these as possible within my design. Others were ordered specifically for the project and I also take advantage of my existing inventory.

The motor

This is essential for my camera to pan and track targets. Otherwise it is just a stationary camera which is not very useful nor creative. I decided a NEMA 17 motor would be most useful for my project and ordered one along with a steel mounting bracket for stability. At least that was the intention and have since come to find the bracket may act more as dead weight than anything useful. Well at least it looks nice. I also ordered a 5mm coupling for the motor shaft, allowing me to directly mount components on top of the motor. Probably avoided in industry but works fine for this.

The stepper motor is driven with the included ADA2927 driver. Two are included but only one is needed. This is powered from a wall AC – 12V 1 A adapter, split into two terminals with a DC barrel jack – 2 pin connector. Slightly concerned by the 12W output but may be acceptable for a single NEMA 17 motor not needing much torque.

The camara (and rest of Node A)

I am using the Arducam Mini 2MP Plus OV2640. Should be able to suitably take power from our setup and send data to the Node A MAX32630FTHR#. The camera should provide suitable on-board compression to allow the board to process frame differences to detect movement and drive the motor. The IMU should also work to detect tampering (IMU triggering disabled during motor movement to eliminate false detections). Given unfortunate time constraints there won’t be SD storage. State information and times are sent to Node B via Bluetooth. States being “connection”, “movement” and “tampering”. No connection could display static or something on the LED matrix. This just makes it look more engaging than just having a single LED light up to imply a state. Data should be sent to the computer to log state and timing information. The board on A will be powered directly with a 3.7V lithium battery.

Node B

This is pretty straightforward. Just another board connected to an LED matrix display. Either the CharliePlex FeatherWing 7x15 or the Würth Elektronnik ICLED Featherwing. If feasible within time constraints the Ethernet adapter will also be included. Since this is intended as the ‘command station’ we can just power it using USB from the computer.

Other stuff

There are some other components included such as the FTHR-PMD-INTZ Adapter which is likely necessary. I also have a couple 9V batteries, breadboards, wires, jumper wires, wire strippers, and a Leatherman Wave (very useful) which will all be incorporated.

The Plan

Time is very limited for me but there’s no point jumping in trying to get to the final design immediately. I plan to build this up in stages and test parts individually before putting it all together.

I’ll first start by getting one of the boards to display patterns on the LED matrix. This shows I can get the board powered up properly and code running. Then I’ll try triggering this by a Bluetooth signal from the other board. Then I’ll set up Node A to control the motor to angle the camera. Perhaps the trickiest I’ll attempt to get the camera module feeding data to the board, have the board analyse the frames, and use the analysis to direct the camera towards movement. If by miracle this all works well then I should be able to integrate this all together in addition with the IMU detection.

Final Thoughts

I have a clear plan ahead now and am excited for the days to come. To be honest I am a little nervous about this not working out perfectly within the time constraints but I hope to have something running to demonstrate, even if it means some deviation from the original plan. I’ve worked on more complex stuff before though not in the same time constraints. Regardless, it will be a learning experience and I will be documenting the whole process. The free socks are also appreciated!

Guardian Sentinel — The Slave

meera_hussien — Sat, 09 May 2026 00:29:33 GMT

Guardian Sentinel - The Slave

<Part 4>

For the slave, i decided to use the similar setup, hence i decide to use the FeatherWing Tripler Mini Kit.

The following image shows the header pins being soldered

Once finish soldering, I place the MAX32630FTHR in the middle.

Followed by the FTHR-PMD-INTZ Feather-to-PMOD

Which is place to the right of the MAX32630FTHR

For further info on the FTHR-PMD-INTZ Feather-to-PMOD click here. Following that, i place the DC Motor + Stepper FeatherWing Addon.

Which is place to left of the MAX32630FTHR

To ensure all the three boards are connected, i did the i2C scanner and below are the result

#include <Wire.h>

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

  Serial.println("MAX32630FTHR I2C Scanner");
  Wire.begin();
}

void loop() {
  byte error, address;
  int devices = 0;

  Serial.println("Scanning I2C bus...");

  for (address = 1; address < 127; address++) {
    Wire.beginTransmission(address);
    error = Wire.endTransmission();

    if (error == 0) {
      Serial.print("I2C device found at address 0x");
      if (address < 16) Serial.print("0");
      Serial.println(address, HEX);
      devices++;
    }
  }

  if (devices == 0) {
    Serial.println("No I2C devices found.");
  } else {
    Serial.print("Total devices found: ");
    Serial.println(devices);
  }

  Serial.println();
  delay(3000);
}

and the result from the serial monitor is shown below

In the next post we shall see on interfacing with sensor and motor.

Guardian Sentinel — Ethernet & BLE

meera_hussien — Fri, 08 May 2026 09:37:37 GMT

Guardian Sentinel — Ethernet & BLE

<Part 3>

In the previous post we have seen about how to program the MAX32630FTHR and the OLED. In this post we shall see how to configure the ethernet and the BLE.

Ethernet

Since we are using the ethernet FeatherWing, there is onboard RJ45 connector with controller. The image below shows the details of the device.

The board is based one the WIZnet5500 and take the form factor of the Adafruit FeatherWing Tripler. It can support

10BaseT/100BaseTX Ethernet
Support Auto Negotiation (Full and half duplex, for both 10BaseT and 100BaseTX)

In order to test the ethernet connectivity i have use the following code. And the serial output shows the output. I have also configure the OLED to show the output as well.

#include <SPI.h>
#include <Ethernet.h>

#define STATUS_LED LED_BUILTIN

#define ETH_CS    44
#define ETH_RESET 46

byte mac[] = { 0xDE, 0xAD, 0xBE, 0xEF, 0x32, 0x30 };

void resetEthernet() {
  pinMode(ETH_RESET, OUTPUT);

  digitalWrite(ETH_RESET, HIGH);
  delay(100);

  digitalWrite(ETH_RESET, LOW);
  delay(300);

  digitalWrite(ETH_RESET, HIGH);
  delay(1000);
}

void setup() {
  pinMode(STATUS_LED, OUTPUT);

  Serial.begin(9600);
  delay(3000);

  Serial.println();
  Serial.println("==============================");
  Serial.println("MAX32630FTHR + Particle Ethernet");
  Serial.println("==============================");

  SPI.begin();

  resetEthernet();

  Ethernet.init(ETH_CS);

  Serial.println("Starting DHCP...");

  if (Ethernet.begin(mac) == 0) {
    Serial.println("DHCP failed.");
    while (true) {
      digitalWrite(STATUS_LED, HIGH);
      delay(300);
      digitalWrite(STATUS_LED, LOW);
      delay(300);
    }
  }

  Serial.println("DHCP successful!");
  Serial.print("Local IP: ");
  Serial.println(Ethernet.localIP());

  Serial.print("Subnet: ");
  Serial.println(Ethernet.subnetMask());

  Serial.print("Gateway: ");
  Serial.println(Ethernet.gatewayIP());

  Serial.print("DNS: ");
  Serial.println(Ethernet.dnsServerIP());
}

void loop() {
  Ethernet.maintain();

  Serial.print("Running. IP: ");
  Serial.println(Ethernet.localIP());

  digitalWrite(STATUS_LED, !digitalRead(STATUS_LED));
  delay(3000);
}

The library used is the Ethernet.h. And below is the serial output.

And i have tried to show the status update of the ethernet on the OLED as well

Next lets configure the BLE

BLE

Initially i found that, most of the resources are using the Mbed OS to setup the BLE. After researching and also the sharing from other participant, below is the code that i am using to check the BLE.

#include <pwrseq_regs.h>
#include <pwrman_regs.h>
#include <Wire.h>
#include <Adafruit_GFX.h>
#include <Adafruit_SSD1306.h>

// -------------------- Bluetooth Settings --------------------
#define BT_SERIAL Serial0
#define BT_RST    P1_6

// -------------------- OLED Settings --------------------
#define SCREEN_WIDTH 128
#define SCREEN_HEIGHT 32
#define OLED_RESET -1
#define OLED_ADDR 0x3C

Adafruit_SSD1306 display(SCREEN_WIDTH, SCREEN_HEIGHT, &Wire, OLED_RESET);
bool oledOK = false;

// -------------------- HCI Commands --------------------
const byte HCI_RESET_CMD[] = {
  0x01, 0x03, 0x0C, 0x00
};

const byte HCI_READ_BD_ADDR[] = {
  0x01, 0x09, 0x10, 0x00
};

const byte HCI_LE_READ_LOCAL_SUPPORTED_FEATURES[] = {
  0x01, 0x03, 0x20, 0x00
};

// -------------------- Helper Functions --------------------
void showOLED(String line1, String line2, String line3 = "", String line4 = "") {
  if (!oledOK) return;

  display.clearDisplay();
  display.setTextSize(1);
  display.setTextColor(SSD1306_WHITE);

  display.setCursor(0, 0);
  display.println(line1);

  display.setCursor(0, 8);
  display.println(line2);

  display.setCursor(0, 16);
  display.println(line3);

  display.setCursor(0, 24);
  display.println(line4);

  display.display();
}

void setupOLED() {
  Wire.begin();

  if (!display.begin(SSD1306_SWITCHCAPVCC, OLED_ADDR)) {
    Serial.println("OLED not detected.");
    oledOK = false;
    return;
  }

  oledOK = true;
  showOLED("MAX32630FTHR", "OLED Started", "BLE Detect Test");
  delay(1500);
}

void printHexByte(byte b) {
  if (b < 0x10) Serial.print("0");
  Serial.print(b, HEX);
  Serial.print(" ");
}

void clearBTBuffer() {
  while (BT_SERIAL.available()) {
    BT_SERIAL.read();
  }
}

void configureBluetoothUART() {
  // Enable 32.768 kHz oscillator output on P1.7
  MXC_PWRSEQ->reg4 |= MXC_F_PWRSEQ_REG4_PWR_PSEQ_32K_EN;

  // Start HCI UART
  BT_SERIAL.begin(115200);

  // Swap RX/TX lines and enable CTS/RTS
  MXC_IOMAN->uart0_req |= MXC_F_IOMAN_UART0_REQ_CTS_IO_REQ |
                          MXC_F_IOMAN_UART0_REQ_RTS_IO_REQ |
                          MXC_F_IOMAN_UART0_REQ_IO_MAP;
}

void hardwareResetBT() {
  pinMode(BT_RST, OUTPUT);

  digitalWrite(BT_RST, LOW);
  delay(1000);

  digitalWrite(BT_RST, HIGH);
  delay(3000);

  clearBTBuffer();
}

bool readHCIResponse(byte *buffer, int &length, unsigned long timeoutMs) {
  length = 0;
  unsigned long startTime = millis();

  while (millis() - startTime < timeoutMs) {
    while (BT_SERIAL.available()) {
      byte data = BT_SERIAL.read();

      if (length < 64) {
        buffer[length++] = data;
      }
    }
  }

  return length > 0;
}

bool sendHCICommand(const byte *cmd, int cmdLen, const char *label, byte *response, int &responseLen) {
  Serial.println();
  Serial.print("Sending: ");
  Serial.println(label);

  clearBTBuffer();

  BT_SERIAL.write(cmd, cmdLen);

  bool gotResponse = readHCIResponse(response, responseLen, 2500);

  Serial.print("Response: ");

  if (!gotResponse) {
    Serial.println("No response");
    return false;
  }

  for (int i = 0; i < responseLen; i++) {
    printHexByte(response[i]);
  }

  Serial.println();

  return true;
}

bool checkStatusOK(byte *response, int responseLen) {
  // HCI Command Complete format:
  // 04 0E XX 01 OP_LSB OP_MSB STATUS ...
  if (responseLen >= 7 && response[0] == 0x04 && response[1] == 0x0E) {
    return response[6] == 0x00;
  }

  return false;
}

String extractBDADDR(byte *response, int responseLen) {
  // Read BD_ADDR response:
  // 04 0E 0A 01 09 10 00 XX XX XX XX XX XX
  // Address is returned LSB first
  if (responseLen >= 13 && response[6] == 0x00) {
    String addr = "";

    for (int i = 12; i >= 7; i--) {
      if (response[i] < 0x10) addr += "0";
      addr += String(response[i], HEX);

      if (i > 7) addr += ":";
    }

    addr.toUpperCase();
    return addr;
  }

  return "Unknown";
}

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

  Serial.println();
  Serial.println("MAX32630FTHR BLE Module Detection Test");
  Serial.println("--------------------------------------");

  setupOLED();
  showOLED("BLE Test", "Starting...");

  configureBluetoothUART();

  bool detected = false;
  String btAddress = "Unknown";

  for (int attempt = 1; attempt <= 5; attempt++) {
    Serial.println();
    Serial.print("BLE detection attempt ");
    Serial.println(attempt);

    showOLED("BLE Detect", "Attempt " + String(attempt), "Resetting module");

    hardwareResetBT();

    byte response[64];
    int responseLen = 0;

    bool resetOK = sendHCICommand(
      HCI_RESET_CMD,
      sizeof(HCI_RESET_CMD),
      "HCI Reset",
      response,
      responseLen
    );

    if (resetOK && checkStatusOK(response, responseLen)) {
      Serial.println("HCI Reset: OK");
      showOLED("BLE Module", "HCI Reset OK", "Reading address");

      bool addrOK = sendHCICommand(
        HCI_READ_BD_ADDR,
        sizeof(HCI_READ_BD_ADDR),
        "Read BD_ADDR",
        response,
        responseLen
      );

      if (addrOK && checkStatusOK(response, responseLen)) {
        btAddress = extractBDADDR(response, responseLen);
        Serial.print("Bluetooth Address: ");
        Serial.println(btAddress);

        bool leOK = sendHCICommand(
          HCI_LE_READ_LOCAL_SUPPORTED_FEATURES,
          sizeof(HCI_LE_READ_LOCAL_SUPPORTED_FEATURES),
          "LE Read Local Supported Features",
          response,
          responseLen
        );

        if (leOK && checkStatusOK(response, responseLen)) {
          Serial.println("LE Feature Check: OK");
          detected = true;
          break;
        }
      }
    }

    Serial.println("BLE module not ready. Retrying...");
    delay(1000);
  }

  Serial.println();

  if (detected) {
    Serial.println("BLE MODULE DETECTED SUCCESSFULLY");
    Serial.print("BD_ADDR: ");
    Serial.println(btAddress);

    showOLED(
      "BLE: Detected",
      "HCI: OK",
      btAddress,
      "LE Feature: OK"
    );
  } else {
    Serial.println("BLE MODULE NOT DETECTED");

    showOLED(
      "BLE: Not Found",
      "Check reset/UART",
      "Try board reset"
    );
  }
}

void loop() {
  // Nothing needed. The result remains on OLED.
}

And we can monitor the status on oled. The image below shows the status of the BLE on the OLED.

Now the MASTER is ready. We can now prepare the SLAVE.

Identity Protocol - Part 10 - W5500 Ethernet

arvindsa — Tue, 05 May 2026 05:09:14 GMT

Argh, Writing a good post is definitely the hard part. :D i completed interfacing all the necessary modules almost a week ago, I am also working on other projects in parallel, but this weekend, i managed to sit down and write this post. The final piece of the jigsaw in my project is to get W5500 to interface with the MAX32630.

Recap:

The idea is simple enough: stop making people swipe a card and type a PIN at every single door. Instead, the ID card (a MAX32630FTHR + ATECC508A in your pocket) unlocks once via PIN, then silently does challenge-response crypto over Bluetooth every time you walk up to a door. If the card gets yanked off you, the IMU detects the tug and it locks itself. No PIN, no entry. For more details check the Part 1 of the series

The SPI Protocol: Reads, Writes, and Verifying Connectivity

The SPI transaction requires three bytes of command header (address + block + direction) followed by one or more data bytes. The direction is in the control byte:

Read:  [ADDR_H][ADDR_L][BSB|READ |OM][DATA_IN_FROM_W5500...]
Write: [ADDR_H][ADDR_L][BSB|WRITE|OM][DATA_OUT_TO_W5500...]

RWB bit: 0 = read, 1 = write. OM (Operation Mode) is almost always 0 for variable-length reads/writes. BSB is the block selection bits to say which memory i want to access.

The first test is always the same: read VERSIONR (register 0x39 in the common block, BSB 0x00). The W5500 should respond as 0x04.

static int w5500_read(uint16_t addr, uint8_t *rx, int len)
{
    uint8_t tx[3] = {
        (uint8_t)(addr >> 8),                   /* ADDR_H */
        (uint8_t)(addr & 0xFF),                 /* ADDR_L */
        (W5500_BSB_COMMON << 3) | W5500_READ    /* control: BSB 0x00, READ */
    };
    return spi_read_write(tx, 3, rx, len);
}

uint8_t version = 0;
w5500_read(W5500_REG_VERSIONR, &version, 1);
if (version != 0x04) {
    printf("W5500 not responding. VERSIONR = 0x%02x\n", version);
    return -1;
}
printf("W5500 alive. VERSIONR = 0x%02x\n", version);

BSB = 0x00  Common registers // (VERSIONR, IP config etc.)
BSB = 1, 5, 9, 13... → Socket 0, 1, 2, 3... register space (status, control, RX/TX pointers)
BSB = 2, 6, 10, 14... → Socket 0, 1, 2, 3... transmit buffer
BSB = 3, 7, 11, 15... → Socket 0, 1, 2, 3... receive buffer


The formula for socket n:
Registers: BSB = (n * 4) + 1
TX buffer: BSB = (n * 4) + 2
RX buffer: BSB = (n * 4) + 3

Never on the same boat, I mean Voltage

But my code was being heard on deaf ears, No response. I tried going though the documentation, it's clear as day. It should work, But it did not. So, I hooked up my logic analyzer. No signals on the clock lines. Then spend an hour trying to see why the SPI peripherals is not being initiated. I even compiled the official examples, yet no avail. But then I "Accidentally" Clicked the Analog reading of the signal lines and then i saw something like an ECG. The SPI's clock line. But the logic levels was around 1.7V. And then it hit me. The chip is communicating at 1.8V levels. But W5500 Does not respond back to such levels. So first instinct, I used TXB108 Level shifter, I checked the output lines, and it was working but W5500 Never responded. I was greeted with 0xFF

Now, what i noticed is that when i reset, the MOSI was not very consistent. Ideally it was supposed to sent 0x00 0x39 0x00 0x00 (the image above has the ideal sequence) but many times i noticed, there would be extra 0xFF in between the right sequence. I felt the level shifter had to do something to with the ghost bits, In my past, the level shifter had created issues for me. Without a reliable level shifting, I was stuck, But then i remembered the MAX32630 was working fine with the I2C lines which was pulled up to 3.3V which means it is 3.3V tolerant, so i dug into the documentation to find, i can change the Logic level of the Pins on an individual level. Whoa is what i said,

By changing the IOMAN has select bits to move a pins output buffer to another voltage level (use_vddioh_0/1/2). By calling SYS_IOMAN_UseVDDIOH(&cfg) after SPIM_Init, I get a 3.3V SPI Signals

const spim_cfg_t spim_cfg = { .mode=0, .ssel_pol=SPIM_SSEL0_LOW, .baud=1000000 };
SPIM_Init(MXC_SPIM2, &spim_cfg, &sys_cfg);

const gpio_cfg_t spim2_vddioh = {
    PORT_5, (PIN_0 | PIN_1 | PIN_2 | PIN_3),
    GPIO_FUNC_GPIO, GPIO_PAD_NORMAL
};
SYS_IOMAN_UseVDDIOH(&spim2_vddioh);

Careful enough to change only the SPI lines i tried again and It is alive. W5500 was talking back 0x40.

Back to SPI Protocol

To write a register, i use

static int w5500_write(uint16_t addr, const uint8_t *tx, int len)
{
    uint8_t cmd[3] = {
        (uint8_t)(addr >> 8),
        (uint8_t)(addr & 0xFF),
        (W5500_BSB_COMMON << 3) | W5500_WRITE   /* BSB 0x00, WRITE */
    };
    return spi_write(cmd, 3, tx, len);
}

uint8_t mac[6] = {0x00, 0x08, 0xDC, 0xAB, 0xCD, 0xEF};
w5500_write(W5500_REG_SHAR, mac, 6);            /* set source hardware address */

To read a socket register, i use the the code below with the BSB calulated as per the code above

int sreg_read(int socket, uint16_t offset, uint8_t *rx, int len)
{
    uint16_t addr = offset;
    uint8_t bsb = W5500_BSB_SREG(socket);   /* computes (socket*4)+1 */
    uint8_t tx[3] = {
        (uint8_t)(addr >> 8),
        (uint8_t)(addr & 0xFF),
        (bsb << 3) | W5500_READ
    };
    return spi_read_write(tx, 3, rx, len);
}

uint8_t sr;
sreg_read(0, Sn_SR, &sr, 1);   /* read socket 0 status register */
if (sr == SOCK_ESTABLISHED) {
    /* socket is connected */
}

TCP: Open, Connect, Send, Receive, Close

The W5500 has a simple socket abstraction. Each operation sets a CR (Command Register) value and polls the SR (Status Register) for the result/

Step	Write CR	Poll SR until	Timeout
Open	`CR_OPEN`	`SOCK_INIT`	100 ms
Connect	`CR_CONNECT`	`SOCK_ESTABLISHED`	5 s
Send	`CR_SEND`	`Sn_IR.SEND_OK`	1 s
Recv	(no cmd)	`Sn_RX_RSR > 0`	per attempt
Close	`CR_DISCON` then `CR_CLOSE`	`SOCK_CLOSED`	200 ms

The So i code tcp_recv, which reads in a loop until either the buffer fills or the remote closes the connection and yes, i used HTTP1 which i copied from the regular arduino library.

static int tcp_recv(int sn, uint8_t *buf, int max_len)
{
    int total = 0;
    for (int idle = 0; idle < 100 && total < max_len; idle++) {
        uint16_t avail = sreg_r16(sn, Sn_RX_RSR);
        if (avail == 0) {
            uint8_t sr = sreg_r8(sn, Sn_SR);
            if (sr == SOCK_CLOSE_WAIT || sr == SOCK_CLOSED) break;
            TMR_Delay(MXC_TMR0, MSEC(50));
            continue;
        }
        int n = avail;
        if (total + n > max_len) n = max_len - total;
        uint16_t rd = sreg_r16(sn, Sn_RX_RD);
        srx_read(sn, rd, buf + total, n);
        sreg_w16(sn, Sn_RX_RD, rd + (uint16_t)n);
        sreg_w8(sn, Sn_CR, CR_RECV);
        total += n;
        idle = 0;
    }
    return total;
}

I did use static ip configuration for my LAN, and copied more and more working from the arduino library to interface the actual requests. Explaining that will be far too gruesome and more sleep inducing than Propofol So i will end it here. Now for the 3D printing and integration

Final Notes

When you are used to Arduino Libraries for quick prototyping, you forget to appreciate the work done by the developers to get these things working. Even porting an existing code to a diferent platform to make it work the SDK is a huge task. So respects to the Developers. Now, truth be told, My code is bit flaky and does not work 20% of the time, I am not going to solve this considering the timeline. But i will take it as a good enough work for the final integration and solve it there if needed.

Sentinel Box - Part II - back to C

saramic — Thu, 30 Apr 2026 12:42:46 GMT

I had fun with my Rust 🦀 experiment but it was time to get back to C and LPSDK (Low Power ARM Micro SDK) if I was going to get anything complete for this challenge.

Recap

The idea is to build a smart lock box for digital devices to help control digital addiction, more on the idea can be found in part I

Sentinel Box - Part I - the plan

Rust for Hermetic builds

As I was not super happy in having to depend on EOL (End-of-life) software stacks like Mbed or LPSDK, I thought, how hard can it be writing a HAL (Hardware Abstraction Layer) from scratch in Rust. I had some initial wins getting the LED flashing, so I continued. In Part I I even started implementing some commands against the MAX14690 PMIC (Power Management Integrated Circuit) - I was actually going above and beyond and looking at the schematic of the dev board to see how it hangs together. This should have turned me OFF the idea of rust, but it gave me some false hope and I continued.

The BMi160 accelerometer chip highlighted on the block diagram of the MAX32630FTHR

Next on the diagram there was an Accelerometer and Gyroscope using the BMi160 6-Axis Inertial Motion Sensor. With a bit of AI I soon enough had a driver to get X, Y, Z accelerations and using the MAX7219 I built a simple “attitude meter” which would show you which way to move the board to correct it being right way round. At this point I started to notice that some of the timing was out, my LED refresh rate was out by anywhere from 4x to 20x - that should have turned me OFF the idea of rust but with false hopes I continued.

community.element14.com/.../20260423_5F00_01_5F00_attitude_5F00_meter.mp4
The video above shows the attitude meter 🛩️ that displays on the LED matrix the direction to turn the device to flatten the chip.

These were all distractions from the core of the Smart Security Challenge, so it was time to use a finger print reader. This would need UART (Universal Asynchronous Receiver-Transmitter) surely that cannot be hard? Well this is where the speed changes of 4X – 20X really started to bite. You see if you don’t know how fast your clock speed is going, you are not going to be able to transmit or receive at a given Baud. I tried a bunch of things. As I don’t have a logic analyzer nor oscilloscope on hand, I ended up hooking up an ESP32 to measure the duration of pulses. I didn’t know there was a function to measure pulse length pulseIn

unsigned long width = pulseIn(RX2_PIN, LOW, 5000000UL); // 5 s timeout
if (width == 0) {
  Serial.println("timeout — no signal on RX pin");
  return;
}
// Filter noise: allow 1200–115200 baud = 8–833 µs.
if (width < 8 || width > 833) {
  Serial.printf("noise/glitch: %lu µs (ignored)\n", width);
  return;
}
unsigned long estimated_baud = 1000000UL / width;
  // Square-wave formula: CPU MHz = N / width_µs, where N is the delay_cycles count.
  // Firmware step 1 uses N=4800. Steps double: 4800, 9600, 19200, 38400, 76800.
  // Read the first group of pulses (smallest width) and use N=4800.
Serial.printf(
  "LOW pulse: %lu µs | sq-wave asm::delay(4800)~9600 cycles: CPU ~%lu MHz\n",
  width,
  9600UL / width); // asm::delay(N) ≈ 2N cycles → CPU MHz = 9600 / width_µs

The above code also made me realise that \n does not cut it and my serial monitor only displayed the output when I had \r\n - need that Carriage return.

And all my Rust results were conclusive on 1 part, I was never getting 96 MHz. After some digging around I found the C file in LPSDK that seems to do the setup of the frequency

Maxim/Firmware/MAX3263X/Libraries/CMSIS/Device/Maxim/MAX3263X/Source/system_max3263x.c

Enable the 32 kHz RTC oscillator — this serves as the stable reference clock for calibration, then wait for it to warm up and settle.
Enable the RO calibration complete interrupt — so the system can signal when calibration is done.
Clear the calibration complete interrupt flag — removing any stale state from a previous run.
Write an initial trim value into the frequency calibration initial condition register — giving the hardware a starting point rather than hunting from scratch.
Load that initial trim into the active frequency trim register — making it live.
Enable the frequency control loop — the hardware mechanism that will drive the RO trim toward the target frequency.
Start calibration in atomic mode — the hardware runs the measurement and adjustment cycle uninterrupted.
Wait for the ro_cal_done flag — polling until the hardware signals completion.
Stop the calibration engine.
Disable the calibration complete interrupt.
Read back the final trim value — the digital code the loop converged on.
Write the final trim to the RO flash trim shadow register — persisting the result across resets.
Restore the RTC to its previous state — since it may have been off before the routine borrowed it.
Disable the frequency control loop.

no can do - I tried and tried again but could not get a consistent 96 MHz set which meant the UART was not going to work and the rust experiment was over for the time being

❌🦀

Back to LPSDK

I couldn’t get myself to go to Mbed, a platform that is slated for EOL in July 2026, so it was back to C and the legacy LPSDK stack.

Hitting up my ESP32 setup, proved I had the right frequency set on UART and in no time I was connected to the fingerprint reader. The problem was that now my system would need to be multi modal. I pulled in a rotary encoder and got some runs on the board. First just to read turns to the left and right as well as a button press and display it on the LED MAX7219 matrix display. Then I added in the finger print reader.

community.element14.com/.../20260430_5F00_03_5F00_fingerprint_5F00_demo.mp4

Getting the fingerprint, LED Matrix and rotary encoder was the easy bit, but having a state diagram that can save a bunch of fingerprints and identify them was starting to get a bit complicated, as is the setup on my workbench.

Now that I have a basic fingerprint reader and a build system that I am confident in, I think I need to get the required piece for a minimal complete build, some kind of actuator working: stepper motor, servo motor or just a motor with a worm drive. This will allow me to create a lock box with multi finger print triggering. If I get time, I may be able to expand on that. Time will tell.

Source

https://github.com/saramic/sentinel-box

Guardian Sentinel — Getting Started

meera_hussien — Thu, 30 Apr 2026 08:39:01 GMT

Guardian Sentinel — Getting Started

<Part 2>

The figure below shows the basic block diagram and idea of how the project will be implemented. The system will consist of two parts: a master and a slave. The master will use the MAX32630FTHR and will be connected to the LAN through an Ethernet FeatherWing. It will also include a OLED FeatherWing to display status or other useful information. The slave will use another MAX32630FTHR together with the DC Motor + Stepper FeatherWing and a gas sensor. This is the basic idea of the project architecture. Along the process of building of this project i will make the necessary changes in order to accomplish the objective of this project.

As i have mentioned previously, in this second post we would like to see in details and initial setup for all the devices used in this project. First lets take a look at the core of this project which is the MAX32630FTHR.

MAX32630FTHR

From my initial research i found that the MAX32630FTHR can be programmed using MBED OS, but unfortunately it will become obsolete or end of life this coming July. Hence while looking for other alternative, i saw the post from Alistair , mentioning about using Arduino to program the MAX32630FTHR. Here is my initial setup and the step to program the MAX32630FTHR using Arduino IDE. Below is the step to program the MAX32630FTHR with Arduino IDE. Please note that, it can be only used with Arduino IDE 1.8.x. I tried using Arduino 2.3.8, but it does not work.

Once the board is installed. I tried to program the board. The setup for programming the board is as shown in figure below

Programming the MAX32630FTHR setup.

Both the usb need to be connected. The usb on the MAX32630FTHR is for power up the device. And the usb connecting the pico is for programming purpose.

Once the this is done. I try to upload a simple Blink example, to verify. First choose the board as shown in the image below

Next choose the programmer as shown in image below

Once done, i tested the simple blink program and it works. Below is the demo video

community.element14.com/.../video_5F00_2026_2D00_04_2D00_30_5F00_00_2D00_55_2D00_04.mp4

The next thing that i would like to test is the Oled FeatherWing which i am using to display the data. For connection between the MAX32630FTHR and the oled i am using the Ethernet FeatherWing. The setup for this is shown in the figure below

Once the sample code is uploaded, the oled works.

The code for the oled is as shown below.

#include <Wire.h>
#include <Adafruit_GFX.h>
#include <Adafruit_SSD1306.h>

#define SCREEN_WIDTH 128
#define SCREEN_HEIGHT 32
#define OLED_ADDR 0x3C

Adafruit_SSD1306 display(SCREEN_WIDTH, SCREEN_HEIGHT, &Wire);

void setup() {
  Serial.begin(9600);
  delay(1000);

  Serial.println("MAX32630FTHR OLED Test");

  Wire.begin();

  if (!display.begin(SSD1306_SWITCHCAPVCC, OLED_ADDR)) {
    Serial.println("OLED not found at 0x3C");
    while (1);
  }

  display.clearDisplay();
  display.setTextSize(1);
  display.setTextColor(SSD1306_WHITE);
  display.setCursor(0, 0);

  display.println("Guardian Sentinel");
  display.println("MAX32630FTHR");
  display.println("OLED OK");

  display.display();

  Serial.println("OLED initialized");
}

void loop() {
}

In the next post, i will share on the Ethernet FeatherWing and also the setting up of the dashboard.

Forum#5: Proposed Design — Adaptive Sentinel: Security & Surveillance Intelligence Hub

skruglewicz — Thu, 30 Apr 2026 04:37:36 GMT

This Forum post outlines the architecture and the strategic logic driving the system’s coordination.

Design Lineage

The foundation of this design is rooted in the Adaptive Environmental Monitoring project. By leveraging that established architecture, the Adaptive Sentinel expands from purely environmental tracking into a proactive security framework, maintaining the core principles of modularity and edge-based intelligence.

Basic Design: The Architectural Framework

The system is structured around a robust hub-to-node topology, designed for high reliability and low-latency response:

Centralized Coordination: At the heart of the ecosystem is the Arduino UNO Q. It serves as the primary hub, orchestrating the network, aggregating telemetry, and managing high-level logic. The use of containerized Bricks will be helpful in carrying out these tasks without compromising the core system's stability.
Deployment of Edge Nodes: To provide a direct interface for localized relays and sensors, I intend to position edge nodes based on FeatherWing in designated building zones, acting as the primary frontline for data collection.
System Layout & Logic: The operational flow is decentralized yet unified. Edge nodes monitor local environments and transmit critical telemetry to the Arduino UNO Q hub for centralized aggregation and automated response.
Connectivity Strategy: I intend to establish a robust UART infrastructure to guarantee stability during the primary rollout. This wired setup will serve as a performance benchmark, providing a structured path for transitioning to wireless protocols after the integration has been thoroughly confirmed.
Sensor Integration:Sensor Strategic Integration: I intend to strategically select and integrate kit-supplied sensors to maximize the hardware’s efficacy in detecting security breaches and maintaining environmental awareness.

Visualizing the Hub-to-Node Topology

The following Basic Design Diagram details the mapping of FeatherWing edge nodes across various zones. By utilizing the Arduino UNO Q as the central coordinator, the architecture remains scalable.

Hub-to-Node Connectivity Design: This system utilizes a robust hub-to-node topology centered on an Arduino UNO Q coordinator, managing modular FeatherWing edge nodes for localized intelligence. The initial rollout employs a stable UART connectivity strategy. The edge nodes are deployed in two primary functional configurations: Edge Node 1 for Biometrics & Sentiment Analysis, and Edge Node 2 for Active Response & Environmental Control.

HUB Node Architecture: Built on the Arduino UNO Q, the central hub functions as the primary network coordinator, aggregating telemetry from FeatherWing edge nodes. This architecture leverages a dual-processor system where the MPU handles high-level orchestration, intensive data logging, and serving the Web UI, while the MCU manages deterministic low-level communication protocols. Furthermore, the system utilizes a specialized Database BRICK to ensure the reliable storage of all telemetry data streamed from the distributed edge nodes.

Edge Node Architecture: Edge nodes are implemented as modular expansion subsystems. The current deployment strategy utilizes the following functional configurations for localized intelligence.

Edge Node 1 (Biometrics & Sentiment Analysis): This node focuses on human-centric data, monitoring biometric signatures and localized sentiment to assess security states based on occupant presence and behavior.

Edge Node 2 (Active Response & Environmental Control): Serving as the primary execution layer, this node manages physical relays and automated control systems to mitigate identified threats or adjust climate variables in real-time.

The "Request for Help"

Before I finalize the Project Blog and lock in the implementation, I am reaching out to the community. Prior to finalizing the Project Blog and committing to this implementation, I am seeking community insights. I invite you to "identify any loopholes" or logical flaws in my current approach.

Specifically, I am interested in your thoughts on whether the transition from UART to wireless is technically sound and if there are hidden bottlenecks in the hub-to-node telemetry aggregation. My goal is to uncover any technical gaps in the orchestration of this security intelligence system before moving to final deployment.

I value your expertise and look forward to the feedback.

BLE scanning and CC256X firmware uploading

Alistair — Tue, 28 Apr 2026 12:02:18 GMT

After thinking I had everything in place I have just got wound to the BLE scanning, and it turns out that it it not working. Basic Bluetooth functionality appraiser fine, but the BLE functionality is not there. Doh!

Following a hint from online I trued the command 01 01 FE 01 00 (HCI_VS_Write_BD_Addr) and that returned 0x01 (Unknown HCI Command), and that shown new firmware needs uploading. Has anyone done this?Any other suggestions for that matter?

Identity Protocol - Part 9 - BLE GATT Challenge/Response with BTstack

arvindsa — Tue, 28 Apr 2026 06:01:28 GMT

It has been long time since i used Bluetooth SPP. Infact I do not think I ever used Bluetooth SPP via firmware. I think i used an RN42 module to get UART converted to Bluetooth SPP. But I have used BLE GATT so, I will be using that to exchange data between the Door and ID device.

Recap:

GATT Service Definition

BTstack generates an ATT database at plaintext .gatt file. Refer: https://github.com/bluekitchen/btstack/blob/master/tool/compile_gatt.py For our purpose, I need to detect the door and ID card to be nearby, one service to write the nonce and another for the response. I did take help of ChatGPT to generate the file. If you are new to GATT - I recommend to watch this video - www.youtube.com/watch

PRIMARY_SERVICE, GAP_SERVICE
CHARACTERISTIC, GAP_DEVICE_NAME, READ, "Auth-Door"

PRIMARY_SERVICE, GATT_SERVICE
CHARACTERISTIC, GATT_DATABASE_HASH, READ,

// Identity Protocol Auth Service
PRIMARY_SERVICE, AAAAAAAA-0000-0000-0000-000000000001

// CHALLENGE: 32-byte nonce sent by the door, read by the card
CHARACTERISTIC, AAAAAAAA-0000-0000-0000-000000000002, READ | DYNAMIC,

// RESPONSE: 4-byte device_id followed by 64-byte signature written by the card
CHARACTERISTIC, AAAAAAAA-0000-0000-0000-000000000003, WRITE | DYNAMIC,

For Testing two Roles, One Source File

Both the door and the card run on identical hardware (MAX32630FTHR + PAN1326B), so the test is a single C file compiled twice. A ROLE make variable drives the split:

make ROLE=server    # door firmware
make ROLE=client    # card firmware

-DROLE_SERVER / -DROLE_CLIENT select which half of gatt_auth.c is compiled. The server advertises, serves CHALLENGE when ID card nearby, and verifies writes to RESPONSE. The client scans, connects, reads CHALLENGE, signs, and writes RESPONSE.

The Server Side (Door)

The server's packet handler wakes up three places: stack ready, client connected, and every ATT write. When client connected, we serve the once, when ATT writes to the signature service, we verify it.

Even though i have only one feather to function as a ID device, i made the firmware such that it can store multiple ID Cards device name and their public key to be synced from the Django server.

if (att_handle != RESPONSE_VALUE_HANDLE) return 0;

if (buffer_size != 68) {
    printf("VERIFY FAIL, expected 68 bytes, got %u\n", buffer_size);
    return 0;
}

uint32_t device_id = (buffer[0] << 24) | (buffer[1] << 16)
                   | (buffer[2] << 8)  |  buffer[3];
const uint8_t *sig = buffer + 4;

// Serch for the public key from the flash. 
const uint8_t *pubkey = lookup_pubkey(device_id);
if (!pubkey) { 
    /* unknown device (not in django server, reject */ 
    return 0; 
}

// Generate the digest via the crypto chip
uint8_t digest[32];
atcac_sw_sha2_256(nonce, 32, digest);


// Verify using micro-ecc
int ok = uECC_verify(pubkey, digest, sig);
printf(ok ? "*** VERIFY PASS ***\n" : "*** VERIFY FAIL ***\n");

The Client Side (Card)

The client we make a state machine:

typedef enum {
    STATE_IDLE,
    STATE_SCANNING,
    STATE_CONNECTING,
    STATE_DISCOVER_SERVICE,
    STATE_DISCOVER_CHARS,
    STATE_READ_CHALLENGE,
    STATE_WRITE_RESPONSE,
    STATE_DONE,
} client_state_t;

On HCI state HCI_STATE_WORKING the client calls gap_start_scan() and watches for advertisements under name "Auth-Door". When it sees one, we execute gap_connect. once the state advances to STATE_DISCOVER_SERVICE and a gatt_client_discover_primary_services_by_uuid128 call goes out with the auth service UUID.

During the STATE_READ_CHALLENGE phase , the 32 byte nonce has arrived from the server, the client hashes it, packs its own device ID into the first four bytes of the response buffer, and calls atcab_sign:

uint8_t digest[32];
atcac_sw_sha2_256(challenge, 32, digest);

response_buf[0] = (CLIENT_DEVICE_ID >> 24) & 0xFF;
response_buf[1] = (CLIENT_DEVICE_ID >> 16) & 0xFF;
response_buf[2] = (CLIENT_DEVICE_ID >>  8) & 0xFF;
response_buf[3] =  CLIENT_DEVICE_ID        & 0xFF;

atcab_sign(0, digest, response_buf + 4);

gatt_client_write_value_of_characteristic(
    handler, conn_handle, response_handle, 68, response_buf);

The device_id is the lower four bytes of the ATECC508A serial number which we saved during provisioning and locking of the chip along with it's public key. This is the same four bytes the server will look up in its static keystore to find the public key.

The ID Card's LED lights up green when connecting to the door device and the door device's LED turns green when the signing of nonce by ATEC508A is successfully verified by micro-ecc

Result

With both bugs sorted, the UART log across two boards looks like this on a clean run.

community.element14.com/.../blegatt.mp4

Again, i am using a PCB which i designed for a client to work like an breakout board for the ATTEC508A. Hence the blur. After a successful verification, the door devices starts readvertising and i do have to reset the ID card to re-auth again.

Final Notes

Again, thanks to BTStacks awesome documentation, this was an easy three hour work after setting up ATECC508A. There was some hold up due to typo in the micro-ecc bundled by BTStack, which i thought was my problem but later I realized it was a bug. I did write the public key manually in the lookup table for this unit test, in the final unit test, I will interface W5500 to sync the public keys to the feather board.

Using the Particle Ethernet FeatherWing with the MAX32630FTHR (Don't Forget to Set)

Alistair — Mon, 27 Apr 2026 20:29:29 GMT

For my project I am using the Particle Ethernet FeatherWing to allow the MAX32630FTHR to communicate with the local network and enable my alarm.

The Particle Ethernet FeatherWing is based around the WIZnet W5500 and under normal circumstances will work with the standard Arduino Ethernet library version 2.0.0+. This is however not compatible with the older Maxim core. It took a while but I worked round the problem, and here is my solution just in case it is helpful to someone else.

Before we get into the software, we need to add some header pins to the MAX32630FTHR. My advice is to loosely place the pins in the FeatherWing and quickly solder on the corner pins. After that the header pins are held in place and the rest of the pins will be so much easier to solder.

My work around with the Arduino IDE 1.8 it to this is to use the older Ethernet2 library, that is a drop in replacement to the version 1 Ethernet library but supports the W5500. This addresses most of the issues, but we still need to copy across a few files to get this to work. Here are the setup instructions...

First install the Ethernet2 library from the Arduino library manager (Sketch->Include Library->Manage Libraries…).

Once installed we need to copy the following files from the Arduino AVR core "%homepath%\Documents\ArduinoData\packages\arduino\hardware\avr\1.8.6\cores\arduino" to the Ethernet2 library directory "%homepath%\Documents\Arduino\libraries\Ethernet2\src".

Client.h
Server.h
IPAddress.h
IPAddress.cpp
Udp.h

I will note that although it would make more sense to copy the missing files to the Mamim core ("%homepath%\Documents\ArduinoData\packages\Maxim\hardware\arm\1.1.5\cores\arduino") and not the Ethernet2 library, but doing this uncovers yet more issues that need to be addressed, so lets take the easy road on this occasion.

So after this modification, and including Ethernet2.h instead of Ethernet.h our standard Ethernet applications will compile but not run. We still need to tell the library what pin to use in our setup code. From the schematic we can see the chip select is on pin 22 if the featherwing connector (traditionally GPIO10) and that is mapped to pin 7 on CON12 (P5.4 /SDIO 2) according to the MAX32630FTHR schematic.

So, in English, just add “Ethernet.init(P5_4);” to setup() before calling “Ethernet.begin”.

And that is it. Here is a cut down version of the WebClient example to set with…

#include <SPI.h>
#include <Ethernet2.h>

byte mac[] = { 0xDE, 0xAD, 0xBE, 0xEF, 0xFE, 0xED };
char server[] = "www.google.com";

EthernetClient client;

void setup() {

Serial.begin(115200);
Serial.println("Starting...");

Ethernet.init(P5_4);
Ethernet.begin(mac);

delay(1000);
Serial.println("connecting...");

if (client.connect(server, 80)) {
Serial.println("connected");

client.println("GET /search?q=arduino HTTP/1.1");
client.println("Host: www.google.com");
client.println("Connection: close");
client.println();
}
else {
Serial.println("connection failed");
}
}

void loop()
{
if (client.available()) {
char c = client.read();
Serial.print(c);
}

if (!client.connected()) {
Serial.println();
Serial.println("disconnecting.");
client.stop();
while (true);
}
}