Close
0%
0%

OpenFluidWarmer

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

Similar projects worth following
The OpenFluidWarmer is a safe, low-cost, easy-to-manufacture solution that provides IV fluid warming capabilities to those with few financial resources or sourcing options. Some IV fluid products must be stored at temperatures below human body temperature. The OpenFluidWarmer reduces the risk of hypothermia in the patient by warming the IV fluids to body temperature before they are administered. Together we can make IV fluid warmers accessible to everyone.

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

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

The Impact

  • A safe, low-cost IV fluid warming solution that is accessible worldwide.
  • A reduction in the cost of commercially available fluid warming solutions either by market pressure from a lower cost option or by adoption of the OpenFluidWarmer approach.
  • A proven product development path for open-source electromechanical medical devices.

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 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 fabrication 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 the 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 Hackaday.io project page so others can quickly become familiar with the current design and the processes used to develop it.

Development Milestones

  1. Initial system architecture and cost study, complete
  2. Initial mechanical design, complete
  3. Heat transfer proof-of-concept prototype, complete
  4. Gen 1 prototype code development, complete
  5. Gen 1 prototype testing, complete
  6. Gen 2 heat transfer approach, complete
  7. Gen 2 system architecture, complete
  8. Gen 2 code development, complete
  9. Gen 2 prototype testing, complete
  10. Field prototype, not started
  11. Field prototype testing, not started

OpenFluidWarmer_ProductRequirements_10-18-2020.xlsx

product requirements, design targets, product classification

sheet - 15.55 kB - 10/18/2020 at 17:22

Download

OpenFluidWarmer_BOM_10-29-2020.xlsx

bill of materials for one unit, component pricing, component common use, component source

sheet - 23.88 kB - 10/29/2020 at 05:34

Download

sheet - 11.00 kB - 10/31/2020 at 22:11

Download

sheet - 16.33 kB - 10/18/2020 at 05:57

Download

Adobe Portable Document Format - 339.88 kB - 09/28/2020 at 03:53

Preview
Download

View all 13 files

  • 1 × Bill Of Materials See "OpenFluidWarmer_BOM" document in the Files section of this project for a complete bill of materials for one unit.

  • IR Temperature Sensor Measures IV Fluid Through IV Tubing

    John Opsahl01/12/2021 at 03:21 0 comments

    I finally got around to testing the GY-906 BAA IR temperature sensors. The test results indicate that measuring the temperature of IV fluid through IV tubing is not only possible with IR temperature sensors but also can likely achieve something close to +/- 1°C accuracy! I was pleasantly surprised and this was such a great way to close out this project. 

    Testing of the IR temperature sensor involved using the sous vide cooker to warm water to several different temperature setpoints then pump the water through an IV tube and detect the temperature using a GY-906. 

    To get a good reading from the IR temperature sensor, I had to place the IV in direct contact with the senor and apply a very small amount of pressure on the IV tube to push it against the sensor.

    IR temperature sensor readings for six water bath setpoints between 20-60°C are shown in the table below. No sensor reading deviated by more than 0.7°C from the water bath setpoint temperature.

    I am still surprised by the accuracy of the results. My first thought was that I may have been too quick to dismiss using a thermistor on the outside of IV tube to get an accurate temperature reading. So I hooked up a couple thermistors I had on hand. The temperature response was at least ten times worse than the IR temperature sensor and the thermistors would only read 47-49°C when the water bath setpoint was 70°C.

    It's pretty cool to find that a <$10 part can be used to accurately measure IV fluid temperature through an IV tube. This was not a problem that I thought I would be able to solve at the beginning of this project.

    This will likely be the last log of the OpenFluidWarmer project. I had a lot of fun pushing the boundaries of open-source medical device development and developing a working IV fluid warmer prototype. A big thanks to everyone who provided feedback and encouragement on this project over the last six months. Please feel free to message me if you have any interest in the continued development of the OpenFluidWarmer or want to chat about the challenges of open-source IV fluid warming.

  • Measure IV Fluid Temperature with an IR Sensor

    John Opsahl11/18/2020 at 05:48 0 comments

    A low-cost method for measuring the temperature of IV fluids through IV tubing or IV bags would be a game changer for the safety of the OpenFluidWarmer design. I have purchased three GY-906 BAA IR temperature sensors this week for testing. I am encouraged by medical temperature measurement studies that have shown that non-contact IR temperature sensors can achieve +/- 0.5°C measurement accuracy. 

    Temperature sense of the IV fluid at the IV bag will ensure that the operator has a double check on inlet IV fluid temperature. Inlet temperature determines the length of IV tubing that is to be immersed in the water bath, water bath set point temperature, and IV fluid flow rate. 

    Temperature sense of the IV fluid in the IV tube at the outlet of the OpenFluidWarmer will ensure that IV fluid is not warmed above the threshold at which hemolysis begins to occur. Warming the fluid above temperature can be caused by immersing too much length of IV tubing in the temperature bath, using too high of a water bath setpoint temperature, assuming too high of an inlet IV fluid temperature, or using too low of a IV fluid flow rate.

    Without IV fluid temperature measurement at the inlet and outlet, the burden is on operator to ensure that the IV fluid remains within the normal operating temperature limits. Incorporating IV fluid temperature sense can help reduce the burden on the operator and help quickly identify over temperature hazardous conditions. 

    I remain skeptical that there might be an accurate, low-cost method to measure IV fluid temperatures through IV tubing and IV bags, but am confident that there is something to be learned from testing these GY-906 BAA IR temperature sensors.

  • Gen 2 Prototype Cost Analysis

    John Opsahl11/10/2020 at 05:03 0 comments

    The latest cost workup puts the OpenFluidWarmer Gen 2 design just under $110; roughly $10 above the $100 cost target. It is important to note that these costs include shipping and are based on shipping to the United States. In the table above, items are listed from top to bottom in decreasing contribution to the total cost of the device. The sous vide cooker, electronics enclosure, and stainless steel mixing bowl being the top three most expensive components and representing over 70% of the total cost.

    During requirement development I had little visibility on all the required safety features and how much each would cost. At the time, the $100 cost target was my best guess at a competitive upper limit. Since performing the hazard analysis, I have more insight into which safety features are important and which cost increases are well justified for risk mitigation. 

    I am proposing that the new competitive cost target be moved to $125. This new cost target considers safety features that have not yet been added and an approximation of the price fluctuations that I have observed on the components over the last few months. Even at $125, the OpenFluidWarmer device is at most 22% the cost of a commercially available IV fluid warmer with comparable safety and performance.

    I predict that an additional $5-6 of savings is possible with more creative ways of repurposing other common-off-the-shelf items. These savings are just difficult to arrive at quickly. I most often find these opportunities for savings when looking for parts online for other projects. It is always surprising to me how many specialized items that I am totally unfamiliar with can be considered commonly available. Browse AliExpress for ten minutes and you will get an idea of what I am talking about.

  • Operating Procedure and Operational Parameters Table

    John Opsahl10/31/2020 at 22:12 0 comments

    The operating procedure has had the single most influence on the design of the Gen 2 prototype. The reason for this is simple - the most unpredictable and difficult to control component of the OpenFluidWamer solution is the human operator. Understanding how relays, 7 segment displays, button switches, temperature switches etc. can fail and cause a hazardous condition is a trivial task compared to understanding all the ways the human operator can make an incorrect action that results in harm to the themselves or the patient. Therefore, it has been a major focus of the OpenFluidWarmer design to reduce the number of opportunities that the device can be used incorrectly by the operator and cause a hazardous condition.

    See "OpenFluidWamer_OperatingProcedure" in the files section of this project for the latest version of the OpenFluidWamer operating procedure. 

    The first step of the operating procedure is to determine which operational parameters to use during device operation. The current approach is to have the operator use lookup tables in the user manual (or perhaps on a laminated sheet attached to the device) to determine the appropriate operational parameters. The images that follow are the proposed format for these lookup tables.

    You may notice that there is currently only one entry in the IV Tube Immersion Length column. This one entry represents the only test conditions that the Gen 2 prototype has been tested to so far. It also represents one of the most challenging thermal performance test cases. Consequently, almost all other test conditions in the table will require that a shorter length of IV tubing be immersed to achieve the 38°C outlet temperature at the 70°C water bath temperature. All the "??" entries represent tests that will be performed in the coming weeks to complete the table.

    It is also important to note that the current approach uses a constant water bath temperature of 70°C. If the operator needs to change the IV fluid flow rate, the two ways to implement this change with the device is to either change the water set point temperature or change the length of immersed IV tubing. It is less convenient for the operator to change the water bath set point because of how long it will take the sous vide cooker to bring the water bath to the new set point. Instead, changing the length of immersed IV tubing can be done much quicker and will result in an immediate correction to how much heat is being transferred to the IV fluid. 

  • OpenFluidWarmer Gen 2 Prototype

    John Opsahl10/27/2020 at 15:11 0 comments

    After about two and a half weeks of system design and component selections, it was very fun to finally see this second generation come together over the last four days. I started with writing the microcontroller prototype code. Then tested that code with the benchtop prototype and made corrections as needed. Once I was confident in the code, it took only a couple of hours to decide how to arrange the electronic components in the enclosure and put everything together. 

    I intend to cover the details of the operating procedure and how the device works in later project logs, but I think it makes sense to provide a high level overview here. The second generation OpenFluidWarmer uses a commercially available sous vide cooker to warm and maintain the temperature of a water bath. While the IV fluid is being administered, the operator immerses a length of IV tubing in the water bath. Heat from the water bath will warm the IV fluid as it flows through the length of IV tubing that is immersed in the water bath. The custom electronics assembly can be thought of as a "safety companion" for the sous vide cooker. It includes safety protections like redundant temperature monitoring, a sous vide cooker power disconnect, and fault detection and alerts.

    The next step is to develop and perform several tests to ensure that the device operates as intended. 

  • Benchtop Prototype and Operating Logic

    John Opsahl10/21/2020 at 04:58 0 comments

    I assembled the benchtop prototype yesterday in about 20 minutes. I will be using it to test the Arduino code in the coming week. 

    All-in-all, the signals are very simple. Most of the microcontroller inputs and outputs only have two states - "on" or "off". Even for the 4 digit, 7 segment display and the water bath temperature sensors, there are existing code libraries that make controlling or reading from the components easy.

    Five microcontroller inputs:

    • two water bath temperature sensors
    • sous vide cooker power momentary push button
    • set point monitor momentary push button
    • IV tube switch

    Five microcontroller outputs:

    • sous vide cooker power button red LED ring
    • set point monitor button blue LED ring
    • 4 digit, 7 segment display
    • buzzer
    • sous vide cooker power relay

    The challenging part is developing the logic to enforce a conditional operating sequence. Enforcing which and when controls are available to the operator is a strategy to reduce the cognitive load on the operator as well as to prevent the operator from creating a hazardous condition. Ultimately, this approach is used to ensure the safety of the operator and the patient during device operation.

    With the understanding that detailed and easy-to-understand documentation is an important part of open-source design, I have taken the approach of documenting the operating logic in table format. It is something I made up and it does not yet capture all the nuances. I imagine there has to be a better format out there for this type of logic (pseudo code maybe?). Please leave a comment if you have a suggestion.

    The table below details the following statement in Boolean logic: "When the device is plugged in, the sous vide power standby and water bath temperature monitor will be activated." The columns represent only the objects that are effected by the control action. The initial conditions must be satisfied in order for the action to be valid. The final conditions are enforced once a valid control action has occurred.

    In the example above, the descriptive statement provides more clarity than the table. I find that the opposite quickly becomes true when documenting a control action that is dependent on multiple initial conditions and results in a multitude of final conditions.

    It's hard to identify gaps and improve the conditional operating sequence without a good comprehensive format. I know I can just start coding without a solid plan upfront and eventually arrive at the intended operating logic. For the OpenFluidWarmer, the goal is not to just arrive at the intended operating logic but also to justify each line of code and prove that all gaps are closed.

  • Hazard Analysis - risk reduction as-far-as-possible

    John Opsahl10/18/2020 at 05:54 0 comments

    A hazard analysis of the OpenFluidWarmer sous vide cooker design was performed using a reduction as-far-as-possible (AFAP) risk management approach (the latest revision of  the hazard analysis is "OpenFluidWarmer_HazardAnalysis" in the project files). The goal of the hazard analysis is to identify the harms and develop the mitigation controls for each significant hazardous condition that can occur during device operation. EN ISO 14971, an ISO standard detailing the application of risk management to medical devices, was used as a reference to perform the analysis.

    The OpenFluidWarmer hazard analysis identified six hazards (all with multiple potential causes) and four resulting harms. Many risk controls were identified to further reduce the probability of a hazard condition occurring, but none were identified that would reduce the severity of the harm once a hazard condition does occur.

    When following the AFAP approach, risk is to be reduced to the R1 rating (per image above) regardless of economic practicality. In cases where it is not possible to reduce risk to a R1 rating, a risk-benefit analysis is to be performed. The risk-benefit analysis must provide evidence (with no consideration given to economic practicality) that the medical benefits of using the device outweigh the residual risks. 

    The reduction as-far-as-possible risk management approach provides an exciting opportunity to explore the feasibility of electromechanical open-source medical devices like the OpenFluidWarmer. With the number of risk reduction controls required, adherence to AFAP risk reduction presents the most difficult cost challenges for the OpenFluidWarmer design. On the other hand, if it is possible to follow the AFAP risk reduction approach and achieve a low-cost, easy-to-manufacture, component-flexible design, that has huge implications beyond the development of just the OpenFluidWarmer. It means that it may be possible to develop other safe and economically practical open-source medical device designs; some that may even provide more medical benefit to the patient than IV fluid warmers.

  • New Prototype in Development

    John Opsahl10/16/2020 at 20:31 0 comments

    It was decided last week to explore what it would take to develop a safe OpenFluidWarmer design with a sous vide cooker. Testing showed that the constant temperature water bath method with the sous vide cooker was able to meet the thermal performance requirement that the previous two hot plate design could not. Since performance with the sous vide cooker has been so promising, the recent design effort has focused on improving the safety and reliability of the system. The image above is the latest build progress towards the OpenFluidWarmer sous vide cooker prototype.

    The most notable design compromise with the sous vide cooker design is the amount of time it takes for the device to warm up and be ready for use. The two hot plate design could warm up in less than 60 seconds from 25°C to 105°C. Whereas the sous vide cooker design takes about 11.5 minutes to warm the water bath from 25°C to the lower required heater set point temperature of 70°C. It is a little misleading to make this comparison because the two hot plate design was never able to meet the thermal performance requirement at the 105°C set point anyways. 

    At this time, I don't believe a warm up time close to 11.5 minutes to be a significant issue with this warmer. The device could be turned on 10 minutes before the procedure or run continuously during a procedure when need for warming IV fluids was anticipated. Then the IV tubing can be placed into the water bath at a moments notice when warming is needed.

    The sous vide cooker design starts to outshine the two hot plate design when it comes to operational redundancies and simplicity of assembly. The sous vide cooker itself includes an independent power button, temperature controller, and temperature display. The additional system housed in the electronics enclosure (what I am calling the sous vide cooker "safety companion") includes button controls, a sous vide cooker power disconnect, temperature monitoring, and state and fault indicator displays. If for whatever reason the sous vide cooker failed, the "safety companion" system will alert the user and potentially disconnect the power. If the "safety companion" failed, it's very possible that the sous vide cooker will continue to operate as intended without issue. Hardware redundancy really helps to ensure safe operation of the device. On top of that, it's very convenient that a full package, cost-optimized constant temperature bath solution like sous vide cookers are readily available for purchase. All you have to do is supply power to it.

    Instead, the two hot plate architecture only included one microcontroller/control system and no backups if that failed. Adding redundancies to the two hot plate architecture would greatly increase the complexity of the hardware, software, and assembly.

  • Architecture with Sous Vide Revision 1

    John Opsahl10/13/2020 at 04:56 0 comments

    The first design stage of this project was to find a solution that was capable of the required thermal performance. During this stage the sous vide cooker solution was found. The focus of this next design stage is minimizing the number and severity of operator and patient safety hazards as well as minimizing opportunities for human error in the operating procedure.

    The wiring diagram above depicts the first revisions from this second stage design effort. 

    The big changes:

    • No more toggle switches. Toggle switches are no longer used because they maintain state if the operator unplugs the device. So if the power switch was in the "on" state and the device was unplugged and plugged back in, the safety involved with the operator being able to anticipate and be confident in their ability to control the device state is compromised. Momentary push buttons are used instead.
    • Microcontroller is always powered. The microcontroller and associated safety features are always powered whenever the device is plugged in to the AC supply. Ensures that temperature of the water bath is always being monitored and displayed regardless of whether the sous vide device is on or off. 
    • 4 digit, 7 segment display. During normal operation, the water bath temperature will be displayed. When a fault occurs, the display will transition between the water bath temperature and the number and type of fault that is occurring.
    • LED rings on the push buttons instead of independent indicator lights. The "Sous Vide Power" and "Temperature Set" push buttons are the only means to control device state with the microcontroller once the device is plugged in. From a operator perspective, I believe it will be more intuitive that the state indicator lights that change in response to button presses are on the buttons themselves. The "Sous Vide Power" button will use a red ring (implying heater/hot) and the "Temperature Set" button (for setting water bath temperature monitoring) will use a blue ring (implying water bath). 

    The main design challenge I am working through right now is on how to ensure that the operator submerges the correct length of IV tubing and to ensure that it remains submerged throughout operation. 

    Most of the electronic components for this new architecture arrive this week. Hope to have a semi-operational assembly by this weekend.

  • New Architecture with Sous Vide

    John Opsahl10/09/2020 at 03:25 0 comments

    For the new OpenFluidWarmer architecture, the electronics monitor the water bath, alert the user of state and faults, and disconnect the sous vide cooker in the event of a high temperature fault. The new architecture requires fewer electronics components than the previous two hot plate architecture because those components are standard offering in sous vide cookers.

    The idea is to package all the electronics in a single enclosure that will be mounted near the sous vide cooker.

    Theory of operation is as follows:

    1. user plugs in the unit into an AC source. If the power switch is in the "off" position, nothing happens. If the power switch is already in the "on" position, see step 2.
    2. user flips the power switch to the on position. The microcontroller gets powered. If the temperature monitor switch is in the "off" position, the microcontroller commands the relay to close. Closing the relay, provides power to the sous vide cooker. At the same time, the buzzer sounds and yellow LED flashes once a second; indicating that the device is in a warm-up state.
    3. using the controls on the sous vide cooker, the user sets the temperature and starts the device. Temperature is set based on the IV fluid flow rate. The buzzer sounds and yellow LED flashes once a second; indicating that the device is still in a warm-up state.
    4. once the sous vide cooker warms the water bath to the temperature set point, the user flips the temperature monitor switch to the "on" position. The buzzer turns off the and the yellow LED stops flashing. The green LED turns on solid; indicating that the device is warmed up and ready to be used. At this point, the microcontroller will be reading the temperature sensors and ensuring that temperatures do not significantly deviate in either direction starting from the moment that the temperature monitor switch was flipped to the "on" position. 
    5. user submerges the appropriate length of IV tubing in the water bath and starts administering the IV fluid/blood product to the patient. If the temperature measured is too far above the set point, the red LED will flash, the buzzer will sound, the relay will open, and sous vide cooker will no longer receive power. If the temperature measured is too far below the set point, the red LED will flash and buzzer will sound. Then it will be up to the medical professional recognize that there is a fault and either turn off the device or allow it to continue operating. 
    6. user removes the IV tubing from the water bath and flips the power switch to the "off" position when finished.

    Couple of other thoughts:

    • I am thinking of staggering the water bath temperature sensors at different heights in the water bath. Then track the temperature difference between the two sensors. If the temperature difference is too high, that indicates that either the temperature bath is not at a uniform temperature or one of the sensors is out of the water because the water level is too low. At least one water bath temperature sensor should be positioned at either the minimum water level required for the sous vide cooker or minimum water level required to submerge the IV tubing (whichever is greater) to ensure proper water level is maintained. 
    • After writing about many of the fault scenarios above, it's clear to me now that three colored LEDs is not sufficient to effectively communicate device state and faults to the user. Whatever is considered next needs to have more resolution, but also be able to be clearly read/understood from 1.5m away.
    • My intention is to use a Arduino Uno microcontroller instead of the Nano depicted. The 5V pin on the Nano can only supply up to 50mA. Whereas the Uno can supply up to 500mA at the 5V pin. The 5V relay draws about 70mA. I could stay with the Nano if I added another DC-DC step down and tuned it to 5V, but the combined cost of the extra step-down and Nano is more than what I purchase an Uno for. Ideally, I would get rid of the 12V to 9V DC-DC...
    Read more »

View all 35 project logs

  • 1
    Assembly instructions and user manual to follow after safety features of OpenFluidWarmer device have been validated through testing.

View all instructions

Enjoy this project?

Share

Discussions

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 ( https://www.adafruit.com/product/4383 ). 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