<div dir="ltr">Steve,<br><div class="gmail_extra"><br><div class="gmail_quote">On 22 June 2015 at 08:48, Steve Butler <span dir="ltr"><<a href="mailto:kg7je@comcast.net" target="_blank">kg7je@comcast.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
  
    
  
  <div bgcolor="#FFFFFF" text="#000000"><span class="">
    On 06/21/2015 03:23 PM, Rick Walsh wrote:<br>
    <blockquote type="cite">
      <p dir="ltr">On 22 Jun 2015 8:16 am, "Steve Butler" <<a href="mailto:kg7je@comcast.net" target="_blank">kg7je@comcast.net</a>>
        wrote:<br>
        ><br>
        > On 06/20/2015 06:25 PM, Rick Walsh wrote:On 21 Jun 2015
        11:19 am, "Dirk Hohndel" <<a href="mailto:dirk@hohndel.org" target="_blank">dirk@hohndel.org</a>> wrote:<br>
        >> >On Sat, Jun 20, 2015 at 11:17:28AM +1000, Rick
        Walsh wrote:<br>
        >> > > But what about me?  I like SI units and whole
        decimals.  Don't worry, 2 s<br>
        >> > > timesteps fit nicely when using 10 m/s ascent
        rate (18 s between stops).<br>
      </p>
    </blockquote></span>
    snip<span class=""><br>
    <blockquote type="cite">
      <p dir="ltr">> Also my DC records every 10s.  One of the DCs
        i'm looking at does 5s intervals.  <br>
        ><br>
        > How would this work comparing the pre-dive plan with the
        post-dive profile?<br>
        ></p>
      <p dir="ltr">The change has nothing to do with setting or limiting
        an ascent rate. Currently the ascent to the next stop is done in
        3 second increments. If you ascend at 30ft/min (Subsurface
        default, which matches most DCs) it should take 20s to ascend
        10ft. But in 3s increments it is bumped out to 21s. No huge
        issue but it makes the calculated plan have some odd runtimes.<br>
      </p>
      <br>
    </blockquote></span>
    So that would be 10 calculations (one every 2s) between stops.  If
    you slid the other way and went every 4s then its 5 calculations up
    to the next stop.  Any concerns with snappiness (performance) on
    slower machines?<br></div></blockquote><div><br></div><div>I have an 8 year old laptop, and calculations appear immediate, so I don't think it's too intensive.  Changing from 3s to 2s means we do 10 calculations rather than 7, which isn't that dramatic.  Changing to 4s is ok for a 30ft (9m) /min ascent rate, but for 20ft (6m) /min ascent (also common), a stop should take 30s but that becomes 32s. 5s is ok for 20ft/min or 30ft/min but isn't good for 5 m/min or 10 m/min.</div><div><br></div><div>You are right, it isn't all that efficient.  I tried setting it to the time it takes to ascend to the next stop (do the ascent in one jump), which I thought should work.  And to quote a great of modern philosophy, "60 percent of the time it worked every time".  Occasionally, it would just break a ceiling.</div><div> </div><div>R</div></div><br></div></div>