RFRTime to Next Experiment
JPEN
Try one failure

Prototype / Co-validationWe run focused PoCs from one resolved failure or one existing device.

Mission / The time RFR gives back

Shorten debugging.
Extend value validation.

RFR connects device communication, embedded Linux, LTE, and cloud behavior on one shared timeline.

It reduces time spent on device integration, protocol analysis, and failure reconstruction so physical AI teams can spend more time validating customer value on real machines.

Connect what would not connect. Resolve what breaks next with evidence. Return to the next real-world test sooner.

Try one resolved failure Validate device integration or wireless readiness View the 60-sec demo
  • ConnectUnderstand protocols and connect devices
  • DetectNotice anomalies and preserve evidence
  • ReconstructNarrow the failure scope with evidence
  • ContinueReturn to the next real-world test

Customer promise

Reduce device integration and failure investigation time. Return to the next real-world experiment sooner.

See the time recovered

Problem / Friction before value validation

Development time disappears into device integration and system-wide failure isolation.

Teams should be learning whether a robot improves customer operations and can run safely and continuously.

Instead, time goes into understanding protocols, preparing logs, waiting for a failure to recur, aligning timestamps, and coordinating across teams.

01

Connection

Find documentation, understand the protocol, build a dedicated driver, and test it on the machine.

02

Capture

Wait for intermittent failures and add logs. Automatic recovery often hides the first deviation.

03

Reconstruction

Search across formats and clocks, align evidence manually, and test competing hypotheses.

04

Handoffs

Move repeatedly between application, embedded, connectivity, and cloud teams to assemble the story.

Interviews with mobile robotics teams confirmed that diagnosing LTE issues across robot and cloud can stall real-world testing and customer-value validation.

Customer outcome / Time recovered

RFR shortens three critical intervals.

Protocol translation, log integration, anomaly detection, and Failure Reconstruction are means, not the end.

The goal is to shorten the time from a failure to the next valuable real-world experiment.

01

Time to connect

AI-assisted protocol understanding and validated Adapters reduce documentation search, driver implementation, and integration testing.

02

Time to detect

Known-error rules and deviations from normal models preserve the surrounding evidence as a Failure Clip before it disappears.

03

Time to next experiment

Failure Timeline and Evidence Chain reduce log search, timestamp alignment, team handoffs, hypothesis testing, and missing-evidence discovery.

North-star metric

Time to Next Valuable Experiment

Time required to begin the next valuable real-world test

Value Validation RatioValue validation time /
(Value validation + integration + investigation time)

RFR is designed to increase this ratio.

Concrete case / LTE failure

The motors and sensors are healthy. Is it LTE, the modem, or the cloud?

Every component can look healthy while the end-to-end task still fails.

RFR links available evidence across layers and shows the first observed deviation, likely failure scope, uncertainty, and missing evidence.

  1. 01Robot Task

    Operational task and request

  2. 02ROS 2 / App

    Send, timeout, retry

  3. 03Linux

    Process, driver, network

  4. 04Modem

    AT, reset, registration

  5. 05LTE

    Signal, cell, data session

  6. 06Transport

    DNS, TCP, TLS, MQTT

  7. 07Cloud

    Receive, process, respond

  8. 08Recovery

    Reconnect, retry, state

LayerEvidence examined
ApplicationSend request, timeout, retry
LinuxProcess, driver, and network state
ModemBoot, reset, registration, disconnect notifications
RadioSignal quality, cell changes, connection state
Data SessionIP acquisition, session establishment and loss
TransportDNS, TCP, TLS, MQTT, HTTP
CloudRequest receipt, response, processing delay
PowerVoltage drop during LTE transmission and modem resets

RFR workflow / Return to validation

Connect. Detect. Reconstruct. Return to the next experiment.

RFR brings Observe, Normalize, Detect, Capture, Reconstruct, and Register into one workflow.

Raw logs remain the primary evidence. AI stays read-only and supporting.

01

Observe

Read-only ingestion of ROS 2, Linux, modem, LTE state, device bus, cloud, and operator logs.

02

Normalize

Convert vendor-specific notifications into common events such as application.request.sent.

03

Detect

Detect known errors and deviations in connection time, response time, and reconnect frequency.

04

Capture

Freeze Agent and Node ring buffers on anomaly and create a Failure Clip around the event.

05

Reconstruct

Align clocks and formats, then present First Observed Deviation, Evidence Chain, and uncertainty.

06

Register

Store validated Adapters, normal sequences, reconnect patterns, Failure Patterns, and regression conditions.

60-second demo / LTE Failure Timeline

Reconstruct a mobile robot LTE failure from device to cloud.

The request reached the modem. LTE data-session latency then moved outside its normal range and the application timed out.

RFR does not treat the successful recovery as proof that nothing failed. It links the first deviation and reconnect sequence back to raw evidence.

  1. 03.100TASK

    Patrol task requests the next command.

  2. 03.112APP

    ROS 2 application begins transmission.

  3. 03.124MODEM

    Linux sends the request to the modem.

  4. 03.380DEVIATION

    LTE response latency exceeds the normal range.

  5. 04.100TIMEOUT

    Application timeout.

  6. 04.120RECOVERY

    Automatic reconnect begins.

  7. 07.800CLOUD

    Cloud connectivity is restored.

  8. 08.100STATE

    The task transitions to interrupted.

Project: mobile-robot-connectivity-failure / device-to-cloud evidence

Timeline

sample JSONL

    Selected Event

    evt_000000

    Select an event

    Raw HEX

    -

    ASCII

    -

    Payload JSON

    {}

    AI Debug

    Select the ai_analysis event to view facts, hypotheses, and recommended checks.

    Product components / Built to return teams to validation

    One foundation for integration, observation, and reconstruction.

    LTE can be both an Edge Gateway uplink and an observed target in Failure Reconstruction.

    Teams begin with available logs and only the observation points they need.

    01

    RFR Ingest Agent

    Read-only capture of ROS 2, applications, Linux, network, modem, cloud communication, and ring buffers on embedded Linux or robot PCs.

    02

    RFR Tap / Bridge Node

    Observe and normalize UART, RS-485, and other physical communication outside Linux. OBSERVE and BRIDGE remain separate modes.

    03

    RFR Edge Gateway

    Manage BLE Mesh, Direct BLE retrieval, clock coordination, and Failure Clip collection. Add Ethernet, Wi-Fi, or LTE only when needed.

    04

    RFR Reconstruction Core

    Normalize Semantic Events, map clocks, detect anomalies, build Failure Timelines and Evidence Chains, identify missing data, and register patterns.

    BLE-only Node

    Raw stays local

    Each observation point keeps its ring buffer and timestamp information.

    BLE Mesh

    Control and notification

    Discovery, health, anomalies, configuration, and retrieval requests. No continuous raw transfer.

    Direct BLE

    Retrieve only the needed window

    Transfer a Failure Clip directly from the target Node to the Gateway.

    Edge Gateway

    Aggregate external connectivity

    Add Ethernet, Wi-Fi, or LTE only when external connectivity becomes necessary.

    Reusable knowledge

    Use every protocol learned in the next integration and investigation.

    Normalize logs that differ by device and modem into common events.

    AI proposes Adapter candidates from manuals. After human validation, the Adapter runs deterministically without AI.

    Common Device Model

    • Command / State / Measurement
    • Fault / Transaction / Capability
    • UART / RS-485 / Modbus RTU
    • Motors, sensors, power, and actuators

    Common Connectivity Model

    • Application Transaction: request / timeout / retry
    • Modem State: ready / resetting / unavailable
    • Network Registration: searching / registered / lost
    • Data Session: activating / active / degraded
    • Signal Condition: strength / quality / cell / mode
    • Transport: DNS / TCP / TLS / MQTT / HTTP
    • Recovery: reconnect / modem reset / interface restart
    vendor modem notification  →  modem.registration.changed
custom application log     →  application.request.sent
cloud access log           →  cloud.request.received

    Adapter Registry: Stores modem-specific AT notifications, firmware differences, normal connection sequences, reconnect patterns, known Failure Patterns, and regression conditions.

    PoC / Co-validation for the next experiment

    Start with one failure whose cause and fix are already known.

    We validate RFR through fixed-scope Sprints rather than presenting it as a finished product.

    You do not need every log. We can start with three to five data sources.

    Connectivity Failure Reconstruction Sprint

    For teams re-analyzing LTE, modem, or cloud failures

    Reconstruct one resolved mobile-connectivity failure as a Device-to-Cloud Timeline.

    • ROS 2 and application logs
    • Linux system and kernel logs
    • Modem AT and LTE state
    • TCP / TLS / MQTT / HTTP logs
    • Cloud access logs
    • Power, reset, and operator records

    Deliverables: Failure Timeline, First Observed Deviation, Evidence Chain, failure scope, uncertainty, Missing Evidence, next-capture plan, recurrence rule candidates, and Evidence Bundle.

    Wireless Readiness Sprint

    For teams connecting or adding wireless capability to an existing device

    Observe, translate, and validate one wired device externally before modifying the product.

    • OBSERVE current communication
    • Map to a Common Model
    • Shadow Translation
    • Wired Bridge test
    • Separate BLE Mesh and Direct BLE roles
    • Latency, loss, and disconnect emulation

    Deliverables: feasibility, required bandwidth, acceptable latency, retry and state-sync risks, Adapter proposal, and test items for a real wireless PoC.

    Safety & Data

    Separate observed facts from what cannot be observed.

    AI never sends direct commands to controlled equipment. Raw logs remain primary.

    When mobile network operator internals are unavailable, RFR does not fill the gap with a guess. It marks Missing Evidence.

    Analysis boundary

    • Separate First Observed Deviation from root cause
    • Separate Observed Facts from Hypotheses
    • Preserve time and ordering uncertainty
    • Keep AI read-only and supporting
    • Run validated Adapters deterministically

    Data safety

    • NDA available
    • Agree storage location and deletion deadline in advance
    • Never use customer data for model training
    • Limit what is sent to AI
    • On-premises and local analysis available for discussion

    CTA / PoC inquiry

    Measure the time back to the next experiment with one failure.

    Start with the failure summary, the original investigation time, available log formats, and timestamp information. Do not attach raw logs or confidential information to the initial inquiry.

    View technical details

    The button converts your entries into an email. If no email application opens, copy the address.

    FailureWhat failed and how it recovered
    TimeInvestigation time, occurrence time, and clock types
    EvidenceApplication, Linux, modem, LTE state, cloud, and power logs
    BoundaryUnavailable operator internals, confidentiality scope, and deletion terms