Export lists of Devices as a CSV​

Users can now bulk export lists of Devices and associated information as a CSV file. Use filters as normal to define the desired list of Devices and then export that list as a CSV. Once the CSV is generated it will be emailed to the user. This makes it easy to share information on specific groups of Devices to teams in the organization outside of Memfault for the purpose of further processing in external tools or scripts for logistics, reporting, etc.

By default on export the CSV will include basic information about the Device such as serial number, cohort, software and hardware version etc. and a user can also choose to include custom attributes in the export if required.

See data in Metric charts as soon as it’s received​

Data in Metric charts is now available in “real-time” once received. Previously, data in Metric charts only updated once the day in UTC completes and this would add some delay in the insights the Metric charts were able to provide. Now the Metric data collected from devices is visible in Metric charts as soon as it is received by Memfault.

This enhancement will allow users to react quicker to undesirable changes in behavior and provide closer to real-time information during significant events like software version roll-outs. Currently, this change is only applicable to Metric charts and does not apply to other chart types (e.g. Issues charts, Device set charts, etc).

Software versions displayed in Device Timeline​

Device Timeline now includes a visualization of the active software version on the device alongside the metric and traces information. This allows a user to very quickly associate any metric behavior, crash or reboot event with the active software version at the time.

As demonstrated in the screenshot, this should also make it very easy to identify if a change of behavior coincides with a change in software version. The software version is now displayed by default across all Devices on all platforms.

Best Practice Guide: Using MQTT with Memfault​

We have released a new best practices guide covering the use of the MQTT protocol with Memfault. Correct set-up for your MQTT implementation is critical as errors in set-up can result in data loss or data being decoded incorrectly rendering it impossible for Memfault to deliver accurate insights.

The guide provides a basic introduction to MQTT and specific advice for users looking to optimize their MQTT stack to ensure reliable data delivery to Memfault. Topics covered include:

• Publishing QoS settings
• Topic architecture and recommended topic structure
• Minimizing publishing overheads with topic aliases
• Choosing an MQTT payload size
• Device and Service examples

Read the full MQTT guide in our best practice documentation.

New Data Aggregation for Metric Charts: Percentiles​

Metric Charts now have a new data aggregation available for both chart rollup options (by Cohort or Software version, and Over Time). This aggregation is called “Percentiles” and will display the data set broken into the 1st, 5th, 50th, 95th and 99th percentiles. Displaying the metric data as percentiles makes it easier to understand the prevalence of behaviors (tracked as metrics) across your fleet.

As an example, if you are seeing significant spikes in battery discharge rates for a specific software version you can use percentile aggregation to get a clearer picture of the scale of this problem. Are these undesirable metric readings I am receiving contained to a small set of samples or is this a wide scale problem? Conversely, this aggregation should also make it easier to understand what “normal” actually looks like across your fleet.

This new aggregation is the default view when creating any new metric chart. You can read more about this new data aggregation in our Metric Charts documentation.

Best Practices Guide for Android Battery Debugging​

Our Developer Experience team have released a new guide designed to help users get the most from Memfault when identifying and debugging battery issue on Android devices. This guide provides detail on:

• What data the Android SDK can collect
• Using metric charts for tracking battery health/performance
• Setting fleet and device alerts
• Identifying problem devices
• Debugging individual devices using Device Timeline

The guide takes into account the recently released set of updates to our Android SDK with version 4.8.0 which included the addition of new battery usage metrics such as per app battery usage.

You can read the full guide in the Memfault Best Practices for Android Battery Debugging.

Bulk Issue Merging improvements​

Users can now merge multiple issues together with a few clicks, eliminating the previously repetitive process of merging each issue independently. This addresses the scenarios where Memfault’s de-duplication algorithm may not group related issues due to unaccounted for variables within the issue signature making each appear as an independent issue.

Users can now use all of the filtering capabilities within the issues page to narrow down to a specific issue set and either bulk select or individually select a set of issues they believe should be merged into one issue. You can read more about issues and bulk merging in the Issue Management documentation.

Android SDK 4.8.0: More OTA control, more metrics and more issue tracking​

The most recent Android SDK 4.8.0 introduces a number of new features for Android customers. Android customers now get powerful additional controls for the OTA update process, more granular battery usage metrics and tracking of SELinux violations.

The OTA improvements allow users to control download and install behavior independently and dependent on additional payload specific metadata and/or current device condition. For example, you can ensure that devices will prioritize updates a user has tagged as “critical” for download and will only install an update if certain battery conditions are met. You can read more about the specific configurations in Memfault’s documentation on configuring download and install for OTA updates.

The changes to battery metrics allow users to view the battery usage per app, distinguish usage in screen-on or screen-off scenarios, and see battery capacity, all on the device timeline view. This gives much more granular visibility into battery performance and further enhance users’ ability to root cause issues. You can read more about this in Memfault’s Android Battery Summary Metrics documentation.

Finally, we added support for tracking SELinux violations via Memfault. Tracking these issues will now be possible with all of the same functionality as the other pre-existing Android issue types.

Metric Charts: Comparison by Software Version or Cohort​

Metric charts have been enhanced with the addition of a new chart type presenting a direct comparison version to version or cohort to cohort without time as a variable. This new chart type presents a comparison of min/mean/max data aggregated across the entire comparison populations based on your selection (e.g. min/mean/max ever reported on v1.0.0 vs min/mean/max ever reported on v.1.0.1).

The pre-existing “over-time” chart view restricts comparison to an 8 week window which is great for intensive monitoring but less good at judging absolute performance. This new chart type allows users to make more effective performance comparisons in real-world scenarios and take decisions with more confidence.

You can read more about this new chart type in Memfault's documentation.

Increased Configurability for Alerting and Notifications​

Alerting and notification functionality has received a set of significant enhancements. These include the introduction of configurable incident start and end delays, the ability to decide at which stages of an incident a user wants a notification, and increased control over the scheduling for incident summary notifications.

These changes are designed to give users greater control on an alert-by-alert basis over the alerting behavior and incident related notifications, reducing unnecessary “noise” without sacrificing visibility. Ultimately these changes help ensure alerts trigger notifications which are highly relevant and timely.

You can read more about these changes to alerting, incidents and notifications in Memfault's documentation.

Simplified Debugging with Device Timezone in Memfault​

The Timezone selector allow users to adjust the timezone within which all information viewed in Memfault is contextualized for that session. Currently, the timezone selections available include “Browser” (browser default), “Universal” (UTC), “Device” (configurable) and “Custom” (region selection).

Timezone selection within Memfault is designed to make it easier for international teams working with globally deployed devices to contextualize, coordinate and collaborate. Whether you want to standardize working within the “Universal” timezone across your team, or you want to use the “Custom” or “Device” options to adjust your session to the specific local timezone of a device you are debugging, having this type of control over context can be powerful.

To provide a specific example, let’s say you receive a report of a customer having an issue with a device via your support team. The end user has reported a problem at 11am this morning. Rather than the developer needing to do the calculation manually they can just adjust to the correct “Custom” timezone assuming they know where that device was located. This process is even quicker if “Device” timezone is configured and takes a single click with no additional information required.

This month we made some improvements to the function of the “Device” timezone selection for Android devices. This selection is now available by default for Android devices using the persist.sys.timezone system property.

You can read more about timezones here and about the Android specific “Device” timezone metric collection here.

Server-Side Support for Developer Mode​

Developer Mode now allows you to temporarily remove any server-side rate limiting on devices from within the device view. This new functionality gives you full control over your integration/testing process with no imposed requirement to pause or prematurely switch between devices because a rate limit has been hit.

This will make it easier to integrate, configure and test new Memfault features and accelerate the testing, debugging and feature development processes of your own products using Memfault.

Developer Mode is activated on a per-device basis and will remove all rate limiting for uploads from the device to Memfault of coredumps, bug reports, heartbeats and other data. This Server-Side Developer Mode functionality is an extension of the existing device-side Developer Mode (Android, Linux) and they can be used in tandem or independently.

Memfault Support for Cortex-R​

Memfault has expanded its coverage of Arm-based devices adding support for coredumps on Arm Cortex-R. This allows customers to realize the full value of the Memfault monitoring, debugging and update capabilities on more of their Arm-based devices.

For customers already familiar with integrating the Memfault Firmware SDK on Cortex-M devices, the process for Cortex-R-based devices is very similar, with the only minor difference in the integration of the exception/interrupt handlers on Cortex-R. For more information on how to complete the integration, please review our Arm Cortex-R integration guide.

New Access Control Permissions: Teams and Roles​

Memfault added new concepts for access control: Teams are a flexible way to group members of an organization. They can reflect an actual company structure with functions such as “quality assurance” or “firmware engineering.” Alternatively, with Roles, administrators can design teams solely to manage permissions more conveniently when assigning dedicated roles on a per-project level.

Teams and Roles allow for configuration scenarios such as “read-only access for this department” or “OTA must only ever be performed by these four people.” They further allow for sophisticated setups such as “these five contractors may only ever see this one project and nothing else” or “newly invited members of the organization can do anything with our playground project but are otherwise limited to read-only access.”

Using this new system is strictly optional as all members of an organization are part of the group “everyone” that grants permission to all of Memfault’s features by default.

Memfault Support for RISC-V on ESP32-C3 Devices​

Memfault now supports RISC-V on ESP32-C3 devices. By following the steps in the ESP32 ESP-IDF integration guide, you will be able to integrate the Memfault Firmware SDK into a system that is using the ESP-IDF, including the ESP32-C3 chip. The integration guide assumes you already have a working project/toolchain for the ESP32. If you do not, the official getting started guide is a great resource.

Including Linked Devices in the Search Results​

With the introduction of the Linked Device Search feature, users can not only list the devices returned by search results, but also the devices that are linked to those devices. This is helpful when defining a population of devices (both primary and linked) before performing follow-up tasks such as assigning them to a specific Cohort, describing a new Device Set or assigning Fleet Sampling Resolutions and while doing so preventing any discrepancies (e.g. linked device staying in the old Cohort while the primary device is moved to a new one). Improvements to the Device Details page will also allow users to easily inspect the configuration states and update the Fleet Sampling Resolutions of both devices.