Open Source Dive Computer

[vam]

Create a small device that allows to read out non-bluetooth LE dive computers with a phone (in particular iOS)

Sorry, not my itch. My Perdixes sync great with my iPhone. Honestly, I don't really have enough time to be very involved anyway. Definitely interested though. I understand the casing being a big challenge. I was thinking about starting with something like a camera housing and attaching the pressure sensor with epoxy.

I love the buttons on the Perdix and would love to achieve something like that. I figure they must be pressure sensors themselves that look for pressure above ambient when they're pressed, but I really don't know how they work.

I'm really more of a software than hardware guy myself too, so I'm out of my depth with that stuff. It wouldn't stop me from playing though.

 

[kelemvor]

Nope. Discord is the new real time chat lol

Chat software comes and goes, but so far none that I've seen are superior to IRC.

 

[KeithG]

...The challenging part is to come up with a box that can withstand the pressure while exposing the pressure sensor to the outside. Once you manage that, you can start worrying about the electronics and the programming...

Agreed. But enclosure design is something you should step back and think about a bit as it may affect some of your other design choices.

The most reliable enclosure is one that does not have any holes through it. No holes, no leaks.

The simplest pressure resistant enclosure is a zip lock baggy filled with mineral oil. Enclosures do not need to be pressure resistant if they are not compressible.

I claim it is worth taking a look at the enclosure design of the Uwatec Aladin computers. Later models even incorporated a "buttonless" switch that is used to turn the screen backlight on (you simply squeeze the computer).

 

[KenGordon]

They're using the MPLAB-X IDE and have straightforward instructions to setup the development environment.

They appear to be using this chip in the OSTC3 dive computer: PIC18F87K22

When I realised that I dropped the idea of buying one. I’d not want to be programming one for fun. Proper danger money required.

It turns out that so long as you can get the power modes done properly the CPU is not your problem for batter life. You get got because the pull down resistors are too small, some sensor is always or or stuff like that.

The hassle of doing floating point maths with a low end micro controller is not worth while. If you have to use a 1970s programmng language it Is harder for everyone’s involved and much harder to tell people to bet their lives on the result.

 

[kelemvor]

I got more information from them. The OSTC4 has two processors. Primary is STM32F429 and secondary is STM32F411. They're expecting to release the source for OSTC4 by the end of March.

The C code isn't that bad to work with.

static void calc_tissue(PARAMETER unsigned char period)
{
    assert( 0.00 <= ppN2 && ppN2 < 11.2 );  // 80% N2 at 130m
    assert( 0.00 <= ppHe && ppHe < 12.6 );  // 90% He at 130m

    for (ci=0;ci<NUM_COMP;ci++)
    {
        read_buhlmann_times(period);        // 2 sec or 1 min period.

        // N2
        temp_tissue = (ppN2 - pres_tissue_N2[ci]) * var_N2_e;
        temp_tissue_safety();
        pres_tissue_N2[ci] += temp_tissue;

        // He
        temp_tissue = (ppHe - pres_tissue_He[ci]) * var_He_e;
        temp_tissue_safety();
        pres_tissue_He[ci] += temp_tissue;
    }
}

//////////////////////////////////////////////////////////////////////////////
// calc_limit
//
// New in v.111 : separated from calc_tissue(), and depends on GF value.
//
static void calc_limit(void)
{
    char_O_gtissue_no = 255;
    calc_lead_tissue_limit = 0.0;

    for(ci=0; ci<NUM_COMP;ci++)
    {
        overlay float N2 = pres_tissue_N2[ci];
        overlay float He = pres_tissue_He[ci];
        overlay float p = N2 + He;

        read_buhlmann_coefficients();
        var_N2_a = (var_N2_a * N2 + var_He_a * He) / p;
        var_N2_b = (var_N2_b * N2 + var_He_b * He) / p;

        // Apply the Eric Baker's varying gradient factor correction.
        // Note: the correction factor depends both on GF and b,
        //       Actual values are in the 1.5 .. 1.0 range (for a GF=30%),
        //       so that can change who is the leading gas...
        // Note: Also depends of the GF. So the calcul is different for
        //       GF_low, current GF, or GF_high...
        //       *BUT* calc_tissue() is used to compute bottom time,
        //       hence what would happend at surface,
        //       hence at GF_high.
        if( char_I_deco_model != 0 )
            p = ( p - var_N2_a * GF_high) * var_N2_b
              / (GF_high + var_N2_b * (1.0 - GF_high));
        else
            p = (p - var_N2_a) * var_N2_b;
        if( p < 0.0 ) p = 0.0;

        if( p > calc_lead_tissue_limit )
        {
            char_O_gtissue_no = ci;
            calc_lead_tissue_limit = p;
        }
    }

    assert( char_O_gtissue_no < NUM_COMP );
    assert( 0.0 <= calc_lead_tissue_limit && calc_lead_tissue_limit <= 14.0);
}

 

[KenGordon]

I got more information from them. The OSTC4 has two processors. Primary is STM32F429 and secondary is STM32F411. They're expecting to release the source for OSTC4 by the end of March.

The C code isn't that bad to work with.

static void calc_tissue(PARAMETER unsigned char period)
{
    assert( 0.00 <= ppN2 && ppN2 < 11.2 );  // 80% N2 at 130m
    assert( 0.00 <= ppHe && ppHe < 12.6 );  // 90% He at 130m

    for (ci=0;ci<NUM_COMP;ci++)
    {
        read_buhlmann_times(period);        // 2 sec or 1 min period.

        // N2
        temp_tissue = (ppN2 - pres_tissue_N2[ci]) * var_N2_e;
        temp_tissue_safety();
        pres_tissue_N2[ci] += temp_tissue;

        // He
        temp_tissue = (ppHe - pres_tissue_He[ci]) * var_He_e;
        temp_tissue_safety();
        pres_tissue_He[ci] += temp_tissue;
    }
}

//////////////////////////////////////////////////////////////////////////////
// calc_limit
//
// New in v.111 : separated from calc_tissue(), and depends on GF value.
//
static void calc_limit(void)
{
    char_O_gtissue_no = 255;
    calc_lead_tissue_limit = 0.0;

    for(ci=0; ci<NUM_COMP;ci++)
    {
        overlay float N2 = pres_tissue_N2[ci];
        overlay float He = pres_tissue_He[ci];
        overlay float p = N2 + He;

        read_buhlmann_coefficients();
        var_N2_a = (var_N2_a * N2 + var_He_a * He) / p;
        var_N2_b = (var_N2_b * N2 + var_He_b * He) / p;

        // Apply the Eric Baker's varying gradient factor correction.
        // Note: the correction factor depends both on GF and b,
        //       Actual values are in the 1.5 .. 1.0 range (for a GF=30%),
        //       so that can change who is the leading gas...
        // Note: Also depends of the GF. So the calcul is different for
        //       GF_low, current GF, or GF_high...
        //       *BUT* calc_tissue() is used to compute bottom time,
        //       hence what would happend at surface,
        //       hence at GF_high.
        if( char_I_deco_model != 0 )
            p = ( p - var_N2_a * GF_high) * var_N2_b
              / (GF_high + var_N2_b * (1.0 - GF_high));
        else
            p = (p - var_N2_a) * var_N2_b;
        if( p < 0.0 ) p = 0.0;

        if( p > calc_lead_tissue_limit )
        {
            char_O_gtissue_no = ci;
            calc_lead_tissue_limit = p;
        }
    }

    assert( char_O_gtissue_no < NUM_COMP );
    assert( 0.0 <= calc_lead_tissue_limit && calc_lead_tissue_limit <= 14.0);
}

Not bad? Most of the variables are globals. What does ‘overlay’ mean? All those random floating point constants?

 

[Oonej]

Not bad? Most of the variables are globals. What does ‘overlay’ mean? All those random floating point constants?

Simple answer:
The ARM compilation tools provide the minimum support to enable overlays. Overlay regions are specified in the scatter-loading file. When two or more execution regions are marked as OVERLAY in the scatter file, these regions can have the same base address without causing a linker error. The code/data positioned in these regions will be linked to locate at that particular base address.

Also found this:
Overlay (programming) - Wikipedia

Essentially its just a way to make global vars

 

[kelemvor]

Simple answer:
The ARM compilation tools provide the minimum support to enable overlays. Overlay regions are specified in the scatter-loading file. When two or more execution regions are marked as OVERLAY in the scatter file, these regions can have the same base address without causing a linker error. The code/data positioned in these regions will be linked to locate at that particular base address.

Also found this:
Overlay (programming) - Wikipedia

Essentially its just a way to make global vars

All necessary when programming chips with such limited capabilities. Both chips support extended (external) RAM, and I'm not sure what they added on the board yet. OSTC3's chip supports only a max of 2Mb external RAM. The OSTC4's chip has 32 bit external memory addressing so it should be able to directly map 2^32 = 4,294,967,296 bytes 4,294,967,296 / (1,024 x 1,024) = 4,096 MB = 4GB. Still vastly inferior to modern above the surface computers, but it's pretty snazzy for a dive computer in my opinion. Keep in mind clock speed is only 180Mhz on this puppy, so reading 4GB from ram might be somewhat sluggish compared to the 4ghzish speeds we're used to.

There might even be enough capacity to spend on a high level language with the new chip. Since they've already put their time and money into lower level programming it might be a tough sell to do a complete rewrite, and give up the performance benefits just to attract a wider community.

 

[Oonej]

All necessary when programming chips with such limited capabilities. Both chips support extended (external) RAM, and I'm not sure what they added on the board yet. OSTC3's chip supports only a max of 2Mb external RAM. The OSTC4's chip has 32 bit external memory addressing so it should be able to directly map 2^32 = 4,294,967,296 bytes 4,294,967,296 / (1,024 x 1,024) = 4,096 MB = 4GB. Still vastly inferior to modern above the surface computers, but it's pretty snazzy for a dive computer in my opinion. Keep in mind clock speed is only 180Mhz on this puppy, so reading 4GB from ram might be somewhat sluggish compared to the 4ghzish speeds we're used to.

There might even be enough capacity to spend on a high level language with the new chip. Since they've already put their time and money into lower level programming it might be a tough sell to do a complete rewrite, and give up the performance benefits just to attract a wider community.

Makes sense. I personally would much rather write on newer tech. Most of this code is easily convertible to new languages and technologies.

The Arduino Trinket Pro is going into my dive compass i'm making.

Its rather cheap and tinker friendly. Just engineering a case for it is the tough part.

NeoPixel Ring 16 x 5050 RGBW $11.95
Adafruit Trinket - Mini Microcontroller $6.95
Triple-axis Accelerometer+Magnetometer $14.95
Lithium Ion Polymer Battery - 3.7v 500mAh $7.95
5-10 bucks for accessories

Total : < 50 bucks!

 

[KenGordon]

All necessary when programming chips with such limited capabilities. Both chips support extended (external) RAM, and I'm not sure what they added on the board yet. OSTC3's chip supports only a max of 2Mb external RAM. The OSTC4's chip has 32 bit external memory addressing so it should be able to directly map 2^32 = 4,294,967,296 bytes 4,294,967,296 / (1,024 x 1,024) = 4,096 MB = 4GB. Still vastly inferior to modern above the surface computers, but it's pretty snazzy for a dive computer in my opinion. Keep in mind clock speed is only 180Mhz on this puppy, so reading 4GB from ram might be somewhat sluggish compared to the 4ghzish speeds we're used to.

There might even be enough capacity to spend on a high level language with the new chip. Since they've already put their time and money into lower level programming it might be a tough sell to do a complete rewrite, and give up the performance benefits just to attract a wider community.

If you have 2mb of ram and think you need to use anything other than a flat memory space for something this simple you need your head examined.

Limited is a thing like the atmel with 2k of ram and 128k of flash. Then you have to squeeze stuff in. Then every bit is sacred and you do what it takes. You only do that if unit price or power needs swamp development costs.