https://community.element14.com/challenges-projects/design-challenges/smart-security-and-surveillance/A community design challenge focused on smart security and surveillance projects, where members design, build, and document practical solutions to real-world monitoring and protection problems. Participants share their process, hardware choices, and resulen-USTelligent Community 12https://community.element14.com/challenges-projects/design-challenges/smart-security-and-surveillance/f/forum/56874/identity-protocol---part-7---colouring-on-the-icled-featherwing/235253Fri, 01 May 2026 05:25:00 GMT93d5dcb4-84c2-446f-b2cb-99731719e767:a003025e-0ef2-4782-912a-afcb218349ddsaramicok let us know how close AI got it Back in the early 1980s, FLIR displays were typically 8×8 or 16×16 pixel arrays with very limited colour palettes — think chunky square pixels with that classic thermal false-colour look (black → purple → red → orange → yellow → white). Here's what icon/text overlays on that kind of display would have looked like: That's roughly what the operator was looking at — a 10" CRT with an analogue false-colour palette circuit mapping IR intensity to a cold→hot ramp (black → purple → red → orange → yellow → white), with chunky 5×7 pixel font characters overlaid in green phosphor or amber for altitude, heading, and speed readouts. The really clever engineering challenge back then was doing all that text and icon compositing in hardware — frame buffers were expensive, so a lot of it was done with character generators and video mixing ICs rather than anything resembling a GPU. Getting icons to sit cleanly over a noisy IR image with no alpha blending, just pixel-level XOR or overlay switching, was a real craft.https://community.element14.com/challenges-projects/design-challenges/smart-security-and-surveillance/f/forum/56874/identity-protocol---part-7---colouring-on-the-icled-featherwing/235252Fri, 01 May 2026 04:23:00 GMT93d5dcb4-84c2-446f-b2cb-99731719e767:70f896b6-cf20-405d-9ce4-ce9ef5b23d5aarvindsaWow.. that's an pure memory thenhttps://community.element14.com/challenges-projects/design-challenges/smart-security-and-surveillance/f/forum/56894/sentinel-box---part-ii---back-to-c/235251Fri, 01 May 2026 01:12:00 GMT93d5dcb4-84c2-446f-b2cb-99731719e767:77982b6f-0ab7-44e1-86a2-80528acb029esaramichey - yeah I saw your post Forum #5: Proposed Design — Adaptive Sentinel: Security & Environmental Intelligence Hub and I presume you are trying to communicate between 2 MAX32630FTHR edge nodes to a master UNO Q via UART. I am no expert and have mostly used it to: communicate to a peripheral (like the fingerprint reader) (master/slave give a command and wait for response) OR to read output via a serial monitor on a computer (hence receive only) The rule of thumb of UART seems to be RX of one device to TX of other device between 2 devices table top distance WARNING: This interface operates at 1.8 V logic levels and must be used with a compatible USB-to-TTL converter to avoid hardware damage. and the MAX32630FTHR is 3V3 Once you have that sorted, you would need to decide on how you want to communicate, there seem to be 3 approaches: Request/Response - one device is mater and sends requests and then listens - simple and predictable Turn-taking with a token/flag byte - decide on a special token (e.g. 0xFF ) to decide who should be sending or listening Asychronous/event-driven - dependent on UART being full-duplex - but you need start/end framing markers and buffering so you can assemble complete messages from the stream Maybe you can get away with the UNO Q being master and asking the edge MAX32630FTHR to send back a response? The most flexible would be the asynchronous/event-driven approach, so assuming they are hooked up like RX on EDGE 1 wire A goes to TX on EDGE 1 wire A +--------------+ +--------------+ | MAX32630FTHR | | MAX32630FTHR | | EDGE 1 | | EDGE 2 | | | | | | RX P3_0 A|---\/---|B RX P3_0 | | TX P3_1 B|---/\___|A TX P3_1 | | GND |--------| GND | +--------------+ +--------------+ but asynchronous means you will need to define a message etc. I tried to get this working with LPSDK, Mbed and ESP32 - LPSDK working code below Here we are using STX 0X02 (Start of Text) and ETX 0X03 (End of Text) to signify the start and end of the message #define MSG_START 0x02 // ASCII STX #define MSG_END 0x03 // ASCII ETX #define BUF_SIZE 128 // ------------------------------------------------------------------------- // Send a framed message over UART2 // ------------------------------------------------------------------------- static void send_message(const char *msg) { uint8_t start = MSG_START; uint8_t end = MSG_END; UART_Write(MXC_UART2, &start, 1); UART_Write(MXC_UART2, (uint8_t *)msg, strlen(msg)); UART_Write(MXC_UART2, &end, 1); debug_print("[TX] --> "); debug_print(msg); debug_print("\r\n"); } in the main loop, I send a PING message every ~1 second #define TICK_MS 10 // loop cadence #define TICKS_PER_PING 100 // 10ms * 100 = ~1s int main(void) { while (1) { // TMR_Delay is blocking for TICK_MS but the hardware RX FIFO // (32 bytes) holds incoming bytes while we wait. TMR_Delay(MXC_TMR0, MSEC(TICK_MS)); if (++tick >= TICKS_PER_PING) { tick = 0; char msg[32]; snprintf(msg, sizeof(msg), "PING %lu", ping_count++); send_message(msg); } } } that's the easy bit - of course I can send any information like this, temperature, accelerometer values, etc Then you need to be able to read these messages #define MSG_START 0x02 // ASCII STX #define MSG_END 0x03 // ASCII ETX #define BUF_SIZE 128 // ------------------------------------------------------------------------- // Non-blocking drain of UART2 RX FIFO — call on every loop tick // ------------------------------------------------------------------------- static void read_incoming(void) { while (UART_NumReadAvail(MXC_UART2)) { uint8_t b; int n = 0; UART_Read(MXC_UART2, &b, 1, &n); if (n != 1) break; if (b == MSG_START) { rx_pos = 0; in_message = 1; } else if (b == MSG_END) { if (in_message && rx_pos > 0) handle_message(rx_buf, rx_pos); rx_pos = 0; in_message = 0; } else if (in_message) { if (rx_pos PING 1000 [RX] PING 2000 [RX] PING 3000 [RX] <-- PING 1934 so there you have it - I hope the issue is not that you hooked up 1V8 on the UNO Q to the 3V3 on the MAX32630FTHR UART is fine for 2 boards on a desk Other alternatives are CAN bus 128 (CAN) nodes or unlimited with CAN FD 500m @125kbps or 40m @1Mbps CRC + ACK + error frames 2 wires twisted pair + GND needs MCP2515 or similar chip needs 120Ω termination resistors to prevent reflection corrupting the signal I2C can have up to 127 devices short distances <1m Master/Slave topology fits may need pull-up resistors 4.7kΩ at 100kHz SDA/SCL share bus so needs collision management RS-485 can have 32 nodes cheap MAX485 or SP3485 chips still UART underneath 100m+ at 100kbps differential signaling means it is noise immune there is also: LIN Bus, Modbus, EtherCAT, 1-Wire, SPI All code can be found: github.com/.../src Including some Mbed code github.com/.../main-mbed-uart.cpphttps://community.element14.com/challenges-projects/design-challenges/smart-security-and-surveillance/f/forum/56874/identity-protocol---part-7---colouring-on-the-icled-featherwing/235249Thu, 30 Apr 2026 20:55:00 GMT93d5dcb4-84c2-446f-b2cb-99731719e767:5974aaf9-4061-4cf0-83f4-37d8862b23faDABNo, that was over 40 years ago.https://community.element14.com/challenges-projects/design-challenges/smart-security-and-surveillance/f/forum/56883/identity-protocol---part-9---ble-gatt-challenge-response-with-btstack/235247Thu, 30 Apr 2026 20:50:00 GMT93d5dcb4-84c2-446f-b2cb-99731719e767:592c9dc9-8608-49f5-9cb9-8e7700cdfa2bDABGood update. I hate finding other peoples mistakes, though it did earn me an A in one of my classes in college.https://community.element14.com/challenges-projects/design-challenges/smart-security-and-surveillance/f/forum/56893/guardian-sentinel-part-2-getting-started/235244Thu, 30 Apr 2026 20:43:00 GMT93d5dcb4-84c2-446f-b2cb-99731719e767:77b5a932-81f8-494d-9510-173efeacdb1dDABNice update.https://community.element14.com/challenges-projects/design-challenges/smart-security-and-surveillance/f/forum/56894/sentinel-box---part-ii---back-to-c/235243Thu, 30 Apr 2026 20:05:00 GMT93d5dcb4-84c2-446f-b2cb-99731719e767:47510893-e294-43fe-a904-b7b3e8487ed8skruglewiczHi saramic Hi saramic, I've been following your Sentinel Box project, and while the Rust experiment was fascinating, I really appreciate you sharing the transition back to C and the LPSDK. I’m currently trying to learn the ropes with the MAX32630FTHR , but I’ve hit a bit of a wall. I’m quite new to UART coding in general and I’m struggling to get a simple send/receive working between boards. If you have a moment, would you be willing to share how you laid out your pin connections and perhaps a snippet of the code you used for the UART setup within the LPSDK stack? I'd love to learn from your implementation as I try to get my own communication working. Thanks for the inspiration! Best, Stephenhttps://community.element14.com/challenges-projects/design-challenges/smart-security-and-surveillance/m/managed-videos/151274Thu, 30 Apr 2026 12:44:00 GMT93d5dcb4-84c2-446f-b2cb-99731719e767:d1f6900b-9830-4c97-ac7f-96586afb3ea2saramichttps://community.element14.com/challenges-projects/design-challenges/smart-security-and-surveillance/m/managed-videos/151273Thu, 30 Apr 2026 12:44:00 GMT93d5dcb4-84c2-446f-b2cb-99731719e767:6953d335-5bda-4fc4-9edf-0ea31e08f418saramichttps://community.element14.com/challenges-projects/design-challenges/smart-security-and-surveillance/f/forum/56894/sentinel-box---part-ii---back-to-cThu, 30 Apr 2026 12:42:00 GMT93d5dcb4-84c2-446f-b2cb-99731719e767:085fd39e-8ab5-43de-a7db-bbc8127d7724saramicI 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 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. Next 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-boxsecurity-challengerustbmi160MAX32630FTHR#https://community.element14.com/challenges-projects/design-challenges/smart-security-and-surveillance/f/forum/56892/forum-5-proposed-design-adaptive-sentinel-security-environmental-intelligence-hub/235240Thu, 30 Apr 2026 11:46:00 GMT93d5dcb4-84c2-446f-b2cb-99731719e767:f6640620-ae06-4986-8c13-d9763c3749c0robogaryThe diagram was very helpfulhttps://community.element14.com/challenges-projects/design-challenges/smart-security-and-surveillance/f/forum/56886/ble-scanning-and-cc256x-firmware-uploading/235239Thu, 30 Apr 2026 11:33:00 GMT93d5dcb4-84c2-446f-b2cb-99731719e767:42beb9c6-51dd-4836-8d39-111332d8c6e9AlistairThat is amazing thanks. Yes the LE was separate, and I was making the mistake of also applying the AVR patch when i should not have done, so lets just pretend that did not happen and move on. ;-) It looks like the mistake I was making is not applying both the event masks and enabling the low energy after. So I now have a lot of data to decode. :-) I guess this is one of those things that is described as a nice problem to have. That and a lot of tidying of the code. As my commands will be static I might just create a blob of commands to send at compile time, including the patch, and use my uploader code to apply then at start up. My main focus is making the code easy to understand and easy to build on, and at the moment it is a bit of a mess of experimentation and debugging code. Again let us pretend that is not the case and move on. ;-)https://community.element14.com/challenges-projects/design-challenges/smart-security-and-surveillance/f/forum/56886/ble-scanning-and-cc256x-firmware-uploading/235238Thu, 30 Apr 2026 09:56:00 GMT93d5dcb4-84c2-446f-b2cb-99731719e767:ee0002e0-6461-41df-8b1b-f55b405c1dc8BigGhere's the Arduino code, if it helps. #include #include "pwrseq_regs.h" #include "rtc_regs.h" #include "ioman_regs.h" #include "gpio_regs.h" #include "CC256XB.h" // Your TI Service Pack file // Define the correct Serial port based on your MXC_HardwareSerial.h discovery #define SerialBLE Serial0 #define BUFFER_ARRAY_SIZE (128u) // 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) // HCI_Reset Command: [PacketType][OpCode Low][OpCode High][Length] const uint8_t HCI_RESET_CMD[] = {0x01, 0x03, 0x0C, 0x00}; const uint8_t HCI_SERIALNUM_CMD[] = {0x01, 0x01, 0x10, 0x00}; const uint8_t VS_STATUS_CMD[] = {0x01, 0x19, 0xFE, 0x00}; // Set event mask and LE event mask const uint8_t SET_EVENT_MASK[] = {0x01, 0x01, 0x0C, 0x08, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF}; const uint8_t SET_LE_EVENT_MASK[] = {0x01, 0x01, 0x20, 0x08, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF}; // Write LE Host Supported (Bit 0: LE Supported, Bit 1: Simultaneous LE/BR) const uint8_t ENABLE_LE[] = {0x01, 0x6D, 0x0C, 0x02, 0x01, 0x01}; // Set Scan Parameters (Passive scanning, 0x64 interval/window) const uint8_t SET_SCAN_PARAMS[] = {0x01, 0x0B, 0x20, 0x07, 0x00, 0x64, 0x00, 0x64, 0x00, 0x00, 0x00}; // Set Scan Enable (Enable=1, Filter Duplicates=0) const uint8_t SCAN_ENABLE[] = {0x01, 0x0C, 0x20, 0x02, 0x01, 0x00}; uint8_t buffer[BUFFER_ARRAY_SIZE] = {'\0'}; uint16_t cntr = 0; bool eventMask = false; bool eventLEMask = false; bool enableBLE = false; bool servicePackDone = false; bool initialiseScan = false; bool ScanEnabled = false; void setup() { Serial.begin(115200); while (!Serial); // --- 1. SET VOLTAGES (Arduino Way) --- // Set 1.8V Logic for all Bluetooth UART pins useVDDIO(BLE_SHUTDOWN_PIN); useVDDIO(M4_TX_PIN); useVDDIO(M4_RX_PIN); useVDDIO(M4_RTS_OUT_TO_BLE); useVDDIO(BLE_RTS_IN_TO_M4); Serial.println("1. VDDIO set to 1.8V."); // --- 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; Serial.println("2. 32kHz Heartbeat active on P1.7."); // Prepare Pins: Set M4 RTS LOW BEFORE the module wakes up // This ensures the BLE module sees "Permission to Speak" immediately. pinMode(M4_RTS_OUT_TO_BLE, OUTPUT); digitalWrite(M4_RTS_OUT_TO_BLE, LOW); pinMode(BLE_RTS_IN_TO_M4, INPUT); // Monitor the module's RTS pinMode(M4_RX_PIN, INPUT); // Prepare RX for data Serial.println("3. Flow control pins staged (M4 RTS = LOW)."); // Initialize SerialBLE (Serial0) // Note: We use 115200 but re-assert IOMAN immediately after. SerialBLE.begin(115200); // Force IOMAN to Mapping B (Crossover) // Serial0.begin() often reverts to Mapping A. We force it back to B. // 0x11 = Request Mapping B for RX/TX pins. MXC_IOMAN->uart0_req = 0x11; while (MXC_IOMAN->uart0_ack != 0x11); Serial.println("4. UART0 Mapping B (Crossover) Locked."); // Pulse Reset (nSHUTD) pinMode(BLE_SHUTDOWN_PIN, OUTPUT); digitalWrite(BLE_SHUTDOWN_PIN, LOW); delay(100); digitalWrite(BLE_SHUTDOWN_PIN, HIGH); Serial.println("5. BLE Reset released. Waiting for module..."); } bool wait_for_hci_ack() { uint32_t timeout = millis(); while (millis() - timeout = 3) { if (SerialBLE.read() == 0x04 && SerialBLE.read() == 0x0E) return true; } } return false; } // --- 3. THE SIMPLE LOADER --- void upload_service_pack() { uint32_t cursor = 0; const uint32_t BasePatchLength = sizeof(BasePatch); const uint32_t LowEnergyPatchLength = sizeof(LowEnergyPatch); Serial.print("\r\nSize of base service pack: "); Serial.println(BasePatchLength); while (cursor >> Sending HCI_Reset Command..."); SerialBLE.write(HCI_RESET_CMD, 4); } } // Handle Manual 'r' Trigger from PC if (Serial.available()) { char c = Serial.read(); if (c == 'r') { Serial.println("\n>>> Manual Trigger: Sending HCI_Reset..."); // Clear buffer first while(SerialBLE.available()) SerialBLE.read(); SerialBLE.write(HCI_RESET_CMD, 4); } else if (c == 'v') { Serial.println("\n>>> Manual Trigger: Sending TI_VS_Get_System_Status..."); SerialBLE.write(VS_STATUS_CMD, 4); } } // Read and Print Module Response if (SerialBLE.available()) { // Wait briefly for the full packet to arrive delay(10); memset(buffer,'\0', BUFFER_ARRAY_SIZE); cntr = 0; Serial.print("<<< BLE Response (HEX): "); while (SerialBLE.available()) { byte b = SerialBLE.read(); if (b < 0x10) Serial.print("0"); Serial.print(b, HEX); Serial.print(" "); if (cntr < (BUFFER_ARRAY_SIZE - 1)) { buffer[cntr] = b; cntr++; } else { buffer[cntr] = b; break; } } Serial.println(); // Review the buffer array... if (buffer[0] == 0x04 && buffer[1] == 0x0E) { Serial.print("Size of buffer: "); Serial.println(cntr); if (buffer[2] == 0x04 && buffer[4] == 0x03 && buffer[5] == 0x0C && buffer[cntr] == 0x00) SerialBLE.write(HCI_SERIALNUM_CMD, 4); if (cntr == 15 && !servicePackDone) { upload_service_pack(); } } else if (buffer[0] == 0x04 && buffer[1] == 0x3E) { Serial.print("Size of buffer: "); Serial.println(cntr); } } if (servicePackDone) { if (eventMask) { if (eventLEMask) { // We can now set up our BLE application if (enableBLE) { if (initialiseScan) { if (ScanEnabled) { } else { Serial.println("Enabling BLE Scan..."); Serial0.write(SCAN_ENABLE, sizeof(SCAN_ENABLE)); wait_for_hci_ack(); ScanEnabled = true; Serial.println("Scanning for devices... (Watch for 04 3E events)"); } } else { Serial.println("Setting Scan Parameters..."); SerialBLE.write(SET_SCAN_PARAMS, sizeof(SET_SCAN_PARAMS)); wait_for_hci_ack(); initialiseScan = true; } } else { Serial.println("Enabling BLE..."); SerialBLE.write(ENABLE_LE, sizeof(ENABLE_LE)); wait_for_hci_ack(); enableBLE = true; } } else { Serial.println("Setting LE Event Mask..."); SerialBLE.write(SET_LE_EVENT_MASK, sizeof(SET_LE_EVENT_MASK)); wait_for_hci_ack(); eventLEMask = true; } } else { Serial.println("Setting Event Mask..."); SerialBLE.write(SET_EVENT_MASK, sizeof(SET_EVENT_MASK)); wait_for_hci_ack(); eventMask = true; } } }https://community.element14.com/challenges-projects/design-challenges/smart-security-and-surveillance/m/managed-videos/151270Thu, 30 Apr 2026 08:40:00 GMT93d5dcb4-84c2-446f-b2cb-99731719e767:154bb124-506c-4a05-915d-b6cd7d003a82meera_hussienhttps://community.element14.com/challenges-projects/design-challenges/smart-security-and-surveillance/f/forum/56893/guardian-sentinel-part-2-getting-startedThu, 30 Apr 2026 08:39:00 GMT93d5dcb4-84c2-446f-b2cb-99731719e767:e847499f-2d80-430b-9267-17c43e86a09dmeera_hussienGuardian Sentinel — Getting Started 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 #include #include #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.max32630fthroledarduino idemaximarduinoMAX32630FTHR#https://community.element14.com/challenges-projects/design-challenges/smart-security-and-surveillance/f/forum/56892/forum-5-proposed-design-adaptive-sentinel-security-environmental-intelligence-hub/235237Thu, 30 Apr 2026 04:58:00 GMT93d5dcb4-84c2-446f-b2cb-99731719e767:cb64b138-bae1-4714-a403-3351adec5276skruglewiczOh darn .. Thanks for letting me know. I'll fix it nowhttps://community.element14.com/challenges-projects/design-challenges/smart-security-and-surveillance/f/forum/56892/forum-5-proposed-design-adaptive-sentinel-security-environmental-intelligence-hub/235236Thu, 30 Apr 2026 04:44:00 GMT93d5dcb4-84c2-446f-b2cb-99731719e767:19641b70-c2dd-4018-8f41-667e319bc72darvindsaI am still reading though your post, but i caught that your link to your hackster profile is incorrect.https://community.element14.com/challenges-projects/design-challenges/smart-security-and-surveillance/f/forum/56892/forum-5-proposed-design-adaptive-sentinel-security-surveillance-intelligence-hubThu, 30 Apr 2026 04:37:00 GMT93d5dcb4-84c2-446f-b2cb-99731719e767:93dc9d1b-bf47-4334-869b-6f0271bf4c2dskruglewiczThis 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.design-challengeMAX32630FTHR#https://community.element14.com/challenges-projects/design-challenges/smart-security-and-surveillance/f/forum/56886/ble-scanning-and-cc256x-firmware-uploading/235225Wed, 29 Apr 2026 17:05:00 GMT93d5dcb4-84c2-446f-b2cb-99731719e767:84c2da58-805a-4eac-9736-fb928f3247beBigGIt's all rather weird logic. Thank goodness for AI! So, I've got it working. The key to actually seeing any output from the scan is to set up the "Event Mask". You do this before setting up scan. // Set event mask and LE event mask const uint8_t SET_EVENT_MASK[] = {0x 01 , 0x 01 , 0x 0C , 0x 08 , 0x FF , 0x FF , 0x FF , 0x FF , 0x FF , 0x FF , 0x FF , 0x FF }; const uint8_t SET_LE_EVENT_MASK[] = {0x 01 , 0x 01 , 0x 20 , 0x 08 , 0x FF , 0x FF , 0x FF , 0x FF , 0x FF , 0x FF , 0x FF , 0x FF }; <<< BLE Response (HEX): 04 01 0B 20 00 Enabling BLE Scan... Scanning for devices... (Watch for 04 3E events) <<< BLE Response (HEX): 04 01 0C 20 00 <<< BLE Response (HEX): 04 3E 2B 02 01 03 01 E1 CD 48 2E 2E 2F 1F 1E Size of buffer: 15 <<< BLE Response (HEX): 04 3E 2B 02 01 03 01 E1 CD 48 2E 2E 2F 1F 1E Size of buffer: 15 <<< BLE Response (HEX): 04 3E 28 02 01 02 01 96 23 5E B8 B8 78 1C 03 Size of buffer: 15 <<< BLE Response (HEX): 04 3E 28 02 01 02 01 48 1D 94 8E B3 73 1C 03 Size of buffer: 15 <<< BLE Response (HEX): 04 3E 28 02 01 02 01 96 23 5E B8 B8 78 1C 03 Size of buffer: 15 <<< BLE Response (HEX): 04 3E 2B 02 01 03 01 E1 CD 48 2E 2E 2F 1F 1Ehttps://community.element14.com/challenges-projects/design-challenges/smart-security-and-surveillance/f/forum/56886/ble-scanning-and-cc256x-firmware-uploading/235222Wed, 29 Apr 2026 15:56:00 GMT93d5dcb4-84c2-446f-b2cb-99731719e767:3ab86ba0-01f5-4469-b933-b189d8bac2ecBigGI thought to give it a try. I now have the service pack loaded... will now see if I can scan for devices >>> Sending HCI_Reset Command... <<< BLE Response (HEX): 04 0E 04 01 03 0C 00 Size of buffer: 7 <<< BLE Response (HEX): 04 0E 0C 01 01 10 00 06 00 00 06 0D 00 90 1B Size of buffer: 15 Size of service pack: 9118 Bluetooth successfully patched! UPDATE. I had only patched with the base patch. Just discovered that you also have to patch with the LowEnergyPatch[] and set the #ifdef __SUPPORT_LOW_ENERGY__