Re: RATIO iX3M DEEP computers compatibility and connection/configuration problem

[Dirk Hohndel]

> On Aug 22, 2017, at 7:55 AM, Jef Driesen  wrote:
> I don't understand what you gain with those comments. I mean it's just 
> comments. Don't you need this kind of info at runtime instead?

Yup - I simply have a tool that parses the source to give me the information 
that I want.

> Something like what I proposed for the I/O refactoring:
> 
> For the I/O refactoring, I'm already planning to add an extra field with the 
> transport type. Since some devices support multiple transports, the transport 
> type will need to change into a bitfield. So something like this:
> 
> {"Shearwater", "Petrel 2",  DC_FAMILY_SHEARWATER_PETREL, 4,
> DC_TRANSPORT_SERIAL | DC_TRANSPORT_BLUETOOTH | DC_TRANSPORT_BLE},

Which doesn't tell me if this is an FTDI chip - which is one of the things that 
I need to know.

/D
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Bluetooth / BLE failing with Shearwater Petrel 2 on mobile and desktop

[Rick Walsh]

Hi,

After nearly three months of terrible sea conditions near home, I managed
some data collection a couple of days ago.  On trying to download to my
phone (Galaxy S7) running Subsurface-mobile 4.6.4.734 (Dirk's build), it
fails.  The log includes:

"13.963: DCDownloadThread started for Petrel 2 on LE:00:13:43:0E:6B:D0"
Starting download from  BT
Starting the thread 0
Creating Android Central/Client support for BTLE
qt_ble_open( 00:13:43:0E:6B:D0 )
Connection updated: error: QLowEnergyController::Error(NoError) oldState:
QLowEnergyController::ControllerState(ConnectingState) newState:
QLowEnergyController::ControllerState(ConnectedState)
connected to the controller for device 00:13:43:0E:6B:D0
  .. discovering services
Service discovery initiated
Found service "{1800--1000-8000-00805f9b34fb}"
 .. ignoring standard service
Found service "{180a--1000-8000-00805f9b34fb}"
 .. ignoring standard service
Found service "{fe25c237-0ece-443c-b0aa-e02033e7029d}"
 .. created service object QLowEnergyService(0xc025edc0)
Discovery of "{fe25c237-0ece-443c-b0aa-e02033e7029d}" started
Service "fe25c237-0ece-443c-b0aa-e02033e7029d" discovered (start: 9 end: 9
) QLowEnergyServicePrivate(0xc03fd500)
 .. done discovering services
 .. discovering details
 .. enabling notifications
Finishing the thread Dive data import error dives downloaded 0
no new dives downloaded
"14.622: DCDownloadThread finished"

Previously (at some time between late May and July) I had been able to
download from my Petrel 2, but only using regular (non-BLE) Bluetooth.
Since then I updated the firmware to v44 (I think it was v37 before - in
any case before Shearwater released their cloud mobile app).

I'm not sure if the change to being able to download is due to subsurface,
libdivecomputer, or the firmware.  In any case, we should support the
current firmware.

Downloading to my desktop (v4.6.4-737-g5de49401c89c, built with Qt5.7.1 on
Fedora 26) also fails now.  From the command line:

build with Qt Version 5.7.1, runtime from Qt Version 5.7.1
qt.bluetooth.bluez: Bluez 5 detected.
qt.bluetooth.bluez: Creating QtBluezDiscoveryManager
qt.bluetooth.bluez: Discovered:  "00:13:43:0E:6B:D0" "Petrel" Num UUIDs 3
total device 0 cached RSSI 0 Class 0
qt.bluetooth.bluez: Updating RSSI for "00:13:43:0E:6B:D0" QVariant(short,
-59)
qt.bluetooth.bluez: void QBluetoothDeviceDiscoveryAgentPrivate::stop()

INFO: FTDI disabled
qt.bluetooth.bluez: No settings found for peer device.
qt.bluetooth.bluez: HCI event triggered, type: e
qt.bluetooth.bluez: HCI event triggered, type: e
[12.217318] ERROR: Failed to open the serial port. [in
../../src/shearwater_common.c:46 (shearwater_common_open)]
INFO: dc_deveice_open error value of -6

>From the libdivecomputer log:
INFO: Open: name=LE:00:13:43:0E:6B:D0
ERROR: Failed to open the serial port. [in ../../src/shearwater_common.c:46
(shearwater_common_open)]

Does anyone have any clue how to fix this?

Thanks,

Rick
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Statistics

[Davide DB]

Despite of huge Tomaz effort (thanks Tomaz) IMHO from usability and
readability pov this layout is poor. It works only on hi dpi screens.
Of course stats are better than nothing. So thank you again.

davide@mobile

On Aug 22, 2017 12:24, "Willem Ferguson" 
wrote:

> On 21/08/2017 18:18, Tomaz Canabrava wrote:
>
>
> Willem,
>
> See if this image is better.
>
> Got this, thank you very much. It looks extremely promising: the
> presentation style looks extremely acceptable.
>
> A few questions and comments.
>
> Question 1. Beneath each blue bar for Depth and Temperature is a thin
> (grey?) horizontal line. What does this indicate? For temperature it always
> corresponds to a value of zero °C. For Depth it corresponds to a value of
> between 0 and 15.
>
> Question 2. The vertical positions of the blue bars in each column, what
> do they signify? For instance, the leftmost bar for temperature (a trip to
> Hoodsport) indicates around 45 (°F ?? = ~7 °C??), but the next blue bar (a
> trip to Maui) indicates 80 (~28 °C ??). Please clarify?(by the way, there
> is an unlabled bar on the extreme left, to the left of the first Hoodsport
> trip. Maybe there was a trip to a site where no locality has been
> defined??). So it may be that the blue vertical bar indicates the minimum
> and the maximum values for a specific trip?? If so, the values for SAC look
> realistic if the measurement unit is l/min. The temperatures looks
> realistic if the measurement unit is °F. The depth values look realistic if
> the measurement unit is m (except that six dive trips have a minimum dive
> depth of zero).
>
> Comment 1. For this type of graph, it is critical that the calculations
> are done for a *selected set of dives* (i.e. those that have been selected
> directly from the dive list or through the filter tool). I see the tab for
> "Trips" is highlighted here, meaning the graphs are done for *trips* (i.e.
> the leftmost bar indicates a *trip* to Hoodsport). It would be very
> valuable to include the number of dives in brackets after the name of the
> trip, e.g. the trip to Hoodsport may be indicated as *Hoodsport, WA, USA
> (6)*. The six in brackets would indicates that this trip comprised six
> dives and that the leftmost bar for Hoodsport summarises six dives.
>
> Comment 2. In a statistics panel is would be proper to indicate the
> measurement units (e.g. C or °F for temperature and m/ft for depth and
> l/min or ft3/min for SAC.
>
> Comment 3. As Davide has argued, there is no reason to keep the depth
> profile while showing statistics, because the depth profile has nothing to
> do with the statistics being shown. On the other hand, since the dive list
> shows which dives or trips have been selected and the map shows all dives
> in an area, one could argue that these panels have some relevance to the
> statistics being shown. Admitting that I know nothing of what the Qt/QML
> implications may be, there is therefore no reason why the statistics panel
> may not be extended to the right to cover the profile panel as well.
>
> Comment 4. For long trip names it is probably useful if only the first
> 15-20 characters of a trip or dive site name is used, otherwise the
> vertical space for creating graphs becomes very small. My own dive
> localities have rather long names.
>
> Comment 5. It might enhance the readability of the graphs if, across the
> panel, there are horizontal light grey lines that correspond to every 10
> units on the vertical axis. This would allow easier interpretation of bars
> located towards the right hand side of the panel.
>
> I hope you find this helpful. Thank you for your time and perseverance in
> doing this. This is going to be a very nice feature.
>
> Kind regards,
> willem
>
> ___
> subsurface mailing list
> subsurface@subsurface-divelog.org
> http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
>
>
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: RATIO iX3M DEEP computers compatibility and connection/configuration problem

[Jef Driesen]

On 2017-08-22 05:29, Gregory Sin wrote:

Please find testing result and files/log/screens below.

DC: iX3M DEEP (Os 4.0.26/013). Clean DC, no dives logged.
Mac:10.12.4
SUBSURF:4.6.4.737
BT: Only DC and Mouse are paired, but only DC connected.

No errors reported.
Can we carefully conclude that BT comm works? ;)
I will be try same DC with dives/log after one week and revert.
Sorry, we have 3 Ratio DC here, but all pristine new w/o dives.


The last error in the logfile:

ERROR: Received NAK packet with error code 58. [in 
../../src/divesystem_idive.c:348 (divesystem_idive_packet)]


might be a bit misleading. Error code 58 means that the dive computers 
contains no dives yet. So it's completely harmless and the download was 
completed successfully.


Jef
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: RATIO iX3M DEEP computers compatibility and connection/configuration problem

[Jef Driesen]

On 2017-08-21 16:51, Dirk Hohndel wrote:

BTW: I have added some annotation in the Subsurface-branch to help us
decide which dive computers to offer as choices on mobile devices
(this is in src/descriptor.c):

[...]

This basically just adds a comment at the end of every line that
follows a strict syntax: two slashes, one space, then a token. There
can be more than one such comment, e.g.:

/* Shearwater Petrel family */
{"Shearwater", "Petrel",DC_FAMILY_SHEARWATER_PETREL, 3},
// BT // BLE
{"Shearwater", "Petrel 2",  DC_FAMILY_SHEARWATER_PETREL, 4},
// BT // BLE
{"Shearwater", "Nerd",  DC_FAMILY_SHEARWATER_PETREL, 5},  
// BT

{"Shearwater", "Perdix",DC_FAMILY_SHEARWATER_PETREL, 6},
// BT // BLE
{"Shearwater", "Perdix AI", DC_FAMILY_SHEARWATER_PETREL, 7},  
// BLE


(yes, I know this looks wrong, as the Petrel has no BLE version, but
the Petrel 2 unfortunately identifies itself as Petrel).

Would you be willing to take a patch that adds this for
libdivecomputer master? This would make our lives easier and it
certainly shouldn't cause any problems on your end as this is all just
comments...
Please let me know and I'll be happy to submit one clean patch to just 
add that.


I don't understand what you gain with those comments. I mean it's just 
comments. Don't you need this kind of info at runtime instead? Something 
like what I proposed for the I/O refactoring:


For the I/O refactoring, I'm already planning to add an extra field with 
the transport type. Since some devices support multiple transports, the 
transport type will need to change into a bitfield. So something like 
this:


{"Shearwater", "Petrel 2",  DC_FAMILY_SHEARWATER_PETREL, 4,
DC_TRANSPORT_SERIAL | DC_TRANSPORT_BLUETOOTH | DC_TRANSPORT_BLE},

With this information, an application knows exactly which transport 
types are supported for each device, and can setup the appropriate I/O 
channel (built-in or custom implementation).


To find out what goes wrong, you'll need to enable the libdivecomputer 
logfile checkbox. Without the logfile, we have no idea where exactly 
it goes wrong. Screenshots are useless because they don't give the 
low-level detailed info.


I keep wanting to improve the error messages that we are able to give
- right now the useless default error that implies incorrect
permissions does a lot more harm than anything else. I just can't seem
to find the time with all the other things on my plate. A feeling that
I know you are well familiar with, Jef.

But until then, the libdivecomputer log file certainly is the correct
next step. Actually, I might be able to add a quick and dirty change
that suggests this to the user... then at least people using the test
builds would get that hint.


Just an idea: Why not always enable the logfile? Then whenever the 
download fails, you can notify the user about the error as usual, but 
also point to the log file. You probably don't want to show the contents 
of the log, but just the location of the file. That makes it very easy 
to report errors, because all the info is right there. Diving Log does 
something similar, and it works very well.


Jef
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Atmospheric pressure for Ratio iX3M

[Jef Driesen]

On 2017-08-21 23:30, Steve wrote:

On 2017-07-13 10:11, Robert Helling wrote:

we have a user report on the forum that gets incredibly low SAC rates
for dives downloaded from a newly acquired Ratio iX3M. Looking at the
xml I see there surface pressure values of above 9bar. Does anybody
have an idea how those come about? Maybe there is something wrong in
the parser.


According to the documentation, the atmospheric pressure is stored in
millibar. That appears to be correct for the older models (Orca and 
iDive).
But for all the newer models (iX3M) the result is indeed a factor 10 
too
large. Probably a mistake in the documentation (or a bug in the 
firmware).

I'll take care of fixing that.

While you are making the surface pressure change can you also add the 
fixed

set point data.
I am manually adding the initial fixed setpoint ppo2 to the xml file 
and I

also don't think that the setpoint changes get added.
You should have my ix3m-reb data from our last testing that is using 
fixed

setpoint and without.


The atmospheric pressure was already added a few days ago, and I've now 
added the setpoint samples too.


Jef
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Statistics

[Willem Ferguson]

On 21/08/2017 18:18, Tomaz Canabrava wrote:


Willem,

See if this image is better.

Got this, thank you very much. It looks extremely promising: the
presentation style looks extremely acceptable.

A few questions and comments.

Question 1. Beneath each blue bar for Depth and Temperature is a thin
(grey?) horizontal line. What does this indicate? For temperature it always
corresponds to a value of zero °C. For Depth it corresponds to a value of
between 0 and 15.

Question 2. The vertical positions of the blue bars in each column, what do
they signify? For instance, the leftmost bar for temperature (a trip to
Hoodsport) indicates around 45 (°F ?? = ~7 °C??), but the next blue bar (a
trip to Maui) indicates 80 (~28 °C ??). Please clarify?(by the way, there
is an unlabled bar on the extreme left, to the left of the first Hoodsport
trip. Maybe there was a trip to a site where no locality has been
defined??). So it may be that the blue vertical bar indicates the minimum
and the maximum values for a specific trip?? If so, the values for SAC look
realistic if the measurement unit is l/min. The temperatures looks
realistic if the measurement unit is °F. The depth values look realistic if
the measurement unit is m (except that six dive trips have a minimum dive
depth of zero).

Comment 1. For this type of graph, it is critical that the calculations are
done for a *selected set of dives* (i.e. those that have been selected
directly from the dive list or through the filter tool). I see the tab for
"Trips" is highlighted here, meaning the graphs are done for *trips* (i.e.
the leftmost bar indicates a *trip* to Hoodsport). It would be very
valuable to include the number of dives in brackets after the name of the
trip, e.g. the trip to Hoodsport may be indicated as *Hoodsport, WA, USA
(6)*. The six in brackets would indicates that this trip comprised six
dives and that the leftmost bar for Hoodsport summarises six dives.

Comment 2. In a statistics panel is would be proper to indicate the
measurement units (e.g. C or °F for temperature and m/ft for depth and
l/min or ft3/min for SAC.

Comment 3. As Davide has argued, there is no reason to keep the depth
profile while showing statistics, because the depth profile has nothing to
do with the statistics being shown. On the other hand, since the dive list
shows which dives or trips have been selected and the map shows all dives
in an area, one could argue that these panels have some relevance to the
statistics being shown. Admitting that I know nothing of what the Qt/QML
implications may be, there is therefore no reason why the statistics panel
may not be extended to the right to cover the profile panel as well.

Comment 4. For long trip names it is probably useful if only the first
15-20 characters of a trip or dive site name is used, otherwise the
vertical space for creating graphs becomes very small. My own dive
localities have rather long names.

Comment 5. It might enhance the readability of the graphs if, across the
panel, there are horizontal light grey lines that correspond to every 10
units on the vertical axis. This would allow easier interpretation of bars
located towards the right hand side of the panel.

I hope you find this helpful. Thank you for your time and perseverance in
doing this. This is going to be a very nice feature.

Kind regards,
willem
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface