a safe, low-cost IV fluid warmer design; for when commercially available IV fluid warmers are too expensive or cannot be sourced

Similar projects worth following
The OpenFluidWarmer warms intravenous fluids and blood products to human body temperature prior to infusion/transfusion. In general, IV fluid warmers are not needed during routine blood transfusions. They are used only when rapid transfusion is required. The OpenFluidWarmer is meant as an alternative when commercially available IV fluid warmers are too expensive or cannot be sourced.

The Problem

"Commercial fluid warmers are either cost prohibitive in many contexts or not available for purchase" (Field Ready Fluid Warmer Open Challenge, Hackaday Prize 2020). 

The Solution

A low-cost IV fluid warmer design that incorporates all industry standard safety features and solves the difficult cost and sourcing challenges encountered when constructing this device anywhere in the world.

Hackaday Prize 2020 Judging Criteria

i. Concept. The OpenFluidWarmer has the potential to become one of the world's first open source life-critical medical devices. Achieving this status requires an innovative new take on IV fluid warmer design. It must incorporate all industry standard safety features and solve the difficult cost and sourcing challenges involved with constructing this device anywhere in the world. 

ii. Design. From product requirements to FMEA and competitive analysis, all design documents are shared in the "Files" section of this project. In addition, significant design efforts and milestones are documented in the "Project Logs". The design will undergo rigorous design verification before being released to the public. A user manual will provide instruction on operating procedure, safety hazards, maintenance, and troubleshooting.

iii. Production. Reproducibility is at the core of the OpenFluidWarmer design. Through common off-the-shelf components, widely accessible manufacturing techniques, and a flexible design that can accept multiple alternative components, the OpenFluidWarmer will solve the cost and sourcing challenges encountered when constructing this device anywhere in the world. An assembly manual will guide users step-by-step through the assembly process. 

iv. Benchmark. A competitive analysis was performed to understand how this OpenFluidWarmer compares to commercially available IV fluid warmers (see "OpenFluidWarmer_competitive_analysis" in the "Files" section of this project). The most significant findings from the competitive analysis are discussed in this "Competitive Analysis" project log. The price and quantity of each item used in the device is detailed in the "OpenFluidWarmer_BOM" document in the "Files" section of this project.

v. Communication. All significant project efforts have been documented on the OpenFluidWarmer project page so others can quickly become familiar with the current design and the processes used to develop it.

Development Stages

  1. Initial system architecture and cost study, complete
  2. Initial mechanical design, complete
  3. Heat transfer proof-of-concept prototype, waiting on parts and developing testing capabilities
  4. Code development, not started
  5. Proof-of-concept prototype testing, not started
  6. System architecture redesign, not started
  7. Mechanical redesign, not started
  8. Code redesign, not started
  9. Field prototype, not started
  10. Field prototype testing, not started


bill of materials, component pricing

sheet - 15.94 kB - 07/17/2020 at 05:02



product requirements, design targets, product classification

sheet - 14.08 kB - 07/17/2020 at 03:43



FMEA, fault conditions, and state indicator strategy

sheet - 18.53 kB - 07/11/2020 at 23:27


sheet - 11.53 kB - 07/11/2020 at 23:27



heating and energy usage calculation

sheet - 11.17 kB - 07/11/2020 at 23:27


  • Bang-bang Control

    John Opsahl5 days ago 0 comments

    The test setup depicted in the image is representative of one of the hot plates of the two hot plate IV fluid warmer design that is being evaluated. A 100W heater silicone pad is sandwiched between a layer of polystyrene insulation foam and a stainless steel medical tray. Two 100kOhm thermistors are fed through holes in the stainless steel tray and mounted to the side of the tray opposite the heater with aluminum tape. As part of the two hot plate IV fluid warmer design, the IV tubing will be in direct contact with the hot plate on the same side as the thermistors. 

    The 100W silicone heater pad and two 100kOhm thermistors are operating successfully with a bang-bang feedback controller. The controller is programmed to turn on the heater if the device is below 36degC and turn it off when the device reaches 36.25degC. Cooling is achieved by natural convection for this test setup. Because the heater and thermistors are on opposite sides of the stainless steel medical tray, the thermistors detect a temperature change about four seconds after the heater has been turned on. After the heater shuts off at 36.25degC, it continues to transfer heat to the hot plate. The hot plate starts to cool down after reaching a maximum temperature near 38degC. Since the heater and stainless steel tray are sandwiched between two layers of polystyrene, the lowest thermal resistance path is through the stainless steel plate out to ambient air.

    It was not my original intention to implement a bang-bang controller, but I am now considering it based on the potential cost savings and simplicity. Up until this point, I have been expecting to implement a PID control algorithm with a 3D printer heater, power FET module. In total, the power FET modules are about $4 USD (5% of total material cost) more expensive than the relay modules needed for bang-bang control. It wasn't until I realized that the power FET modules I had bought require a minimum input signal of around 7.5V (Arduino only outputs a 5V PWM signal) that I considered bang-bang control just to get something working. Bang-bang control has the disadvantage of always drawing max current of around 16.6A combined for both 100W, 12V heaters. Even so, I am looking forward to testing bang-bang control with the two heater plate prototype.

    The next step is to complete the two heater plate proof-of-concept prototype and test it with the fluid temperature rise test setup that I described in the last project log. All materials have arrived and the majority of the fabrication is already done. It will take about two to three more evenings to get everything setup and the first set of performance data collected.

  • Fluid Temperature Rise Test Setup

    John Opsahl07/26/2020 at 21:42 0 comments

    I recently developed the test setup for measuring the fluid temperature rise through the OpenFluidWarmer prototype. A peristaltic pump, typically used for aquarium dosing, pumps fluid through the tubing at a rate of approximately 65ml/min. Two DS18B20 measure fluid temperature at the inlet and outlet of the tubing. An Arduino Nano captures the temperature data from both sensors and sends the data through serial to the computer. I use the PLX-DAQ macro spreadsheet to pull the serial data directly into Microsoft Excel. Once in Excel, it is very easy to manipulate and plot the data.

    The actual testing will include several differences that I did not think were needed to ensure proper operation of the test equipment and instrumentation. The pump will draw fluid from an ice bath. This will ensure a constant fluid inlet temperature and approximate the 4degC initial temperature typical of blood products. An ambient temperature sensor will be added to keep record of environmental temperatures between tests. In addition, the system will be allowed to achieve a thermal steady state condition over a period of ten minutes. 

    This test cuts corners for convenience and is not necessarily representative of how the OpenFluidWarmer would perform with actual blood products. The density and thermal capacity of water is different from whole blood and packaged red blood cells. Hardware store vinyl tubing is used instead of medical grade IV tubing. The pumping action of the peristaltic pump may add a small fluid temperature rise. The inlet temperature will be at 0degC rather than the 4degC typical of the initial temperature of blood products. So the purpose of this test is not to determine with great accuracy if the current OpenFluidWarmer can meet the fluid warming requirements, but whether it is reasonable to think that it could. If not, options are to either accept lower performance or go back to the drawing board.

  • Initial Mechanical Design

    John Opsahl07/20/2020 at 04:59 0 comments

    This initial OpenFluidWarmer mechanical design is a result of the last month of research. Each product analysis exercise (cost, souring, heat transfer, competitive analysis, design requirements, etc.) helped to identify design opportunities that I would not have found otherwise. Perhaps equally important, they helped to eliminate the many sub-optimal solutions that were floating around in my head. Because of all the upfront research, I had about 80% clarity on what the mechanical design would look like prior to staring the 3D modelling and working through the dimensional details.

    You might have noticed that this new mechanical design has almost no resemblance to the metal tube enclosure prototype that I proposed previously. The main reason I moved away from the metal tube design is because of the poor heat transfer rate from the heaters to the IV fluid. More specifically, the new design requires less length of IV tubing through the device in order to transfer the same amount of heat to the IV fluid. This higher heat transfer coefficient between the heat source and the IV fluid is achieved by sandwiching the IV tubing between two heaters rather than exposing only one side of the IV tubing to the heat transfer surface. 

    Couple of other interesting details of this design:

    • the IV tubing follows a large turning radius path through the device to prevent kinks in the tubing
    • the heat transfer contact surface is stainless steel so will not corrode and is able to be cleaned easily
    • insulation (i.e. white blocks/frames in the renderings) surrounds the heaters and heat transfer contact surface so that the path of least thermal resistance is from the heat source to the IV fluid
    • it should be able to accept all diameters of IV tubing up to 7mm; tubing diameter effects the rate of heat transfer that can be achieved so will result in different maximum allowable fluid flow rates
    • the tools required to construct this device are a drill with drill bits, a utility knife, wire cutters, and a soldering iron
    • all components are available through the AliExpress website, total cost of all components is just under $90 (still have opportunities to reduce cost to the $80 target)

    Most of the components have either already arrived or I can pick them up from the hardware store. The next effort is to build up a prototype and determine the maximum achievable fluid flow rate with this design.

  • Competitive Analysis

    John Opsahl07/11/2020 at 22:59 0 comments

    I compiled a competitive analysis table using information from IV fluid warmer manufacturer's websites to better understand the strengths and weaknesses of the OpenFluidWarmer design. All of the competitor IV fluid warmers I selected for this analysis are commercially available, portable, battery powered, and designed for use in disaster and combat zones. 

    In this log I will only comment what I consider to be the most important takeaways from this exercise. For those who want all the details, see the "IV_fluid_warmer_competitive_analysis" spreadsheet included in the files of this project.

    Device weight and volume are two parameters that I excluded from this analysis. It's my full intention to minimize weight and volume of the OpenFluidWarmer design when convenient, but I don't consider those parameters to make-or-break an open source IV fluid warmer design.

    The most telling performance parameter of an IV fluid warmer is the maximum allowable flow rate when warming fluid from 4 to 38 degC. This is especially true for IV fluid warmers that are designed for use in disaster and combat zones. In these applications, where blood loss from traumatic injuries is the most common reason for a blood transfusion, achieving high flow rate transfusions can be an important factor in patient outcomes. That being the case, most of the IV fluid warmer systems I selected for this analysis have maximum flow rates equal to or greater than 100 mL/min. 

    I arrived at a lower flow target of 80mL/min for the OpenFluidWarmer design because I am unsure if a higher flow rate is possible with easily sourced components. More specifically, I am unsure if I can achieve a high enough rate of heat transfer to the fluid while also minimizing the length of IV tubing used. Given a sufficiently long length of IV tubing, it would be relatively easy to design a device capable of higher flow rates. But longer IV tubing means a larger fluid pressure drop through the device (too high of a pressure drop and high flow rates are not even achievable), a larger IV prime volume, simply more IV tubing per procedure, and likely a larger volume of product that is left in the lines at the end of the procedure and never makes it to the patient. 

    The competitor designs all use their own custom, proprietary consumable inline IV tube "chamber" to maximize heat transfer to the IV fluid. This chamber increases the thermal contact surface area between the fluid and the heating element. Thus allowing a higher rate of heat transfer to the fluid. For the OpenFluidWarmer design to be easily sourced, it cannot use a custom heat transfer "chamber". At the moment, the only viable option I have been able to identify is to heat the fluid by contact through standard IV tubing. 

    The relaxed weight and volume requirements for the OpenFluidWarmer may allow a low-cost, easily sourced design that can achieve flow rates greater than 100mL/min. It's just going to take some ingenuity and design iteration to get there.

  • Open Source Life-Critical Medical Devices

    John Opsahl07/04/2020 at 18:23 0 comments

    Open source life-critical medical devices are not common because of the liability that manufacturers of the device and medical professionals using the device assume when the device is used on a patient. The current practice to reduce this liability and ensure patient safety is to certify the medical device with a trusted government regulation body. For good reason, certifying life-critical medical device is generally a very intensive (and consequently costly) process. 

    This "introduction to the regulations to design, commercialize and distribute an open source medical device in EU" document provides brief overview of what types of open source medical devices require certification. 

    The secondary barrier to the development of open source life-critical medical devices is the high level of design complexity required to ensure patient safety during operation. Redundant monitoring and user alert systems are good practice towards ensuring that the user is alerted of any device malfunction in a timely manner. As you can imagine, these redundancies can double or triple the complexity of the hardware and software.

    To date, I have not seen a open source life-critical medical device that I would consider to be successful. "Successful" meaning a completely open design, widely reproduced, and considered an acceptable alternative to a commercially available product.

    All of this background information is meant to put this effort to develop a open source IV fluid warmer in context. Because in some circumstances, an IV fluid warmer might be considered a life-critical medical device. Will the OpenFluidWarmer project result in one of the first "successful" open source life-critical medical devices? Who knows, but it certainly seems worth a try.

  • Challenging Failures Modes, System Faults, and State Indicators

    John Opsahl06/25/2020 at 03:31 0 comments

    Someone's life could be at risk if the IV Fluid Warmer does not operate properly. To better understand and address potential failure modes of the device, I have performed a system FMEA. Through this analysis I have developed a design strategy that includes double redundant fault detection and user alert methods.

    Even so, there are a few failure modes where it is both difficult to detect the failure and difficult to convey to the user that a failure is occurring. These challenging failure modes include the scenario when either the microcontroller fails (a rare occurrence) or if the power being supplied to the device is interrupted (a likely occurrence particularly if a battery is used to power the device). Under these scenarios, if the user isn't actively watching the indicator lights on the device, they are unlikely to notice that the lights are no longer lit up and the device is no longer operating. There may be a 30 second or so grace period after either failure scenario when heat continues to transfer from the unit to the IV fluid, but eventually the rate of heat transfer to the fluid will slow and the IV fluid exiting the device may drop to an unsafe temperature. My current thought to alert the user during these scenarios is to either include a battery or capacitor in the device that will discharge to a buzzer when the microcontroller is no longer functioning (when it either fails or doesn't receive power). 

    Next I put together a list of system fault conditions that will implemented in software to detect when a failure mode has occurred. Hard faults will cut power to the heaters. Hard fault conditions represent scenarios where there is risk that the system will heat the IV fluid to 42 degC or greater and cause hemolysis of the blood products. A soft fault will just inform the user (in a sufficiently annoying manner) that the system isn't functioning properly and that it may or may not still be heating the IV fluid properly. The soft fault allows the user to recognize that there is an issue with the device and decide whether it is in the patient's best interest to continue to administer the fluid or to stop and investigate the cause of the fault. Three sensing devices will be used by the system for fault detection: four heater control temperature sensors, a system level hall current sensor, and an analog voltage sense. 

    ID Description Type
    F01 erroneous temperature sensor reading soft
    F02 large variation of temperature sensor measurements soft
    F03 temperature sensor above max temperature limit hard
    F04 temperature sensor below min temperature limit soft
    F05 current is larger than max allowable current hard
    F06 increase in current is larger than max allowable current change hard
    F07 decrease in current is larger than max allowable current change soft
    F08 input supply voltage below min supply voltage soft
    F09 input supply voltage above max supply voltage hard

    Finally, I have decided on the following strategy for alerting the user of the state of the system using three colored LEDs and a buzzer. 

    State Indicator
    State Red Light Yellow Light Green Light Buzzer
    hard fault solid - - ping every second
    soft fault flashing - - ping every 5 seconds
    warm up - flashing - ping every 30 seconds
    warm up period over - - solid ping five times rapidly
    operating; no faults - - solid ping every 5 minutes

  • Enclosure Prototype

    John Opsahl06/22/2020 at 23:10 0 comments

    I threw together a first iteration prototype of the enclosure today. It is comprised of a 250mm section of 3in diameter galvanized air duct, a male thread 3in PVC end cap, and a 3in compression pipe plug. The current plan is to mount the power switch and led indicator lights in the white PVC end cap. Eventually, I will create a permanent water tight seal between the white end cap and duct pipe. The red compression pipe plug is meant as a service port. It forms a water tight seal with the duct pipe when tightened and can easily be loosened in order to get access to the internal electronics for troubleshooting. 

    For the highest flow rate, the tube will need to be wrapped around the entire length of the duct pipe. Testing is needed to further understand how many wraps around the duct are required for the lower flows. Certainly wrapping around the entire length is most energy efficient, but may use more tube length than desired or result in a higher than acceptable pressure drop from inlet to outlet. 

    The silicone heater pads will wrap around the inside circumference of the metal duct pipe. Electronics will sit in the center core of the pipe (inside the wrapped silicone heater pads). I may route the 12V power supply connection through the duct pipe near the red compression pipe plug (with chord grips for a water tight seal).  

  • System Architecture and Cost Breakdown

    John Opsahl06/22/2020 at 18:28 0 comments

    The first iteration of the system architecture assumes two 100W silicone pad heaters inside a 3in diameter HVAC air duct. PID control on an Arduino Nano will be used to maintain constant temperature. Four thermistor temperature sensors will be used for temperature feedback. Heater power is controlled with two mosfet boards that are typically used for 3d printer heated beds. IV tubing is wrapped around the 3in air duct multiple times. Heat is generated by the silicone heater pads, transferred to the air duct, and then transferred through the IV tubing to the fluid.

     The system will maintain temperature at 39 degC. If temperature exceeds 42 degC during normal operation, the heaters will turn off and the user will be informed through a visual and audible alarm. If the device temperature drops below 36 degC during normal operation, the user will be informed through a visual and audible alarm. Upon startup, the system will inform the user when the device has warmed up to 39 degC through a visual indicator. I may include input voltage sense for battery powered systems. When battery voltage drops below the voltage threshold a visual indicator would turn on to show low battery power. The voltage threshold is dependent on which battery system is used so would have to be configurable in the microcontroller code.

    The latest cost breakdown shows a total system cost of $60 (excluding the required 12V, 20A power source). This cost estimate is not conservative. I expect the final design to be closer to $75. 

  • Heat Power and Flow Calculation

    John Opsahl06/22/2020 at 17:33 0 comments

    A quick calculation shows that the maximum possible IV fluid flow rate with two 100W heaters (at 85% heat transfer efficiency) is approximately 80mL/min. This assumes that the blood product enters at 4degC (typical whole blood and packaged red blood cell storage temperature) and leaves at 39degC. 

    Assuming the electronics consume an additional 12W of power, I arrive at a duration between battery charges of approximately 1 hour for a typical 12V, 45Ah car battery at a 17.7A discharge rate (based on the lead acid battery voltage curves I found online). At 80 mL/min, it is theoretically possible to warm thirteen 350mL units of blood product before the battery needs to be recharged.

  • IV Fluid Warmer Background Research

    John Opsahl06/21/2020 at 18:17 0 comments

    Background Research 06-21-2020:

    - blood warmers are rarely needed during routine transfusions, they are used when rapid transfusion of components is required
    - blood storage temperature, 2 to 6degC (whole blood/red cell component)
    - blood tranfusion temperature, 30 to 37degC
    - suggested rate of transfusion (adult)
        + whole blood 150-200mL/hr
        + PRBC (packed red blood cells) 100-150mL/hr
        + platelets/plasma 150-300mL/hr
    - suggested rate of transfusion (pediatric)
        + whole blood/PRBC, 2-5mL/kg/hr (17 mL/min allows transfusion in less than 30 minutes)
        + platelets/plasma, 1-2mL/minute
    - duration times for transfusion
        + whole blood/PRBC, less than 4 hrs (start within 30 minutes of removing from refrigerator)
        + platelet concentrate, less than 30 minutes (start immediately)
    - warmed blood is most commonly required for:
        + large volume rapid transfers
            * adults, more than 50mL/kg/hr
            * children, more than 15mL/kg/hr
        + exchange transfusions in infants
        + patients with clinically significant cold agglutinins (patient produces autoantibodies which cause agglutination of red cells at cold temperatures)
        + rapid infusion of blood products through central lines
    - blood should never be warmed in a bowl of hot water as this could lead to hemolysis (i.e. rupture) of the red cells which could be life-threatening when transfused
    - a radiant heater should never be used to warm the blood being transfused because of the risk of hemolysis
    - volume per unit of:
        + whole blood, 450ml
        + PRBC, 220-350ml
        + plasma, 180-270ml
        + platelets, 35ml
    - material properties of blood
        + density 1.05g/ml (1050 kg/m^3)
        + specific heat 3490 J/kg*K
    - medical tubing materials
        + polyvinyl chloride (PVC), most common (approx 30% of market)
        + polyethylene, second most common
        + thermoplastic elastomers (TPE)
        + nylon
        + silicone
    - blood transfusion IV tubing catheter size 
        + adults, 18 gauge (nominal inside diameter 0.838 +/- 0.038mm)
        + pediatric, 22 gauge minimum (nominal inside diameter 0.413 +/- 0.019mm)
    - infusion/transfusion line diameter
        + outside diameter 4 to 7mm
    - warming blood to temperatures greater than 42degC may cause hemolysis
    - nominal capacity of a standard 12V car battery is approximately 45Ah

View all 10 project logs

Enjoy this project?



Enceladus wrote 07/15/2020 at 05:45 point

Hey there. I wanted to make sure I fully understood everything before commenting.

With being a class IIb device and hitting the other regs makes QA/QC kind of straightforward.

You'll need to quality control the firmware, which means, among other things you'll need version control, commit signatures, a bug tracking system, and release testing.

For the firmware release testing you'll need to basically trigger each of the code paths and make sure they work as intended. This means causing each of the 9 faults and verifying the lights and buzzer plus the normal operation ping. The rest of the testing can be saved for the finished product testing. For firmware testing you can use "tricks" such as a resistor or controlled current to simulate temperature, but for product testing you'll need to include the assembled thermistor in the loop.

For each produced unit you'll want to do QA that consists of build integrity (seal condition, etc) as well as functional testing. For functional testing you'll want to ensure that it is able to meet the product specs (i.e. warm from 4deg to 36deg in x seconds, warmup time, flow rate etc). It sounds like a lot but you could trigger the hot/cold with ice cubes and hair dryer. Getting it at exactly 42c etc. is only necessary for the firmware testing, for finished product testing you can overshoot.

You might want to build a testing rig that can test many units at once to not cause a bottleneck in production. Probably 5 is a good minimum but 6 is a very divisible number for handling stock requests on the fulfillment side.

To test warming and flow you could use some kind of analogue. I'm not aware of if there is any official analogs for blood but I'd guess some sort of formulation of water and baking soda could do it. You'd have to of course match the specific heat and viscosity.

QC for finished product consists of verifying QA paperwork is completed properly and signed off, and visual inspection. Visual inspection should be thorough and track things that wouldn't even affect operation such as scratches or extraneous sealant or solder, etc. You should have a library of common defects and their severity, with example photos of each kind of defect. One allowable severity is "cosmetic" and doesn't necessarily fail the QC (unless you want it to).

Assemblers and inspectors should have documented training (a signed log that once a year or release version or whatever is reasonable, they have reviewed the product design manual / inspection procedures)

You should also include in the product documentation a suggested QC for incoming materials, although it may need to be customized to suit individual material choices and sources.

One thing you may want to consider is putting a lifetime operating hours counter in the unit. I'm not sure if the Nano has an RTC or nonvolatile storage but they can be added for very little cost.

I understand you want parts to be easily available too but thinking as a user it might be nice to have a version of the product which uses an LCD screen with full operating status, even if it makes IP54 more difficult. If I was operating one of these things I'd want to see Lifetime power-on, time since power-on, current temp, Alarm history log, estimated flow rate, battery remaining, etc.

Adafruit/digikey has a display for only $10 surprisingly ( ). Might also be able to double as non-volatile storage.

That's probably plenty to start. Hope it helps! Each part can be expanded on in great detail when the time comes.

Oh one more thing you probably want to test at least once, having several fully charged batteries ready then operating the thing for many days on end without interruption and make sure it doesn't overheat the Nano or something. In a variety of ambients (like a desert field hospital). You just know someone will use it in this way...

  Are you sure? yes | no

John Opsahl wrote 07/15/2020 at 15:11 point

Enceladus, this is fantastic! Thank you for the feedback. 

The firmware release testing and functional testing will probably get lumped under what I will call design verification testing. I've got several more weeks of mechanical design work and code development before I will be ready for those tasks.

The topic that I was very glad you touched on was how to ensure quality of the final product when assemblers have an unknown level of assembly experience and materials choices and sources may be different for each build. It has been in the back of my mind since I started this project, and I haven't been able to see a clear path forward until now. 

I really like the idea providing a training path for each assembler to become a "certified OpenFluidWarmer assembler". Then requiring annual retesting to maintain the certification. Possibly only allow full access to the design documents without going through the certification process first. 

On QC of incoming materials, in addition to an inspection plan, I think it also makes sense to detail out the specification requirements for each component. That will provide the information needed to make an alternate material or component selections if any of the materials or components in the bill of materials cannot be sourced. 

This definitely gets me excited about the next stage of this project. So I may ping you later on in the project if that is okay. Right now though, I have to keep focus on a proof-of-concept prototype. QA/QC only helps if the design actually works. :)

  Are you sure? yes | no

Enceladus wrote 07/15/2020 at 23:11 point

You got it exactly right about incoming materials. Ping away...I'll be around

  Are you sure? yes | no

John Opsahl wrote 07/15/2020 at 15:39 point

Perhaps I can include a method to alert the user that the device should be tested/calibrated/maintained after a certain number of operating hours. 

I hadn't considered an alarm history log yet. That would be invaluable for troubleshooting and service of the device. Especially if the fault condition is hard to reproduce. 

With the current design, the only way to determine what condition is causing the fault would be to make a connection to the microcontroller and view any error messages on a serial monitor. This certainly isn't convenient for quick troubleshooting in the field. One of my ideas for a very low cost solution is to have two conductors on the outside of the device. One to microcontroller ground and one to an analog output pin. The microcontroller would output a different voltage from 0-5V based on the last fault condition that occurred. The user could measure across the two conductors with a multimeter and reference a table in the user manual to determine the cause of the fault.

  Are you sure? yes | no

Enceladus wrote 07/15/2020 at 23:14 point

Or you could output morse code text! 3.14159265359 volts for dit and

2.71828182846 volts for dah ;) jk

  Are you sure? yes | no

Enceladus wrote 07/15/2020 at 23:36 point

on a more serious note, BLE might not be a bad way to go either, then theoretically you could monitor multiple devices from a phone or tablet. There are modules out there in the $3-5 dollars range.

  Are you sure? yes | no

Similar Projects

Does this project spark your interest?

Become a member to follow this project and never miss any updates