Update the internal electronics of the device to take advantage of new components and improve performance and usability.

Description

Much of the base electronics in the product line were developed and selected in 2012-2014. Since that time there have been some minor updates and improvements with the electronics, but the primary development focus has been on firmware and software.

Over the last 5+ years upgraded processors have become available that can enable some improvements regarding storage size, reliability and transfer speed. There have also been new sensors which have become available and could be better utilized with an updated processor.

Requirements

• Increase the storage capacity limit to 32GB or greater (currently limited to 8GB)
• Improve file transfer speed from current of 500 kB/s
• Update or add newer embedded sensors to improve data quality, specifically include ADXL354/7 product suite.

Deliverables

1. Update existing Slam Stick line with new electronics hardware
2. Apply updated electronics design to future product developments

Cost to the Customer

This will likely not require any change in price point of the device, it's just part of our commitment to be continually improving and taking full advantage of technology's relentless advancement.

Example Use Cases

Virtually all current customers will benefit from the unilateral upgrade.

Develop a new product line of recorders to be accessible wirelessly to download recording files, change configuration, and start new recordings.

Description

The product will in many ways offer all the USB level communication but via a wireless interface. This will allow users to access recorders in hard to reach places to download data, change configurations, and start new recordings.

This will also enable a local computer/software to perform a monitoring sequence where the local computer starts a recording, wait for the recorder to reappear, download the data off the device, and then start the next recording. If/when a cloud portal is developed this same local computer/software can include in the sequence an upload to the portal for cataloging and worldwide access.

Requirements

• Wireless communication functionality of current USB communication
• Software support on local computer to initiate monitoring sequence. If possible this functionality could alternatively be handled on the device itself.
• Each local computer capable of communicating with 5 to 10 local recorders
• Some number of devices should be capable of being managed by one local computer/software to initiate recordings "simultaneously" (within 0.1 seconds).

Deliverables

A few stages would be utilized to receive feedback and buy-in:

• Products with static wireless communication (appear as a network drive)
• Software support on either the device or local computer to initiate a monitoring sequence
• Software support on local computer to upload data to cloud portal
• Gateway or edge devices (SBCs with rugged enclosures) to communicate with multiple devices and upload data to cloud portal.

Cost to the Customer

The upgrade to the electronics to handle such a wireless communication capability will result in some modest cost increase of approximately $500. The software support will remain free (so long as the data is saved locally and not to the cloud portal). If/when a gateway device is developed, the anticipated cost of that will be around $1,500.

Example Use Cases

1. Difficult access to recorders: A mechanical engineer has mounted the recorder inside his machine/system that is difficult to physically reach but accessible wirelessly (mostly plastic). They are unable to run wires to the device because it is operating autonomously and untethered. They would like the ability to check sensor data immediately after a test and adjust the configuration if necessary without dismounting the device. They also know when the test is about to start and could initiate a recording sequence remotely prior to.
2. Monitoring application: A mining company has several drilling assemblies throughout the site and need to semi-continuously monitor the machinery to understand when certain elements are likely to fail. They have developed their own analysis script to predict this but need a steady stream of incoming data. Replacing and rechargeable batteries on a monthly basis is acceptable for this application although they are considering providing a power supply.

Open source the libraries to parse .IDE recording files generated by enDAQ (Slam Stick) recorders.

Description

Many test applications are not the same from a measurement standpoint as well as an analysis perspective. Developers and analysts alike need the ability to directly interface with recording files without going through a GUI to develop custom applications and analysis scripts.

Many analysts and users, although technically competent and good data analysts are not well-versed programmers. However, they are adept at writing analysis scripts. They will need some assistance in accessing these libraries and getting started on their computer.

Requirements

• Return array of calibrated/converted data with time stamps per channel
• Return array of raw/unconverted data for faster processing
• Get list of sensor channels with metadata (sensor name, sample rate, etc.)
• Return metadata about recording (serial number, UTC start time, etc.)
• Future: configuration of recorders

Deliverables

• Published parsing library on Github
• Including the library in a pip installer and/or Anaconda for non-programmers to have relatively manageable access
• Add a scripting console to Lab software
• Tutorials and example scripts that utilize the libraries

Cost to the Customer

This will be published for free.

Example Use Cases

1. Programmer developing custom app: A programmer at an engineering company has an end customer that needs a very specific summary and display of recorded data. The progammer's company is looking to sell a software package along with a service to their end customer that utilizes enDAQ recorders to generate the data.
2. Data scientist performing custom analysis: A data scientist who is adept at writing analysis scripts in MATLAB, MathCAD, MAPLE, and some Python needs to perform a custom analysis on recordings and share with colleagues. The current workflow involves CSV exports that are time-consuming and require the use of a GUI. MATLAB tools have been very helpful but they require a MATLAB license to customize and the scientist is becoming intrigued about the cost savings Python offers. He has done some Python scripting but it is limited and will need some guidance in getting started; but he's a fast learner!

Develop a MATLAB based analysis software GUI to convert .IDE files to .MAT and then leverage the MATLAB runtime to provide efficient, yet powerful, analysis capabilities.

Description

Many of our customers, who are largely mechanical engineers, use MATLAB for their data analysis needs. Not only do they have familiarity with MATLAB, but MATLAB offers some performance advantages for processing of large arrays.

Requirements

• Convert IDE files with all data to .MAT
• FFT, PSD, spectrogram
• Integration, double integration
• Moving metrics (RMS, peak-to-peak, max, min, mean)
• Phase response to FFT
• Filtering (Butterworth, Bessel, Elliptical, moving average, convolution)
• Find peaks routine to characterize shock events
• Compile Tom Irvine's MATLAB GUI and integrate with this analysis package

Deliverables

1. Initial release of file conversion and basic plotting and analysis (FFT, PSD, spectrogram)
2. Second release with advanced analysis as laid out above (integration, find peaks etc.)
3. Third release to incorporate Tom Irvine's GUI
4. Host and share the source code on GitHub

Cost to the Customer

This will be offered for free along with the source code.

User Stories

1. Shock testing to then optimize design: A customer is looking to design a new passenger rescue boat that can survive ejection from the larger ship. When the boat impacts the water there is a significant shock event that is a product of many internal resonances in the boat as well as the rigid body motion of the boat itself. The engineering team would like to not only filter out the higher frequency data, they also need to perform a shock response spectrum analysis to better understand how to effectively design improved support structures.
2. Vibration testing to ensure electronics survivability: A customer is looking to design a new consumer robotic system. The robot can induce significant vibrations that the team need to understand and then simulate in the lab to ensure the electronics can survive. The shaker system they have in the lab requires a simplified PSD. They would like to take raw data to clean, apply a safety factor, and then use to simulate in the lab.

Develop a set of scripts and then a GUI for summarizing a large number of files and displaying it.

Description

Many users are utilizing triggering to record many different events and/or are using multiple devices. Right now all of our software is written for analyzing a single file at a time, but many customers now finish a test with hundreds, even thousands of recording files - or a very large file that can be cumbersome to analyze (and could be broken into smaller files). A set of example Python scripts which loop through a large number of recording files and then generates a database or table that is indexed by timestamp and recorder serial number is needed. In this table, some sensor information can be included with simple analysis such as max, min, mean, RMS levels, even frequency peaks. If the code is open, users could develop their own custom metrics they'd like to classify files based upon.

Then a GUI will be needed to assist with this characterization, but more importantly, display it. This display should include a snapshot of the mission with some simple plots, maybe a table of the "worst" 10 events and the ability for the user to then pull up individual files/events as needed. This display should ideally be in a format for easy export to include in user internal reports they may be generating.

Requirements

• Open source Python scripts
• Canned cataloging of recording files (recorder serial number, time stamp, sensors enabled, sample rate, max/min/mean, RMS, dominant frequency and corresponding amplitude, second dominant frequency and corresponding amplitude)
• GUI to initate characterization and then display
• Display should include a report function which is a one page PDF for easy integration in customer reports. This report should include a small table of the "worst" events.

Deliverables

A few stages would be utilized to receive feedback and buy-in:

• Open source scripts for summary and plotting
• GUI for simple summary and display
• GUI report generator

Cost to the Customer

This will be available for free.

Example Use Cases

1. Post-processing of many files: A mechanical engineer has performed a test over the course of several days with multiple devices. The test was a shipment from the facility in the US to one in Europe where an engineering team and/or end customer can download the data from the devices. The test has generated hundreds of recording files and they need to understand how things changed over time, and find specific files of interest.

Objective

Develop a recorder that only utilizes digital sensors to enable a reduction in size and cost.

Description

The current recorders have largely been developed to support the higher-end sensors we use that have analog outputs and larger physical sizes. Not every application requires these sensors, however, so we are planning a development of a recorder that uses the smaller and lower cost sensors that will be a more direct competitor to the MSR175. These will also include firmware for event-detection to reduce power and storage needs.

Requirements

• Target a 1"x1"x0.5" size
• Two accelerometers for vibration and shock, plus many environmental sensors
• Summarize data to options including max, min, average, RMS levels of each channel
• Nice-to-have, a replaceable primary cell battery

Cost to the Customer

There will ideally be two versions that come out of this development, both small, but different sensor and feature packages. One will have a tentative price point of $600 at quantity 1, the other $1,000. Like the other products, they will have volume discounts.

Example Use Cases

1. Shipping logger: A museum is shipping sensitive art that they would like to ensure is handled properly. They don't need all the raw data, just peak events and when they occured to then correlate this to who was in possession of the package at that time and potentially responsible for the damage.

Objective

Develop firmware to do onboard processing of recorded data to only save information of interest. This will extend battery life and reduce storage and post-processing needs.

Description

The current recorders have triggering to record events but they record all the data continuously. Some applications just need to know that there was an event and some details of the event, not all the raw data. This is especially true in many shipment tracking applications. Firmware development is needed to do some onboard processing to save event summary information such as RMS vibration, max/min, temperature etc. This development can extend battery life, reduce storage and post-processing needs and will become especially useful once we have wireless communication.

Requirements

• Configurable item in software to do event-based recordings
• Summarize data to options including max, min, average, RMS levels of each channel
• Nice-to-have, compute an FFT in real time and save FFT peaks

Cost to the Customer

This will be a firmware option and therefore not have any direct cost to the customer.

Example Use Cases

1. Shipping logger: A museum is shipping sensitive art that they would like to ensure is handled properly. They don't need all the raw data, just peak events and when they occured to then correlate this to who was in possession of the package at that time and potentially responsible for the damage.

Objective

Enable an external analog input channel to use external sensors and/or synchronize recorded data to a known time stamp.

Description

Many of our recorders include a sensor that has an analog output that we are sampling at 20 kHz in each sub-channel. The processor and A/D converter we are using have 5 more channels that we aren't using, we'd like to extend a channel out of the enclosure for external sensors. We have done this customization for occasional customers but there are a few issues:

• No filtering or electrical protection
• Software treats the extra channel as "acceleration"
  Following the hardware update, a more formal extra analog channel option can be enabled that will include filtering and electrical protection. The software will also need to be developed to treat the extra channel as a separate channel to acceleration.

Requirements

• Include low-pass analog filters with user selectable frequency cutoffs
• Protection for voltages outside 0-3 volts and over current

Deliverables

• Hardware add-on to include two wires exiting the rear of the recorder for analog channel
• Software support to change units and scale this data

Cost to the Customer

The added complexity in manufacturing and assembly will add a $500 fee for units with this external channel.

Example Use Cases

1. IRIG Time Stamps: An engineering team is performing testing on a missile system and the time stamps are critical to correlate vibration/shock data to other sensors and systems. They have a voltage signal for the IRIG time stamps that they would like to use to synchronize recorded data.
2. External Pressure Sensor: A group is recording vibration data on an engine and they'd like to understand how the pressure inside the engine compartment changes over time and relates to vibration levels. They need a higher frequency sampling rate for this ability than the ambient pressure sensor included in the unit.

Objective

Develop a waterproof accessory case that can reduce the size and weight of the current one.

Description

The current waterproof accessory design, although robust, is quite large. A development that results in a polycarbonate mold for the top and a simple aluminum base and an o-ring can accomplish the same sealing ability with less mass and size.

The development can also be utilized to include magnetic mounting accessories and a strain-relief for the USB cable when plugged in (this wouldn't allow for the polycarbonate top when in use).

Requirements

• IP68 required
• Small size and weight

Deliverables

One product:

• Waterproof mounting accessory with magnetic mounting options included

Cost to the Customer

The same cost as our current waterproof case: $500.

Example Use Cases

1. Long-term outdoor test: An engineering team is designing a light structure that mounts to the underside of a bridge. This bridge supports a commuter train and as it passes overhead some vibrations are imparted on the lights. Prototypes have not survived over long periods of time and the engineering team suspects that vibrations from the train are damaging the lights. They would like to quantify the vibrations caused by the train over a week of operation (account for different commuter schedules and weather) and then use this data to design a better fixture to support the lights. This data will also be used to simulate the environment for internal testing.
2. Shipping logger: A defense contractor has developed an expensive radar system that needs to be transported from the manufacturing site to the installation site. This shipment can take several days up to several weeks depending on the destination. This system is sensitive to very fine vibrations (<5g) and the engineering team has developed isolation structures to protect the system; but they need to prove to the end customer that the system has not been damaged during shipment. Traditional "shock loggers" will be ineffective due to the data quality needs.

Enable users to input external sensors that take advantage of improved data quality and size yet still benefiting from our ease-of-use and portability.

Description

We have targeted a higher-end market of test engineers that tend to have a better understanding of sensing applications compared to other data logger products. Our embedded sensors are very good relative to those products but they still fail to compete with other applications which require even better resolution, sensitivity, lower noise, smaller mechanical form factor etc. With our lack of time synchronization there is also little chance of users to do modal testing but if we enabled 2 to 4 inputs that are sampled at the same time we would be able to address that market.

There are also some applications that require a very small sensor to provide minimal impact to the environment; but they still need portability and ease of use. The most attractive feature of this development would be that we would be able to target other sensing types without doing custom developments each time. The external inputs would allow users to customize for their needs.

A prototype was developed for the Navy, shown below, and installed in a ship for a 7 month sea trial. These systems will take 4 thermocouple measurements once every 15 minutes for over 2 years.

Requirements

• Keep as many embedded sensors as possible
• Larger battery to power and acquire data from additional sensors for longer periods
• Customizable sensor types (different conditioning boards/modules) to meet greater array of sensors
• Module for thermocouples
• Module for 2-wire sensors (traditional piezoelectric sensors and generic analog)
• Module for 4-wire strain gauge based sensors
• Base recording system have 2 modules, each module with 2-4 channels
• If possible, interface with TEDS sensors to self-describe the sensor attached further making the use easy

Deliverables/Phases

• Start with base system and thermocouple input
• Second module enables the input of 2-wire sensors
• Third module enables the input of 4-wire strain gauge based sensors
• Develop products with integrated conditioning/modules to the base electronics for potentially lower cost and smaller size

Cost to the Customer

The recording system that accepts these external inputs will be a little more complex than the line of fully embbeded sensors. The system will likely cost on the order of $1,500 and then $500 per module. Additional cost for specific sensors but those sensors can be purchased by other vendors too and will range in cost of $300 to $1,500.

User Stories

1. Long term shipboard test: A characterization of an engine room is needed on a Navy ship. Several different temperature locations are needed and the test will run for several months.
2. Car vibration test: A mechanical engineer is developing a new support structure in a Humvee and they need to first understand how the current structure performs in real-world settings, then characterize the new prototypes. They have 8 locations throughout the Humvee they want to monitor and make sure the data is all synchronized. They don't mind running some wires, they are more concerned with ease of use, survivability, and portability.

Develop a cloud portal that .ide recording files can be imported to and accessed globally. Enable cataloging of files so that a basic understanding of the file can be achieved before directly opening/accessing it.

Description

Users are beginning to perform tests over long periods of time with multiple devices that generate hundreds, even thousands of recording files. It can be very time consuming to find particular recording files of interest and also understand how the environment has changed from test to test without directly opening the file.

As the product line begins to evolve towards a wireless product offering, it will become important to provide a centralized file storage system that can be accessed by devices and by customers globally (who may not be in the same location).

Testing and analysis is often a collaborative process where the engineer performing the analysis is doing so on a team and has an end customer who also wants to occasionally access data files. To promote collaboration between internal and external stakeholders this portal should also be very "shareable" so that a link/key can be provided to others to enable sharing of data.

Most importantly, the files themselves need to be "described" with details about the device and sensors used to generate the data and even summary metrics themselves. In the short term this information can be useful to users looking to find the points of interest in a test; but in the long run this same infrastructure can be used in monitoring applications to show in semi-real time how important metrics are changing over time.

Requirements

• Cloud storage
• Canned cataloging of recording files (recorder serial number, time stamp, sensors enabled, sample rate, max/min/mean, RMS, dominant frequency and corresponding amplitude, second dominant frequency and corresponding amplitude)
• GUI in desktop software to upload/download and view list of files (with summary metrics)
• API keys to access files and portal and share specific files with custom scripts
• Custom cataloging function capability

Deliverables

A few stages would be utilized to receive feedback and buy-in:

• Cloud storage (simple online file access - "Dropbox for .ide files") - this includes a desktop based GUI to interact with the files/portal.
• Canned cataloging when files are uploaded
• Documented API to access files with custom scripts and receive API pull/push requests when new files are available
• Interface (could be through desktop app) to provide a custom script that catalogs files with custom numeric metrics as they come into the portal (also allow for post-processing and cataloging of files to fine tune the analysis functions). Documentation and examples will be needed to demonstrate the functions/objects/outputs the system is looking for and providing.
• Browser-based interface to view contents of the database, upload/download data, and manage billing

Cost to the Customer

This system will have inherent costs based upon total storage, upload/download frequency and size, and computing requirements. As such the cost is elastic depending on usage. We would look to have an elastic and transparent pricing model where the user pays for what they use. We recognize the concern over receiving surprise bills so we would include a user-defined maximum monthly limit. Some grace period would be provided with warnings when the limit is being approached and warn that over usage is occurring.

Baring in mind that the cost is elastic depending on use, we'd expect the cost to the average customer to range between $50 and $250 a month per recording device.

Example Use Cases

1. Post-processing of many files: A mechanical engineer has performed a test over the course of several days with multiple devices. The test was a shipment from the facility in the US to one in Europe where an engineering team and/or end customer can download the data from the devices. But this data now needs to be accessible by both teams to understand how the test/shipment went. And they need to collaborate on how best to analyze these recording files. The test has generated hundreds of recording files and they need to understand how things changed over time, and find specific files of interest.
2. Monitoring application: This use case requires a product line that is interfacing with the cloud portal to directly upload files from the device. In this instance, the team has set up the test at their customer's site that has internet access but it is a separate location than the "home base." The engineering team returns to their respective offices after setting up the test and now expects to see/analyze data as it is being continually generated and uploaded to the portal. The engineering team utilizes the portal and the API to develop a custom dashboard with alerts they provide to their end customer to notify them of issues with the test/system as they arise.

Develop and offer a Slam Stick variant with a larger battery.

Description

The current enclosure design of the Slam Stick does not allow for use in particularly harsh environments (outdoor applications). The current battery chemistry also does not perform well in cold environments making some aerospace applications unaddressable even though the core electronics can survive down to -40C. The battery size is also optimized for single day use and there is an increasing need for longer "missions" that last on the order of weeks, even months.

Requirements

• Larger rechargeable battery option to enable a battery life measured in weeks (~20x increase in capacity)
• Battery able to provide adequate power and voltage down to -20C (-40C desired)

Deliverables

• Large rechargeable battery in an aluminum enclosure

Cost to the Customer

The added complexity in manufacturing and assembly to enable waterproof enclosures and larger and more expensive batteries are likely to add between $500 and $1,000 in the purchase price.

Example Use Cases

1. Long-term outdoor test: An engineering team is designing a light structure that mounts to the underside of a bridge. This bridge supports a commuter train and as it passes overhead some vibrations are imparted on the lights. Prototypes have not survived over long periods of time and the engineering team suspects that vibrations from the train are damaging the lights. They would like to quantify the vibrations caused by the train over a week of operation (account for different commuter schedules and weather) and then use this data to design a better fixture to support the lights. This data will also be used to simulate the environment for internal testing.
2. Shipping logger: A defense contractor has developed an expensive radar system that needs to be transported from the manufacturing site to the installation site. This shipment can take several days up to several weeks depending on the destination. This system is sensitive to very fine vibrations (<5g) and the engineering team has developed isolation structures to protect the system; but they need to prove to the end customer that the system has not been damaged during shipment. Traditional "shock loggers" will be ineffective due to the data quality needs.
3. Aerospace, low temperature test: A system is being developed for aerial refueling. In order to effectively design a system, very robust and well-defined environment requirements are needed concerning the vibrations and accelerations caused by the event. Due to the effects from air flow, pressure, weather etc. lab simulations are not effective. A recording system is needed to record the event over several hours at an air temperature of -20C.