• The Decompression Model - Part 1

    Michael • 02/20/2021 at 14:52 • 0 comments

    Pretty much the most important function of a diving computer is the ability for it to monitor all factors on a dive that will keep its user safe, and one of the most important of those is the build-up of nitrogen and helium due to pressure at depth. In other words, the decompression model.

    A very common way for new divers to ensure that they are diving safely are dive tables. They allow a diver to first select a depth and will then show a maximum allowed dive time. When performing multiple dives the depth can be combined with a time to track nitrogen/helium intake over the dive and inform any restrictions that may impose on future dives. Tables are, by there very nature, very conservative, in most cases only allowing the diver to plan for a single depth. They will use what is referred to as a square profile, where the diver descends immediately to their maximum depth and stays there until ascending to their first stop. A computer can often allow for the diver to stay longer underwater as it will track their depth as it changes, rather than assume they are always at the maximum. When a diver is shallower they will be taking on less nitrogen/helium, and in some cases may even be lowering the saturation in their tissues, known as off-gassing.

    When looking at how decompression obligations can be tracked, there are two main (open source) algorithms that dive computers use. The first and I believe most common is the Baulmann gradient factor algorithm which breaks the body down into a series of compartments and tracks tissue pressures in each one. The second is the variable permeability model (VPM), specifically VPM-B, which tracks the growth and pressure of a bubble in each compartment.

    Due to my own experiences, I will first be implementing the Baulmann model and will cover both the details of the model and how I have implemented it in a later post.

  • Working with the MS5803 Pressure Sensor

    Michael • 02/12/2021 at 13:21 • 0 comments

    One of the most important parts of a dive computer is the pressure sensor, it is what is used to calculate the depth you are at, and without it, calculating decompression would not be possible.

    During my research, I found two common sensors that seemed appropriate for the task, the MS5541 and the MS5803 (the 14Bar version of both). There were two reasons why I choose the MS5803, the first of which was the communication protocol. The MS5541 would have required an SPI 4 wire interface dedicated to it, it would not be able to share it with another, while the MS5803 can be used via I2C, requiring only 2 wires that could be combined with other devices if needed. The second reason was board availability, Sparkfun has created a breakout for the MS5803 which is widely available and well document making it both ideal for prototyping as well as potential use in a custom PCB.

    While this board is well documented, the code is intended for an Arduino and so is written in c, rather than in the micropython that I am using. This meant either finding other code or writing my own driver. I was not able to find other code that I was completely happy with, and so via a combined process of reading the datasheet and referencing the Arduino code I have created a driver that can be found here: https://github.com/minyiky/ms5803-micropython

    As part of this, I have included a couple of unit conversion functions that may be of use to some, although I may remove them in the dive computer to save on RAM usage. 

  • Potential Hardware Changes

    Michael • 02/11/2021 at 13:19 • 0 comments

    As of the time of writing I am currently using a:

    • Dfrobot Firebeetle esp32 board
    • Adafruit 320x240 TFT LCD w/ ILI9341 driver
    • Sparkfun MS5803-14BA breakout

    These were the initial items I purchased but I am reviewing where they should be changed.

    MCU

    I am currently using the esp32 which has 512kb of RAM along with WIFI and BLE 4.0 to allow for communication while still enclosed and watertight.

    As alternatives I am considering:

    • STM32L4R9XXX

    This seems to be a very powerful chip and even has MIPI DSI inbuilt. However, I have not been able to find any small boards using this so it would require a fully custom PCB which would take a long time to develop the skills for. Additionally, the STM32 does not have any wireless capabilities built-in, requiring a separate chip to handle that.

    • nrf52840

    There are a lot of boards developed around this, and it appears to have been used in smartwatches, proving its capability. It looks to support pow power modes, which are very important for long-term battery operation, and BLE 4.0 which is likely the more useful protocol out of BLE and wifi.

    • RP2040

    This is a very new chip and so I don't know much about it yet but it seems capable of some very impressive things such as outputting 480p @ 60hz over DVI. The main concern is that it does not natively support wireless, and I am yet to see any long term low power tests as current low power modes do not seem suitable for long term sleep.

    As a final option, I will be keeping my eye on the esp32-3 to see how that develops and when boards start to become available.

    MCU Board

    I am currently using the firebeetle ESP32 with 512kb of RAM, onboard LIPO charging circuitry, a deep sleep current of 80 uA, and measures 58x29mm.

    As an alternative, I am looking at the TinyPico (Nano) as they are smaller boards and look to support a lower deep sleep current, vital for times when there are long periods between dives. The advantage of the TinyPico is that the pins for a standard header making it easy to prototype / solder to as a standalone unit, although it does have fewer pins broken out than the fire beetle board.  In contrast, the TinyPico nano is even smaller and has more pins broken out than even the fire beetle board. The problem with it is that the pins are not in a breadboard format making soldering and prototyping that bit more difficult.

    Display

    I am currently using an Adafruit 320x240 TFT LCD w/ ILI9341 driver.

    I am looking at the alternative of using a Waveshare 2.4inch 320x240 IPS LCD with an ST7899 diver. This has the advantage of both having a better viewing angle due to being IPS rather than TFT, along with having a driver capable of faster speeds.