Injection Molding Shot-to-Shot Process Monitor

This project is a shot-level process monitor for plastic injection molding machines. On every shot, the device captures the two signals that drive part quality: hydraulic injection pressure and mold temperature. It boils each shot down to a handful of summary metrics a process engineer would want to see (peak pressure, fill time, pack pressure, average mold temperature, and shot sequence number), then pushes them to the cloud over cellular. The connectivity sits outside the plant's OT network, so the customer site never has to open an IT or network ticket. The hardware is a Blues Notecarrier CX paired with a Notecard Cell+WiFi.

Expected Outcome

When you finish this project, you'll have:

• A compact DIN-rail enclosure mounted in the machine's electrical cabinet
• Hydraulic injection pressure and mold temperature collected continuously at the edge
• Five shot-level metrics (peak_psi, fill_ms, pack_psi, temp_avg_c, cooling-rate slope) landing in the shot.qo Notefile in the Blues Notehub cloud service, with one event per shot (or per N shots, if you configure it that way)
• Real-time alerts routed to your CMMS, webhook, or quality system whenever a metric crosses a configurable threshold
• A 100% cellular install that doesn't modify the machine, touch the mold, or involve the plant network
• A commissioning run of ~50–100 shots to set baseline thresholds, after which the system runs on its own

1. Project Overview

The problem. Plastic injection molding looks stable right up until it isn't. A mold that ran flawlessly through ten thousand shots can start making scrap on shot ten-thousand-and-one because of a worn gate land, a slightly off-spec resin lot, a partially fouled cooling circuit, or a worn check ring on the screw. None of these failures announce themselves in any dramatic way. Instead they introduce subtle shot-to-shot variation in the two signals that matter most. One is hydraulic injection pressure at the cylinder's manifold block, the upstream hydraulic forcing function that drives how completely the cavity fills and how hard it gets packed. The other is mold temperature, which governs cooling rate, crystallinity, and cycle time. You can measure both of them continuously, but almost nobody does.

Why Notecard. Plastics processors run their production equipment on isolated OT (operational technology) networks. That isolation is deliberate, because machines running 24/7 production can't share a network path with corporate IT systems. An OEM that wants to sell a remote process-monitoring service has two options. It can negotiate a network path through every customer's IT and OT security teams, which is slow, expensive, and different every time. Or it can use connectivity that skips the plant network entirely. Notecard Cell+WiFi takes the second route. It carries data straight to Notehub over cellular, with WiFi as an opportunistic fallback for plants that allow it, so the OEM can ship the same hardware SKU to every customer no matter how the plant's networks are organized.

New to Blues?

Learn what we do in this 3-minute video that walks you through how we simplify wireless connectivity.

Learn what we do in this 3-minute video that walks you through how we simplify wireless connectivity.

Deployment scenario. A compact DIN-rail or panel-mount enclosure goes in or next to the machine's electrical cabinet and runs off the machine's existing 24 VDC control rail. The hydraulic injection pressure transducer taps into a 1/4-18 NPT port on the injection cylinder's hydraulic manifold block. That's on the hydraulic oil side of the machine, with no contact with the polymer melt, so no mold modification is required. The thermocouple probe sits in the mold's existing thermocouple pocket. You don't modify the machine's controller, connect to the plant LAN, or file an IT ticket.

2. System Architecture

Device-side responsibilities. The machine is line-powered, so the Notecarrier CX's onboard Cygnet STM32L433 host just stays running, with no deep-sleep cycle to manage. Between shots it polls injection-manifold pressure at 10 Hz and watches for the rising edge that means the screw has started pushing forward. As soon as that signal crosses shot_detect_psi, the host switches to 20 Hz capture mode (50 ms per sample) and fills a RAM buffer with the pressure and temperature profile for the length of the shot. When the shot ends, the host pulls five shot-level features out of the buffer, bumps the per-boot-session shot counter, and queues a Note for the Notecard to handle. It all fits in the STM32's 64 KB SRAM. A 102-second shot at 20 Hz is at most 16 KB of profile data, well inside the available budget.

Notecard responsibilities. Every Note the host hands off goes into the Notecard's on-device queue, and the Notecard handles everything on the radio side from there. It brings up the cellular (or WiFi) session on the hub.set outbound cadence (60 minutes by default) for routine shot.qo Notes, and it sends anything marked sync:true immediately, whatever the outbound schedule says. Environment variables travel the same channel in the other direction, so a process engineer can retune detection thresholds and alert bands from Notehub without ever reflashing the device.

Notehub responsibilities. The Notecard manages its own cellular session on supported carrier networks worldwide through its embedded global SIM, then delivers data to Notehub over the internet. Notehub ingests and stores every event and applies project-level routes. The data is split into two Notefiles: shot.qo for the per-shot process data and shot_alert.qo for out-of-spec events. Because of that split, each stream can go to a different downstream destination at a different urgency without any filter logic.

Routing (high level only). Notehub can route to HTTP, MQTT, AWS, Azure, GCP, Snowflake, and several other destinations. This project doesn't ship a specific downstream endpoint, so check the Notehub routing docs for setup options.

3. Technical Summary

Path to First Event (5–10 min bench demo)

1. Assemble the minimum bench kit (you don't need production hydraulics):

   • Notecarrier CX + Notecard Cell+WiFi
   • SparkFun MAX31855K thermocouple breakout + dummy K-type leads
   • 150 Ω resistor, 100 nF capacitor, 5 V USB power or MeanWell DC-DC
   • Jumper wires to connect A0 (pressure via resistor) and SPI pins (thermocouple)

2. Create a Notehub project and get the ProductUID:

   • Sign up at notehub.io
   • Create a new project and copy its ProductUID (format: com.company:project-name)

3. Flash the firmware:

   arduino-cli core install "STMicroelectronics:stm32"
   arduino-cli lib install "Blues Wireless Notecard"
   # Edit firmware/injection_molding_shot_monitor/injection_molding_shot_monitor.ino
   # Replace PRODUCT_UID "" with your actual ProductUID
   arduino-cli compile -b STMicroelectronics:stm32:Blues:pnum=CYGNET firmware/injection_molding_shot_monitor/
   arduino-cli upload -b STMicroelectronics:stm32:Blues:pnum=CYGNET -p /dev/ttyACM0 firmware/injection_molding_shot_monitor/

4. Monitor the serial output:

   • Open a serial terminal at 115200 baud to watch the shot detection and feature extraction logs
   • Trigger a shot with a fake pressure pulse (for example, jumper A0 to +3V3_OUT for ~2 seconds, which reads as full-scale pressure)
   • Check that the next Notehub sync (within 60 min) shows a shot.qo event

5. Inspect the event in Notehub:

   • Log in to Notehub, open your project, and go to Events
   • Look for shot.qo events containing cycle, peak_psi, fill_ms, and temp_avg_c
   • During commissioning, treat the serial log and the Notehub events as your source of truth

Here's a sample Note from this device:

{
  "file": "shot.qo",
  "body": {
    "cycle":       247,
    "peak_psi":    1340.5,
    "fill_ms":     750,
    "pack_psi":    890.2,
    "cool_c_s":    -1.84,
    "temp_avg_c":  47.3,
    "shot_ms":     28400
  }
}

4. Hardware Requirements

All Blues parts ship with an active SIM that includes 500 MB of data and 10 years of service, with no activation fees and no monthly commitment.

5. Wiring and Assembly

Inside the DIN-rail enclosure, everything comes back to the Notecarrier CX and its dual 16-pin header. The Notecard Cell+WiFi (MBGLW) seats in the carrier's M.2 slot. The rest of the cabinet wiring (the 4–20 mA pressure loop, the SPI thermocouple breakout, and the 5 V step-down from the machine's 24 VDC rail) all lands on that header. During bench validation, the Mojo sits inline between the 5 V supply output and the Notecarrier's +VUSB pad. It also plugs into the Notecarrier CX's Qwiic connector so the Notecard can read the Mojo's LTC2959 coulomb counter over the shared I²C bus. The Mojo is only for bench validation and doesn't go to the field.

4–20 mA pressure transducer loop (A0):

• 24 VDC supply (+) → transducer (+) supply terminal.
• Transducer (-) return terminal → one end of the 150 Ω sense resistor → GND.
• ADC input A0 → the junction between transducer (-) and the top of the 150 Ω resistor (the node that swings 0.60 V–3.00 V with load current). Put the 100 nF capacitor from this node to GND, physically close to the A0 pin.
• The 24 VDC loop ground and the Notecarrier CX GND need a common reference, so run a ground wire between the machine's 24 VDC return and the Notecarrier's GND pin.

MAX31855K thermocouple breakout (SPI):

• MAX31855K breakout VCC → +3V3_OUT on the Notecarrier CX header (3.3 V, 100 mA available).

• MAX31855K breakout GND → GND.

• MAX31855K breakout SCK → SCK on the Notecarrier CX header.

• MAX31855K breakout DO (MISO) → MISO on the Notecarrier CX header.

  Notecarrier CX label errata. On v1.3 hardware, the MOSI and MISO silkscreen labels are swapped. If SPI reads come back as garbage, swap the MOSI/MISO connections and try again. The Notecarrier CX datasheet has the authoritative pin table.

• MAX31855K breakout CS → D10 on the Notecarrier CX header (any digital I/O works, but D10 is the firmware default).

• MAX31855K breakout TC+ and TC- → the matching positive and negative wires of the K-type thermocouple probe. Polarity note: The ANSI/US K-type convention uses yellow for the positive lead, while IEC 60584-3 uses green for K-type positive. Go by your probe's lead color or connector marking, not a generic color table.

Antenna (mandatory for metal-cabinet installations):

The Notecarrier CX comes with a short flexible LTE antenna connected to the Notecard's cellular u.FL port. Inside a steel electrical cabinet, the enclosure walls attenuate that antenna heavily. For reliable cellular connectivity, the antenna element has to sit outside the cabinet.

• Thread the u.FL-to-SMA female bulkhead pigtail through a cable gland or conduit knockout in the cabinet wall. Use an IP-rated cable gland so the enclosure keeps its protection rating.
• Snap the u.FL connector onto the Notecard's cellular u.FL antenna port. Keep the coax run short and avoid sharp bends, because the RG178 cable is fragile and will fail at a sharp kink.
• Attach the external SMA wideband antenna to the SMA female bulkhead on the outside of the cabinet. A magnetic-mount whip on the cabinet roof works well in the field. Keep the antenna clear of large metal objects and away from the high-voltage conductors in the upper section of the panel.
• Don't use the included flexible antenna inside the cabinet. Keep it as a bench-test spare.

Power:

• 24 VDC rail → 24 V input of the DC-DC step-down converter.
• DC-DC converter 5 V output (+) → Notecarrier CX +VUSB (or +VBAT).
• DC-DC converter 5 V output (−) → Notecarrier CX GND.
• During bench validation, put the Mojo inline between the DC-DC 5 V output and +VUSB so it measures the whole Notecarrier + Notecard subsystem. Connect the Mojo's Qwiic cable to the Notecarrier CX's Qwiic connector. The carrier exposes the shared I²C bus there, and the Notecard reads the Mojo's LTC2959 over that bus. Remove the Mojo before field deployment, since it's only a bench-validation tool.

6. Notehub Setup

1. Create a project. Sign up at notehub.io and create a project. Copy the ProductUID and paste it into firmware/injection_molding_shot_monitor/injection_molding_shot_monitor.ino as PRODUCT_UID.

2. Claim the Notecard. Power the unit. The Notecard associates itself with your project automatically on its first cellular connection.

3. Create a Fleet per production line. Fleets group devices for shared configuration. One fleet per production line or cell is a natural fit, since the monitors on one line usually run the same mold and resin and so share the same threshold set. If you have a lot of monitors, Smart Fleet rules can assign them by line or mold ID automatically.

4. Set environment variables. Every variable below is optional, and the table shows the firmware defaults. A value you set in Notehub overrides the compile-time default on the device's next inbound sync, so operators can adjust alert bands in the field to match a specific mold and resin without reflashing.

   Variable	Default	Purpose
   max_pressure_psi	2000.0	Full-scale range of the installed pressure transducer (PSI). Must match the sensor range you bought.
   shot_detect_psi	100.0	Rising-edge threshold (PSI). Above it, the firmware treats a shot as started. Raise it if idle vibration causes false triggers.
   shot_end_psi	50.0	Falling-edge threshold (PSI). Below it, the firmware treats the shot as complete.
   peak_psi_min	800.0	Alert fires when peak injection pressure falls below this value, which can point to a short shot, gate freeze, or material flow issue.
   peak_psi_max	1900.0	Alert fires when peak injection pressure exceeds this value, a sign of overpacking or flash risk.
   fill_time_min_ms	200	Alert fires when fill time is shorter than this (milliseconds). Unexpectedly short fill times suggest a gate or nozzle issue.
   fill_time_max_ms	3000	Alert fires when fill time exceeds this (milliseconds). Slow fill points to degraded material flow or low injection speed.
   mold_temp_max_c	80.0	Alert fires when average mold temperature exceeds this value (°C). Rising mold temperature can mean the cooling circuit is degrading.
   outbound_min	60	Cellular outbound sync cadence in minutes. When this value changes in Notehub, the firmware spots the difference on its next 5-minute env-var check and re-issues hub.set with the new cadence right away, with no reflash needed. Allow up to the inbound poll interval (default 120 min) for the Notecard to pull the new value from Notehub, then up to 5 more minutes for the firmware to apply it.
   report_every_n_shots	1	Send a shot.qo Note every N shots. Set it to 10 to cut data volume on high-speed machines and still see the trends.

5. Configure routes. Add one route for shot_alert.qo (real-time delivery to a quality alert or CMMS endpoint) and a second for shot.qo (batch delivery to a process historian or analytics platform). The two Notefiles are separate at the source, so each route works on its own. High-urgency alerts can go to an on-call webhook while trend data lands in a time-series database, and neither route needs any filter logic.

7. Firmware Design

The firmware is a single Arduino sketch, firmware/injection_molding_shot_monitor/injection_molding_shot_monitor.ino, built from a small set of focused functions that handle Notecard configuration, sensor I/O, shot capture, feature extraction, and Note emission.

Dependencies:

• Arduino core for STM32 (stm32duino/Arduino_Core_STM32), installed from the Arduino IDE Boards Manager.
• Blues Wireless Notecard (the note-arduino library). Install it from the Arduino Library Manager or with arduino-cli lib install "Blues Wireless Notecard".

Modules

Sensor reading strategy

Pressure. The transducer's 4–20 mA current-loop signal passes through a 150 Ω sense resistor, which produces a 0.60–3.00 V signal on the Cygnet's 12-bit ADC pin A0. Each call to readPressurePsi() averages eight ADC readings, which suppresses switching noise without adding any real latency. The resulting count range maps linearly from [ADC_COUNTS_AT_4MA … ADC_COUNTS_AT_20MA] to [0 … max_pressure_psi].

Temperature. The MAX31855K outputs a 32-bit SPI word with the thermocouple junction temperature in the upper 14 bits (0.25 °C per LSB) and three fault flags in the lower three bits. readMoldTempC() reads that word directly over SPI with no extra library dependency, checks the fault bits, and returns NAN on any thermocouple wiring fault (open-circuit, short-to-GND, short-to-VCC). computeFeatures() guards every temperature accumulation with isnan(), so a disconnected or shorted probe can't corrupt the math. If the thermocouple gives no valid samples across a shot, the mold-temperature trend slope (cool_c_s) and average-temperature (temp_avg_c) fields fall back to 0.0. That's a known simplification, and 0.0 is an ambiguous sentinel. In the payload, a mold that really is near ambient temperature looks exactly like a faulty probe. A future improvement would use a sentinel outside the physical temperature range (for example, -999.0) so downstream analytics can tell the two cases apart.

Probe response-time limitation. A 1/8″ stainless sheath seated in a mold pocket has a thermal response time of several seconds, which is longer than a typical injection-molding cooling phase. So cool_c_s (the least-squares slope of temperature during the cooling window of a single shot) mostly reflects slow mold-surface temperature drift across several shots, not the fast within-shot cooling transient. It's still useful for catching gradual cooling-circuit degradation over time, but don't read it as a precise shot-level cooling rate. temp_avg_c (the mean temperature across the whole captured buffer) is also a lagged, averaged reading of the mold surface. That suits it well to steady-state mold temperature trending and to the mold_temp_high alert threshold.

Shot capture. Between shots, the firmware polls readPressurePsi() at 10 Hz. When the reading crosses shot_detect_psi, it enters captureShot(), which samples pressure and temperature at 20 Hz (a 50-millisecond cadence) into two pre-allocated float arrays. A 102.4-second maximum shot window at 20 Hz works out to 2,048 samples × 2 channels × 4 bytes = 16 KB, well within the Cygnet's 64 KB SRAM. SHOT_TIMEOUT_MS is defined as SHOT_BUF_SIZE × SHOT_SAMPLE_MS (102,400 milliseconds), so the safety timeout fires at exactly the moment the buffer would otherwise fill. That keeps a buffer-exhaustion exit from being mistaken for a shot that ended naturally. If the loop exits on its while-condition instead of a break (meaning the buffer is completely full), captureShot() returns false and logs a diagnostic. The firmware throws the partial profile away instead of quietly computing features on truncated data.

Event payload design

Both Notefiles are template-backed. Templates tell the Notecard to store and send fixed-length binary records instead of free-form JSON, which shrinks per-Note wire size by 3–5×. A machine cycling every 30 seconds across a three-shift day produces roughly 2,880 shot Notes per day, so smaller Notes help keep the daily cellular data budget manageable at high cycle rates.

shot.qo records pack_psi and cool_c_s for downstream trend analysis, but they don't drive any alert rules in this design. Only peak_psi, fill_ms, and temp_avg_c get checked against configurable alert thresholds.

shot.qo records queue in the Notecard's on-device flash and go out on the outbound schedule. shot_alert.qo is template-backed too (port 51), and it's sent with sync:true, which tells the Notecard to skip the outbound queue and open a cellular session for that Note right away.

Sample shot.qo Note body:

{
  "file": "shot.qo",
  "body": {
    "cycle":       247,
    "peak_psi":    1340.5,
    "fill_ms":     750,
    "pack_psi":    890.2,
    "cool_c_s":    -1.84,
    "temp_avg_c":  47.3,
    "shot_ms":     28400
  }
}

Sample shot_alert.qo Note body (immediate sync):

{
  "file": "shot_alert.qo",
  "body": {
    "alert":       "peak_pressure_low",
    "cycle":       248,
    "peak_psi":    692.1,
    "fill_ms":     1250,
    "temp_avg_c":  47.1
  },
  "sync": true
}

Power and sync strategy

The injection molding machine is line-powered 24/7, so the host runs a continuous loop() instead of cycling through deep sleep. There's no NotePayloadSaveAndSleep call, because the host has to stay responsive between shots to catch the rising pressure edge. The power concern here is bandwidth efficiency, not sleep depth.

The Notecard runs in hub.set periodic mode with outbound: 60 and inbound: 120 (minutes). Shot Notes pile up in the on-device queue and go out once an hour. Alert Notes skip the queue and sync as soon as a session can be established (~15–60 seconds). The Notecard low-power design guide and the MBGLW datasheet have the authoritative figures.

Retry and error handling

Notecard initialization. configureNotecard() sends hub.set with requestAndResponse() so it can inspect the response's err field. A semantic failure, like an unrecognized PRODUCT_UID format, gets logged and passed back to setup(), which halts with a FATAL message instead of quietly carrying on in an unprovisioned state. If PRODUCT_UID is empty (the default), setup() halts right away, before it tries to talk to the Notecard at all.

env.get. fetchEnvVars() calls requestAndResponse() and guards against both a nullptr response (Notecard unreachable) and a response with an err field (notecard.responseError(rsp) returns true). Either way, the function returns early and the in-RAM thresholds keep their last-good values. The device keeps running on stale (but valid) thresholds instead of stopping.

Note.template. defineTemplates() runs once at boot. It registers both shot.qo and shot_alert.qo with requestAndResponse() and prints the err string if either call is rejected. Templates are idempotent, so running them again on the next boot fixes any missed registration, at the cost of one cycle of free-form JSON Notes. The alert field in shot_alert.qo uses "peak_pressure_high" as its example string. Any non-numeric example string declares a variable-length string field, so every alert name fits without truncation.

Note.add. sendShotNote() checks the sendRequest() return. A failed note.add drops that shot Note, and there's no per-Note retry queue. At high cycle rates a lost shot Note is acceptable, since the process trend still shows up across the Notes that make it through. sendAlertNote() returns bool (the sendRequest() result), and loop() only advances the per-alert cooldown timer when sendAlertNote() returns true. A brief I2C or Notecard failure therefore doesn't block retries for the full 10-minute cooldown window. The next shot that trips the same condition tries the alert Note again immediately.

card.motion.mode. The accelerometer-disable call in configureNotecard() is best-effort, and a failure just gets logged to Serial. A live accelerometer doesn't affect whether the application works correctly. It adds a little idle current to the Notecard's baseline, which you can see on the Mojo trace.

Sensor faults. readMoldTempC() returns NAN on any MAX31855 fault bit, and computeFeatures() guards every temperature accumulation with isnan(), so faulted samples are silently left out. A shot with zero valid temperature samples produces 0.0 in the temp_avg_c and cool_c_s fields. The sensor reading section above explains what that sentinel choice means.

Shot capture guard. captureShot() throws out events shorter than MIN_SHOT_DURATION_MS (500 milliseconds), so machine vibration or idle pressure noise can't bump g_cycle_count and pollute the trend data.

Key code snippet 1: template definition

The template registers each field's data type with Notecard type-hint syntax:

• 14 = 4-byte signed integer (e.g. cycle, fill_ms, shot_ms)
• 14.1 = 4-byte IEEE 754 float (e.g. peak_psi, pack_psi, cool_c_s, temp_avg_c). The .1 just marks the field as a float; it doesn't limit precision to one decimal place.

With fixed-size binary records, the Notecard can store and send several hundred queued shots without running out of flash, and the wire size drops sharply. The code uses requestAndResponse() so the err field is visible if the Notecard rejects a malformed type hint. sendRequest() would silently swallow that failure.

J *req = notecard.newRequest("note.template");
JAddStringToObject(req, "file", "shot.qo");
JAddNumberToObject(req, "port", 50);
J *body = JAddObjectToObject(req, "body");
JAddNumberToObject(body, "cycle",      14);
JAddNumberToObject(body, "peak_psi",   14.1);
JAddNumberToObject(body, "fill_ms",    14);
JAddNumberToObject(body, "pack_psi",   14.1);
JAddNumberToObject(body, "cool_c_s",   14.1);
JAddNumberToObject(body, "temp_avg_c", 14.1);
JAddNumberToObject(body, "shot_ms",    14);
J *rsp = notecard.requestAndResponse(req);
if (!rsp || notecard.responseError(rsp)) {
    Serial.print("[APP] note.template (shot.qo) failed");
    if (rsp) { Serial.print(": "); Serial.print(JGetString(rsp, "err")); }
    Serial.println(" — will retry on next boot.");
}
if (rsp) notecard.deleteResponse(rsp);

Key code snippet 2: immediate-sync alert

sync:true skips the hourly outbound schedule, so the Notecard wakes the radio immediately and delivers the alert as soon as a session is up.

// Emits an out-of-spec alert with sync:true, which bypasses the outbound queue
// and triggers an immediate cellular session (~15–60 s to reach Notehub).
bool sendAlertNote(const char *alert_type, uint32_t cycle,
                   float peak_psi, int fill_ms, float temp_avg_c) {
    J *req = notecard.newRequest("note.add");
    JAddStringToObject(req, "file", "shot_alert.qo");
    JAddBoolToObject(req, "sync", true);
    J *body = JAddObjectToObject(req, "body");
    JAddStringToObject(body, "alert",      alert_type);
    JAddNumberToObject(body, "cycle",      (double)cycle);
    JAddNumberToObject(body, "peak_psi",   peak_psi);
    JAddNumberToObject(body, "fill_ms",    fill_ms);
    JAddNumberToObject(body, "temp_avg_c", temp_avg_c);
    bool ok = notecard.sendRequest(req);
    // ...
    return ok;
}

Key code snippet 3: feature extraction — mold-temperature trend slope (cool_c_s)

The 1/8″ sheath thermocouple has a thermal response time of several seconds, longer than a typical injection cooling phase, so cool_c_s can't capture the within-shot cooling transient. It does capture the direction and rate of mold-surface temperature drift across the tail end of each cycle window. The firmware fits a least-squares slope, (N·Σxy − Σx·Σy) / (N·Σxx − (Σx)²), over the post-gate-seal samples in the capture buffer, with x as seconds since gate seal and y as mold temperature. It needs at least two valid samples, and the result is a °C/s value (negative = mold surface cooling, positive = rising). Tracked as a trend across many shots, a slope drifting toward zero (the mold cooling more slowly than baseline) is an early sign of a fouled or partially blocked cooling circuit. It surfaces the degradation before it shows up in part dimensions or cycle time.

// 4. Cooling rate: least-squares slope of temperature from gate-seal to
//    end of shot (°C/s; a negative value means the mold is cooling normally).
int cool_start = pack_end_idx + 1;
int cool_n = 0;
double sx = 0, sy = 0, sxx = 0, sxy = 0;
for (int i = cool_start; i < g_shot_n; i++) {
    if (isnan(g_temp_buf[i])) continue;
    double x = (double)(i - cool_start) * SHOT_SAMPLE_MS / 1000.0;
    double y = (double)g_temp_buf[i];
    sx += x; sy += y; sxx += x * x; sxy += x * y; cool_n++;
}
if (cool_n >= 2) {
    double denom = (double)cool_n * sxx - sx * sx;
    *cool_c_per_s = (fabsf((float)denom) > 1e-9f)
                    ? (float)(((double)cool_n * sxy - sx * sy) / denom)
                    : 0.0f;
}

8. Data Flow

Collected. During each shot, the firmware records a continuous time series of injection-manifold pressure (PSI) and mold temperature (°C) sampled at 20 Hz. After each shot, it computes five aggregated features (peak pressure, fill time, pack pressure, mold temperature average, and mold-temperature trend slope), plus the total shot duration and a per-boot-session shot sequence number (cycle). Pack pressure and the mold-temperature trend slope (cool_c_s) are recorded for downstream trend analysis and don't trigger alerts. Keep in mind that cool_c_s reflects multi-shot mold-surface temperature drift, not the within-shot cooling transient, so read it over a run of shots instead of one at a time. §7 covers the probe response-time limitation.

Transmitted.

• shot.qo: one Note per shot (or per N shots if report_every_n_shots is set), queued in the Notecard and synced on the hourly outbound schedule. It's template-encoded to keep it small on the wire.
• shot_alert.qo: sent only when a feature falls outside its configured alert band, and synced right away with sync:true. Each of the five alert types has its own independent 10-minute cooldown timer. A shot that trips several conditions at once (say, low peak pressure and high mold temperature) produces a separate Note for each one. For any single alert type, though, you get at most one Note per 10-minute window, no matter how many out-of-spec shots happen in a row.

Routed. Both Notefiles go to Notehub, where separate routes can forward shot_alert.qo in real time (webhook, email, Slack, CMMS) while shot.qo lands in a time-series database or process historian for trend analysis.

Alert triggers. The firmware checks five conditions independently on every shot:

9. Validation and Testing

Expected steady-state cadence. On a healthy process with default thresholds, the device sends one shot.qo Note per injection cycle (for example, 120 Notes per hour on a 30-second cycle time) and no shot_alert.qo Notes. Plan on a commissioning period of 50–100 shots to confirm that the default thresholds suit the specific mold and resin. The intended workflow is to adjust peak_psi_min, peak_psi_max, and fill_time_max_ms through Notehub environment variables, without touching firmware.

Simulating alerts during commissioning. Set peak_psi_min to a value above what the process actually produces (for example, 1500.0 on a process that normally peaks at 1340.0). The next inbound sync pulls the new value, the firmware picks it up within 5 minutes, the next shot trips peak_pressure_low, and the alert Note should show up in Notehub within a typical cellular session window. Put the variable back to its correct value when you're done.

Shot profile spot-check. During commissioning, set report_every_n_shots to 1 and outbound_min to 10 in Notehub. After the next Notecard inbound sync (up to 120 minutes at the default cadence) and the next firmware env-var check (up to 5 minutes), the device re-applies hub.set and starts syncing every 10 minutes, with a fresh batch of shot Notes in each sync. Watch the fill_ms and peak_psi fields across consecutive shots. On a stable process they should stay nearly constant. Gradual drift in peak_psi, or a step change in fill_ms after a material lot change or mold maintenance, is exactly what this system is designed to surface.

Data-budget validation (required before production). With report_every_n_shots=1 (the default) and a 30-second cycle time, this design can generate up to 2,880 shot.qo Notes per day, plus more shot_alert.qo Notes whenever thresholds trip. Templates make each Note 3–5× smaller than free-form JSON, but at that rate the raw Note volume still adds up. Before you deploy to a production machine:

1. Estimate your daily Note volume. Use notes_per_day = (86400 s ÷ cycle_time_s) ÷ report_every_n_shots. A 20-second cycle with report_every_n_shots=1 produces ~4,320 Notes/day. Setting report_every_n_shots=10 drops that to ~432 and still captures the trend signals, without a 10× data-volume penalty.

2. Run a 24–72 hour validation soak. After commissioning, check Notehub usage data to confirm that actual consumption lines up with your estimate. Cellular data usage depends on sync cadence, signal conditions, Note queue depth at sync time, and routing behavior, so the measured figure is more reliable than any pre-deployment estimate.

3. Tune report_every_n_shots and outbound_min for the machine. A fast machine (≤15 seconds cycle) running at report_every_n_shots=1 will pile up a lot of queued Notes between hourly syncs. Test the queue headroom for real before production. Disconnect the cellular antenna, let the machine run for the expected outage window (for example, 4–8 hours for a typical overnight signal gap), reconnect, and confirm that every Note arrives in Notehub. Gaps in the cycle sequence numbers of the delivered Notes reveal dropped queue entries. If your Note rate times the expected outage window could saturate the queue, increase report_every_n_shots or shorten outbound_min so the queue flushes more often. Actual queue capacity depends on template size, Notecard firmware version, and session behavior, and here too a measured result beats any estimate you make ahead of time.

4. Watch shot_alert.qo volume separately. Every sync:true alert Note triggers its own cellular session. The 10-minute per-alert cooldown caps the worst case at 6 sessions per alert type per hour, but on a badly off-spec process where several alert types fire at once, those sessions add up. During commissioning, check the Notehub event log for alert Note volume and make sure the alert thresholds fit the specific mold and resin.

Using Mojo to validate power behavior. During bench testing, put the Mojo inline between the 5 V step-down converter and the Notecarrier CX +VUSB rail. Connect the Mojo's Qwiic cable to the Notecarrier CX's Qwiic connector so the Notecard can read the LTC2959 coulomb counter over the shared I²C bus. The Mojo measures the whole subsystem at the 5 V input rail. That's the Notecard plus the Notecarrier regulators plus the Cygnet host, not the Notecard in isolation.

Here are the published Notecard figures from the MBGLW datasheet. The MBGLW pairs an LTE Cat-1 bis modem (Quectel EG916Q-GL) with a 2.4 GHz 802.11b/g/n WiFi module, and these figures are for the cellular path this design uses:

And here's the whole system (Notecard + Notecarrier regulators + Cygnet host) at the 5 V Mojo measurement point:

The Mojo reports cumulative mAh to the Notecard over the Qwiic bus at 1% accuracy. Here's a useful bench exercise. Run the device for one hour with no alerts triggering, then check that the Mojo tally fits the expected pattern of one radio burst per hour, lasting tens of seconds at the published ~250 mA, with continuous host-active current in between. If the radio seems to sync far more often than the configured outbound cadence, see whether an alert condition is firing sync:true Notes in rapid succession, because each alert Note triggers its own cellular session right away.

10. Troubleshooting

11. Limitations and Next Steps

This reference design is built around a retrofit a process engineer can install in an afternoon, without modifying the mold or the controller and without a conversation about the plant network. A few details were left simple on purpose to keep that path clean. Each one is documented below, along with the production hardening that closes the gap.

Simplified for this reference design

Everything in this section was kept simple on purpose. Once the basic single-sensor retrofit proves itself, these are the spots where a production deployment adds a persistent counter, a faster sampler, per-cavity tracking, or richer process logic.

Hydraulic injection pressure, not in-cavity pressure. This design measures hydraulic injection pressure at the injection cylinder's manifold block with a standard 4–20 mA strain-gauge transducer. It doesn't measure in-cavity pressure. That takes a mold-mounted piezoelectric transducer installed through a dedicated sensor port in the mold, either an existing port or one machined for that purpose. Hydraulic pressure is the upstream forcing function the injection unit applies, and cavity pressure is the actual polymer pressure inside the mold cavity. The two differ by nozzle, gate, and runner losses that vary with resin, temperature, and wear. Where the hydraulic-to-cavity relationship is reasonably stable, hydraulic pressure is a practical, easy-to-reach signal for shot-to-shot consistency monitoring and trend detection. Applications that need direct cavity pressure (closed-loop pack control, high-precision medical or optical parts) require a mold-mounted piezoelectric transducer with a suitable charge amplifier and signal conditioning. See the scope note near the top of this page.

Cycle counter resets on power loss. g_cycle_count is a RAM-only variable. The cycle field in every Note is a per-boot-session shot sequence number, and it resets to zero on every power loss or reboot. It isn't a persistent lifetime part counter. For cumulative production counts in a downstream system, use Notehub event timestamps as the canonical ordering key. A production enhancement would persist g_cycle_count to the STM32's internal flash (with HAL_FLASH_Program) or to a small external EEPROM, batching the writes (every 100 shots, for example) to stay well within flash endurance limits.

Pressure range is POC-level. The default 0–2,000 PSI range suits benchtop and lab hydraulic circuits, but it may not be enough for production injection machines, where hydraulic injection pressures often run higher. A higher-pressure circuit needs a transducer rated for its actual maximum hydraulic pressure. Update max_pressure_psi to match, and confirm the manifold fitting and transducer pressure ratings before installation.

20 Hz shot capture is POC-level. The firmware samples at 20 Hz (50 milliseconds per sample). That's enough to extract the five summary features used here, but too coarse to capture the fine structure of the fill waveform. Fast injection molding machines, especially ones with fill times under 200 milliseconds or rapid gate-seal transients, may need 100–1000 Hz sampling to characterize fill dynamics faithfully and catch peak-pressure spikes. Getting to those rates on the Cygnet would take SPI DMA, double-buffering, and a deeper profile buffer.

Profile waveform is not transmitted. The firmware captures the pressure and temperature profile in RAM and pulls features out of it, but only the five features go to Notehub, and the raw profile arrays are discarded after each shot. A production system that needs SPC waveform analysis or golden-sample comparison would have to send the profile itself. At 2,048 samples × 8 bytes × 2,880 shots per day, though, sending raw profiles is a very different data volume problem.

Single sensor per shot. The design uses one pressure transducer and one thermocouple. Multi-cavity molds (two-cavity, four-cavity, family molds) would need one transducer per cavity, plus a firmware extension that tracks per-cavity features independently.

Gate-seal detection is heuristic. The firmware treats the pack phase as over when pressure drops to 50% of peak. Real-world molds may need a different ratio depending on gate geometry and resin rheology, and the GATE_SEAL_FRAC constant in the firmware is where you tune it.

Shot trigger is pressure-only. Some machine controllers put out a digital shot-in-progress signal on their I/O board. Wiring that signal to a digital input pin and using it as the primary trigger, instead of the pressure threshold, would give more precise shot-boundary timing. The firmware's pressure-threshold approach is the practical option for installations where you can't get at the machine's I/O.

No shot-to-shot baseline tracking. The alert thresholds are static (set by env var). A production quality system would keep a rolling baseline for each feature and alert on deviation from the process baseline instead of fixed limits, adapting on its own after intentional process changes.

Mojo is bench-validation only. The firmware doesn't read the Mojo's coulomb counter over Qwiic at runtime. If fleet-level energy telemetry turns out to be valuable, adding a mAh field to the periodic shot.qo Note is a straightforward extension.

Production Next Steps

Once a process engineer has the basic shot monitor running, these extensions turn it into a production quality tool. They're ordered roughly from most immediately useful to most dependent on analytics.

A persistent cycle counter batch-writes g_cycle_count to STM32 internal flash or an external EEPROM every 100 shots, so the lifetime shot tally survives power cycling. The persisted count would go out as a separate total_cycle field in the shot.qo Note body.

Per-cavity monitoring adds a cavity_id field to the data model and wires one transducer per cavity. The Notecarrier CX has A0–A5 available for expansion.

Waveform capture for golden-sample comparison adds a TRANSMIT_WAVEFORM mode that sends a base64-encoded mini-profile for offline SPC. It would trigger once per N shots or on command from a _cmd.qi Notefile.

Process change detection computes an exponentially weighted moving average (EWMA) baseline for peak_psi and fill_ms on the device, then alerts only when a feature strays from its EWMA by more than a configurable sigma band.

Field-upgradeable firmware through Notecard Outboard DFU lets the OEM push threshold-logic updates across the fleet without a site visit.

Thermocouple fault-bit handling and internal-reference validation closes a known gap. The MAX31855 32-bit SPI word holds three fault flags (open-circuit, short-to-GND, short-to-VCC) in bits 2:0, and 12 bits of cold-junction (board-level) reference temperature in bits 15:4 (0.0625 °C per LSB). The firmware checks the fault flags and excludes faulted temperature samples from the shot averages, but it still sends the shot Note. When no valid temperature samples came in across an entire shot (from a disconnected or shorted probe, say), temp_avg_c and cool_c_s both show up as 0.0 in the payload. As §7 points out, that sentinel is ambiguous, because it looks just like a mold that really is near ambient temperature. A production improvement would either suppress the shot Note when the probe is entirely faulted, or replace the zero-valued sentinel with a value outside the physical temperature range (for example, -999.0) so downstream analytics can tell a faulted probe from a cold mold. Today the firmware reads the internal-reference temperature bits and throws them away. Sanity-checking that value against the expected ambient range (for example, 15–55 °C for a machine room) can catch board wiring faults and cold-junction compensation anomalies before they turn into bad thermocouple readings.

12. Summary

The process engineer who used to find out about a drifting mold only when scrap rates started climbing now sees every shot arrive in Notehub as five numbers they can actually interpret: peak pressure, fill time, pack pressure, average mold temperature, and a cooling slope. When any one of them drifts outside its band, a sync:true alert fires right away. All it takes is a standard 4–20 mA strain-gauge transducer tapped into the hydraulic manifold block and a K-type thermocouple seated in the mold's existing pocket. Nobody touches the mold, and the Notecard's cellular uplink carries the data without ever crossing the plant's OT network. The same hardware SKU and the same Notehub project work at every plant in every geography. An OEM can ship a process-monitoring module with every new machine, or retrofit the installed base, and count on a predictable deployment with no IT ticket or site survey for any of it.