Skip to main content

Inspecting a Device

Individual Devices can be accessed through many parts of the web application, for example by clicking on a Device's serial number on the Devices search page.

Device details​

Most of the metadata describing the Device lives in the Details section. You can view the hardware version and last reported software version, as well as when the device first and last contacted Memfault. You can also define some metadata yourself, namely the Nickname and Notes for the Device. This can be useful, for example, to record your notes from a debugging session.

Image showing the entire Device details page

Linked Devices​

note

This feature is not automatically enabled, please contact us to discuss how it can be enabled for your Project.

In many situations a Device does not operate in a vacuum. When debugging wireless earbuds, for example, the left and right bud is intimately linked, and misbehavior in one can cause a crash in the other. Memfault enables your Devices to report which other Devices they are in some way linked to, whatever "linked" means in your particular case.

Animation showing the mouse hovering over a linked Device tag in the Device details page

Tabs for debugging​

Below the Device details is a rich set of data reported by the Device, suitable for both debugging and general observability. This view contains slightly different information depending on your device, please see the pages for MCU devices, Android devices and Linux devices for more details.

Custom Data Recordings​

In some projects, devices already capture additional data in custom formats which can be useful to analyze when debugging issues, for example, trace data, proprietary coredumps, non-standard logs. Memfault allows this arbitrary information to be bundled as a "Custom Data Recording" (CDR).

CDRs allow you to collect custom data for specific events happening on your device. Data sent via the CDR API can be of any format, which is then visualized and downloadable from the Device Timeline. To enable this, each CDR is bundled with metadata when uploaded:

  • Reason - This describes what was the cause/reason for sending the CDR. Limited to 100 different unique values.
  • MIME types - One or more MIME types describing the contents of the CDR.
  • Duration - The amount of time the CDR represents (can be 0).
  • Start Time [Optional] - When the capture began. Defaults to the API server's current time in UTC minus the CDR's duration.

Some example use cases of CDRs are:

  • Collecting debug data using a proprietary format
  • Capturing UI heatmaps
  • Recording screenshots of a device when errors occur to better understand what a user was seeing or doing just before a crash
  • Adding test reports for devices in a hardware-in-the-loop test set up
  • ...

For each unique reason given to a CDR, a swimlane is created on the timeline. Clicking or hovering over a timeline entry will give you the metadata of the CDR as well as the option to download the data for further analysis.

Screenshot showing basic custom data recording use case

CDR Reason​

In principle, the reason fields is a free-form string field. A project can only have 100 different CDR reasons. Our recommendation is to treat the reason as an "enum" and use only a small set of static values. In the Device Timeline, all CDRs with the same reason are shown in the same swimlane.

Some examples: for a connected device with a display, we might want to capture the modem logs when it disconnects. We could be using Modem Disconnect for the reason field. Aside of that, we may also want to capture a screenshot image after a crash happened (and the user gave consent to upload a screenshot). Here, we'll use the reason User Feedback Post Crash as the reason.

In the future, Memfault will also extend the Device Search to enable searching for devices having CDRs with a given (set of) reasons.

CDR MIME types​

Memfault uses the MIME types array provided to infer the best visualization to use in the Timeline. The MIME types in the array are expected to be ordered by specificity (most specific first). The visualization for the most-specific but supported MIME type will be used by the Timeline.

note

When using proprietary MIME types, we recommend using one of the types in the table below as the last entry (fallback) in the MIME types list.

For example, for the modem logs CDR from the connected device we talked about in the previous section, we may be using a MIME types list of: application/vnd.acme-inc.modem-trace.v2, application/vnd.tcpdump.pcap, application/octet-stream.

The first and most-specific MIME type is application/vnd.acme-inc.modem-trace.v2. This is a self-coined (not IANA-registered), vendor-specific MIME type, as indicated by the vnd. prefix.

The modem logs happen to be recorded in a format that is a superset of the pcap format. Therefore, we use application/vnd.tcpdump.pcap as the second MIME type in the list. This is the official IANA-registered type for a pcap file (Wireshark dump).

Lastly, application/octet-stream is used in the MIME types list. This type essentially means "application specific binary data".

Even though Memfault does not have a Timeline visualizer for pcap data, let alone the vendor-specific format extensions to pcap, it might be added some day in the future. It also helps to identify the format of the payload when downloading it from the device timeline. For this reason, we recommended using an accurate list of MIME types.

Supported CDR visualizations​

MIME typeDescriptionVisualization
text/*TextComing soon: a preview of the text contents in the popover of the CDR.
text/markdownMarkdownComing soon: a preview of the Markdown contents in the popover of the CDR.
application/json, */*+jsonJSON dataComing soon: a preview of the JSON contents in the popover of the CDR.
application/octet-streamBinary dataComing soon: a preview of the contents in a hex viewer in the popover of the CDR.