Wireless Recorder
Stephen Hanly
Member, Administrator, Moderator Posts: 64 admin
Objective
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
- 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.
- 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.
Comments
Any plans for data streaming over USB (or WiFi)? E.g. in addition to exposing the device as mass storage, add a CDC (RS-232 adaptor), either as a switchable mode, or as a second device on a hub?
We definitely have plans for streaming over WiFi! In fact we have prototypes/dev-boards in house that are streaming 7 megabits per second of data over WiFi to a local FTP server.
The device somewhat supports a "streaming" over USB but it's crude. It allows a local computer to initiate a recording, wait for the device to reappear, copy the data off, then start again. We can and will make improvements to this interface in the future, but the focus for the time being is wireless. When we get back to updating the USB interface, it will be part of a development to make and sell more traditional electronics modules that developers can easily design into their system and still get the benefits of our firmware and soonish cloud interface (if desired). We'll do this as part of the module development because we have a failure mode now where the USB connector fails from strain while plugged in. It happens in about 1% of fielded recorders but that is still too high, and can only be addressed with a different connection type.
Here's more information on that USB software interface.
Cool, thanks!
I understand that it goes somewhat against the philosophy of an autonomous, smart, self-contained data logger, but did you consider an option of a dumber device – no storage, a reasonable RAM buffer, minimal CPU, just enough electronics to continuously stream samples to a desktop/laptop, then do all the high-level work (triggers, filters, storage, etc.) with a desktop CPU? This can be an interesting option price-wise, and would simplify development (debugging , e.g., Python on a real computer is so much easier than embedded C).