Import, Export and Synchronization via Cloud Services (including iCloud Drive) in Dive Log on iOS.
(Some detailed background and analysis)
The most resent version of Dive Log for iOS (2.3, release July 2017) adds support for Importing, Exporting and Synchronizing logbook data via Cloud services such as iCloud Drive, Dropbox, GoogleDrive, OneDrive and Box. This new support depends on an iOS feature called “File Provider Extensions” and may require a bit more explanation to fully take advantage of the capabilities. It is also important to understand that this support is different from the “iCloud Synchronization” that has been available in Dive Log on iOS for a number of years.
The existing “iCloud Synchronization” has been relabeled “iOS iCloud Synchronization”. This is exactly the same as what you may have been using for some time now and has no other changes. This feature can use iCloud Drive OR the older iCloud Documents & Data service depending on how your Apple ID is configured. However, when iCloud Drive is used as the underlying file mechanism you will not be able to see these files except from within Dive Log on iOS devices signed in with your Apple ID. These files are stored in a private area of iCloud Drive (or Documents & Data if you are still using that service) and due to Apple’s security mechanisms can not be exposed in any other way.
The new features added in the 2.3 release of Dive Log allows you to expose your logbook data via iCloud Drive (or other File Provider Extensions installed on your device) so that you can exchange those files with other devices and potentially other users.
By default, most iOS devices are configured to support iCloud Drive (it is possible to turn this off so if you do not have iCloud Drive available you should look in your device’s settings under iCloud to enable it). If you want to use any of the other Cloud services that have File Provider Extension support, all you need to do is install the app from that service (Dropbox, GoogleDrive, Box, OneDrive, etc.) on your device. If the service implements the File Provider Extension, then it will (or should be) available from within Dive Log. Note that all File Provider Extension implementations are not created equally and do not necessarily support all the possible modes that Dive Log can take advantage of. Further, some of the implementations have significant bugs that can cause them to not work properly. However, the advantage to using the File Provider Extension support from within Dive Log is that as these 3rd party implementations increase and improve, Dive Log will automatically be able to take advantage of the improvements without us issuing a new version of Dive Log.
Not surprisingly, the best implementation of the File Provider Extension is iCloud Drive itself. So for the best experience, it is suggested that you use iCloud Drive to store and interact with your logbook files. That said, the other services do work as well and I’ll detail the limitations later in this post.
In general, this new support includes the ability to:
- Export complete Dive Log format logbooks and DAN DL7 format files,
- Import a Dive Log formatted logbook (either replacing the active logbook or possibly merging chnages into the active logbook if the remote Dive Log formatted logbook shares an ancestry with the active logbook) and Import dives from a DAN DL7 formatted file into the active logbook,
- Synchronize the active logbook with the selected remote Dive Log formatted logbook file (provided that it shares a common ancestry)
via installed “File Provider Extensions”. This will enable you to interact with the Cloud Synchronization features in DiveLogDT or Dive Log Manager on the Mac as well as with Diving Log 6.0 on a Windows PC via the supported Cloud services as well as exchange files between iOS devices. One thing to keep in mind though is that synchronizing data via this mechanism (vs using the WiFi Synchronization support) does require internet access and will not work until both devices can interact with the internet.
In order to synchronize between Dive Log on iOS and Dive Log on other iOS devices or applications on Macs or PCs you generally need to follow these steps:
- Upload an initial copy of the logbook to the Cloud service (in Dive Log this is accomplished via the new “Export” feature. You would typically start with the device that has your most complete logbook as you will be using this as the basis for all future logbooks.
- Load that initial logbook from the Cloud service onto the other devices that want to participate in Synchronization (in Dive Log this would be accomplished via the new “Import” feature.
- As you make changes on any device, Synchronize those changes with the copy of the logbook in the Cloud service, and then synchronize each device in turn with that logbook in the Cloud service (in Dive Log this is accomplished using the “Synchronize Dive Log Logbook” feature).
When you Synchronize logbooks via this mechanism, Dive Log will work with the File Provider Extension to resolve any conflicts *IF* the File Provider Extension supports conflict resolution (as of right now, iCloud Drive is the only service that exposes conflict files to Dive Log to be resolved). Conflicts can arise when data is sent to the server from multiple devices or if the internet was not available at the time a file was submitted. Other services use other mechanisms local to their servers to resolve conflict … this usually means that they “pick the winner” based on some timestamp mechanism and Dive Log only ever sees this “winner” so no record by record conflict resolution is possible). Also, not all services implement the features required to support this bi-directional synchronization.
The File Provider Extension provides for two types of services: “Copy” and “Open”. In the case of “Copy”, the requesting app (Dive Log in this case) is provided a “Copy” of the Cloud file to work with but can not write the remote version of the file. Dropbox, for example, only supports the “Copy” service so it is not possible to do the bi-directional synchronization with Dropbox using a single file (note you can “Import with Sync” and then “Export” the resulting logbook file back to Dropbox to get a similar effect but it will not be able to replace the existing file in Dropbox unless you delete it first). In the case of “Open”, Dive Log is given access to a writable copy of the remote file so that it can upload any changes that it makes via the Synchronization process. This service is supported by iCloud Drive, Box, OneDrive and GoogleDrive *BUT*, as things currently stand, only iCloud Drive and Box implement this service without bugs (this can change with each update to the File Provider Extension apps so you may find that other services start working properly in the future).
In summary, as things stand as of this writing:
- iCloud Drive supports “Copy” and “Open” semantics. Conflict resolution is supported.
- Box supports “Copy” and “Open” semantics. Conflict resolution is done before Dive Log gets access to the file so no conflict resolution is done by Dive Log.
- OneDrive supports “Copy” and “Open” semantics. No conflict resolution is available to Dive Log and bugs may prevent the remote file from being updated.
- Google Drive supports “Copy” semantics and reports that it supports “Open” semantics, but bugs in their implementation prevent synchronization from working properly (Import works with some limitations and Export seems to work).
- Dropbox only support “Copy” semantics so Import and Export both are available but not Synchronization.
Hopefully this provides some background to help you take advantage of the new facilities. You can (and should) make backups of your logbooks before doing any synchronization operations. Dive Log will maintain the most recent logbook that was in place before an operation locally so that you can revert to it if needed. You can also use the “Export” feature to make a backup of any Dive Log logbook and you can use the Cloud service provider (i.e. File Provider Extension) apps to make backups of your files in their respective services.
On the Environment tab, if all of the required information about your tank is filled in, you can get a SAC Rate (RMV) over the length of the dive as shown in the photo above. If you only used one tank over the course of your dive, then the SAC rate for this tank will also be for the whole dive. Unless you're doing some technical multi tank diving, this is the case for most people.
Dive Log, Dive Log Manager, and DiveLogDT all use the Respiratory Minute Volume (RMV) method of calculating your SAC rate so that you can compare your rate over *all* your dives, regardless of which tank (size) you used. This is the volume of gas you breathed in 1 minute at the surface. If you use Imperial units, it will be "cubic feet per minute", and if you use metric units, it will be in "liters per minute". You can use this number to plan a future dive, regardless of what kind or size of tank you will use.
If you want to take a "deep dive" into analyzing your SAC rate for a particular dive, you can do this on the profile tab. (This assumes you have a dive computer that logs your tank pressure over the course of your dive).
In the image above, we're looking at the same dive as the first image, however we're looking at just a portion of it. By "clicking (and holding) and dragging" over the time axis of the graph, you can select a *portion* of time and find out what your average depth was for that portion, and what your average RMV rate was for just that portion.
From the images, we can see that Jane Diver had an average RMV rate over the course of the whole dive of 0.34 ft3/min and an Average Depth of 47 ft. But in the second image, while starting her ascent at the end of the dive, she had an average RMV rate of 0.26 ft3/min while still maintaining the same Average Depth. Apparently she was much more mellow on her way back!
When clicking and dragging, you can look at the "Time" value at the top of the profile to determine exactly what portion you are looking at. It will change when you click, and update when you drag, so that if you want to know exactly the period of time you're analyzing, you can.
We have had some requests from customers to show a different kind of SAC rate calculation, sometimes called "Surface Gas Consumption". This is an absolute measure of gas over time, and is only useful when using the same kind and size of cylinder over subsequent dives. It is simply the amount of gas you have used in a period of time, adjusted to the surface pressure. Again, if you're using Imperial measurements, this number will be in "psi per minute", and if you're using Metric units, it will be in "bar per minute". We have added an Application Preference to toggle between the two kinds of SAC measurements. If you open the Preferences Window, navigate to the Profile tab, you will see a checkbox at the bottom "Calculate SAC (not RMV)". If this is checked, you will instead see a "SAC" rate when selecting a portion of the dive as above. The image below will show SAC rate using Metric units.
Happy Analyzing! Happy Diving!
You can "Quick Add" any of the dropdowns on the Detail tab of a dive. Just type in the name and tab to the next thing. If that name doesn't already exist in the list of those items, you'll get a small bubble window telling you that the new item has just been added. This works for Site, City, Country, Shop, and Trip.
When there is a list of items that can be added, you can also add a new one by clicking on the "plus" sign in the upper corner. Once clicked, you'll get a popup window you can just start typing in. Hit return and the new list item has been added and you can continue logging. This works for Buddies, Dive Types, and Equipment.
Happy Diving! (and Dive Logging!)
The Vyper Novo and the Zoop Novo use the “DCbuddy - Suunto D” connectors rather than the “DCbuddy - Suunto Z” connectors used by previous Vyper and Zoop models. If you already have a DCbuddy and just require just the pigtail connector those are available from the DiveNav Inc. website (https://www.divenavstore.com/interfaces).
Dive Log also recently added support for the Oceanic DataMask and the Aeris CompuMask. These computers use the "DCbuddy - Pelagic V” connectors.
If you’re downloading your “later generation” UWatec dive computer, and you’re getting the wrong start time for your dive, you're going to want to read and understand these details. If you’re just interested in more detailed information about using your dive computer, this might be interesting.
Your UWatec dive computer keeps track of time using “Coordinated Universal Time” or UTC. It is the primary standard by which the world regulates clocks and time. It is similar to, but not exactly the same as, “Greenwich Mean Time” (GMT). GMT is a time zone whereas UTC is a time standard. No country uses UTC as a local time, but some use GMT as their local time zone. The “UTC time” is the same everywhere in the world. It is the same everywhere in the world at the same time.
Once you have agreed what UTC is, then the local time where you are is measured as an “offset” from UTC. The offset can be either a positive number, or a negative number. On the day of this blog post, Belgium has a UTC Offset of +1:00. The Pacific coast of the USA has a UTC offset of -8:00. This is very similar to saying that your time zone is +1 from GMT or -8 from GMT, it just formalizes and standardizes the language. Your Mac also uses this concept to determine what time it is. When you travel with your Mac to a new place, you don’t go in and change the time, you just change the time *zone* to match and then your Mac knows what the local time is.
When you are setting the time on your UWatec, your instructions show you how to set both the time of day and the UTC offset. The idea is that when you travel to another time zone to dive, you simply change the UTC offset to match where you are now diving. This UTC offset is saved along with all the other information specific to a given dive so that it knows what time it was when you did the dive, even if you change time zones again after the dive. (Otherwise the start time of an “old” dive would change when you changed the current time zone or UTC offset setting).
Now that you have all that terminology, follow along here and see how the “time of day” on your dive computer can look right, but actually be wrong.
I’ll use the Pacific coast of the USA as an example because it has a large difference from UTC. Let’s say you don’t bother setting the UTC offset on the dive computer (so it’s set to 0), and you just set the time of day to be “right”. What you’ve just done is (re)set the dive computers version of the UTC value to be 8 hours wrong. Even though the dive computers time of day always matches what is shown on the wall clocks around you, when you download it, the logbook software will read a dive and see, “oh look, the UTC offset for that dive was zero”. I’ll just “add zero” to the current UTC value given to me by the *Mac* and that will give me the start time of the dive. Using actual numbers, let’s say your dive computer says 09:00 when you start a dive. In UTC time, that’s actually 17:00. When downloaded, the start time of that dive will be calculated as “+0” from UTC or 17:00. Not really what you wanted. When you look up the start time of the dive on the UWatec though, it will show what you really want to see, which is 9:00. Looks right, technically wrong.
What the UWatec instructions don’t really tell you is that you should find out what your UTC offset is where you are, and set that FIRST. And then go in and adjust the time of day if you need to. In the example above, the diver should first set the UTC offset to -8:00 and then set the time of day to be correct, if necessary. This will set the correct UTC value for the UWatec. Then when the software downloads the dive information, it says “oh look, the UTC Offset of this dive is -8, therefore the start time is 17:00 minus 8 hours or 09:00”.
When you buy a brand new “out of the box” UWatec Galileo, it seems likely that the UTC value is already set and already set correctly. Having never bought a new one myself, I can’t say for sure.
When traveling, you can also look up and set the UTC offset before you leave. If you’re heading off to Bonaire on a dive trip, they are “UTC -4:00” right now. So set the UTC offset to -4:00 before you leave and you’ll know that your dive computer will have the right time of day for when you arrive and start diving. (And yes, we’ve all jumped in the water on our first dive of the trip and realized that we’ve forgotten to set the right time on our dive computer!)
As an UWatec user, you’ll notice that there is no Daylight Savings setting or option on the dive computer. This is probably a good thing. The Daylight Savings rules world wide are varied and complicated and close to impossible to keep track of. If you’re in a place that observes daylight savings time, you’ll want to simply adjust your UTC offset. If you’re in Belgium in the summer time, you’re now “UTC +2:00”. If you’re on the Pacific coast of the USA, you’re now “UTC -7:00”. Your Mac has all the daylight savings rules built into it so you don’t have to tell it. But your dive computer has better things to do so you must tell it manually. Daylight savings is just a 1 hour change to the UTC offset.
This is actually a nice feature of these dive computers. But as it is with many things, it needs to be used properly or it may cause some headaches. If you have a bunch of dives on your UWatec that have the “wrong” time, Dive Log Manager/DiveLogDT has a special “switch” that will instead use your Mac’s time zone setting instead of the UTC offset when calculating the start time of the dive. Contact us on our support email address and we’ll give you directions.
Happy Diving and remember - "We've all got time enough to dive"!