Docs / Contact / devices/live-metrics

Live Metrics

A compact rail sits at the right of the workspace tab bar and shows what the connected board is actually using: RAM and storage, as used / total, with a bar under each.

It answers one question: how close am I to running out?

Reading the rail

The peak marker is the one worth watching. You run out at the peak, not the average: a loop that averages 40% but spikes to 95% is the one that fails, and the spike is usually gone by the next sample.

How often it updates

Keeping it live from your own script

The board has one REPL, and a running script owns it. Rather than compete for the port, which would corrupt both its samples and your script's output, the rail stands down and waits to be told.

So while your script runs, your script is what feeds the rail. One call does it:

from tendrl import emit_metrics

while True:
    # ...your work...
    emit_metrics()

The Terminal recognizes those lines, hides them from the scrollback, and routes them to the rail, exactly like preview.frame() does for camera frames.

In a tight loop, skip the filesystem check, since heap is what moves:

emit_metrics(refresh_disk=False)     # reuses the cached storage figures

If you also want the numbers in your terminal output, sample once and use it for both, so the two can never disagree:

from tendrl import sample_metrics

while True:
    m = sample_metrics(refresh_disk=False)
    print('TDLMETRIC:' + json.dumps(m))                  # -> the rail (hidden from scrollback)
    print('used %d / %d' % (m['a'], m['h'] + m['a']))    # -> your terminal
    time.sleep(1)

sample_metrics() returns {'h': free, 'a': allocated, 'df': disk_free, 'dt': disk_total, 'p': psram_free}. It handles the root path for you: /flash on OpenMV, / elsewhere.

Watching memory while you develop

The rail is most useful when you're about to allocate something large and want to know whether it fits.

Loading a model. Start a detector in the Vision playground and watch RAM step up as the tensor arena allocates. Measured on an OpenMV AE3:

That first-frame spike is exactly what the peak marker is for: the steady figure alone understates what the detector demands.

Stopping a run frees it. Models live in device globals, so stopping the playground releases them and RAM returns near its baseline. If you load a detector by hand over the REPL, it stays resident until you drop the reference and collect.

Finding a leak. Run your loop with emit_metrics() and watch across a few minutes. Flat is healthy. A steady climb that survives collection is a real leak, and the peak marker preserves the high-water mark even if the value settles back.

← Back to Contact docs