Need testers for dive computer downloader

3rd party extensions (phpDivingLog, dive computer downloader,...)
Post Reply
AndyDragon
Posts: 110
Joined: Tue Nov 14, 2006 08:38
Location: Penetanguishene, Ontario
Contact:

Post by AndyDragon »

Graham, there is one other thing I'd like you to do. Can you run PortMon, then OceanLog and then read the PDC settings and then simply write the same settings back out (no changes). Could you send that log to me as well, it would go a long way to helping with the write commands for that model. Thanks.

BTW, I forwarded your information to TnT (Jef) as well...he wrote the 'veo250.exe' downloader, so hopefully he will have something updated soon to allow you to dump the whole memory of the computer.
Andrew Forget
PADI IDC Staff Instructor 212158
alfiejts
Posts: 4
Joined: Sat Jan 17, 2009 16:16

Post by alfiejts »

on its way back Andy by email. I've also tried the test apps for the other Oceanic models just in case the output helps at all by comparing that with the Veo250 app. All are in the email....
AndyDragon
Posts: 110
Joined: Tue Nov 14, 2006 08:38
Location: Penetanguishene, Ontario
Contact:

Post by AndyDragon »

Got it, thanks Graham. This has been a huge help and hopefully we can get this timing issue sorted out.

Still looking for a tester with one of the following computers:

Aeris Atmos 2
Aeris Atmos AI
Aeris Elite
Oceanic Pro Plus 2
Oceanic VersaPro
Oceanic VT Pro
Sherwood Wisdom
Sherwood Wisdom 2
Sherwood InSight

These are different from the VT3/Atom series and the VEO/XR2 series...
Andrew Forget
PADI IDC Staff Instructor 212158
AndyDragon
Posts: 110
Joined: Tue Nov 14, 2006 08:38
Location: Penetanguishene, Ontario
Contact:

Post by AndyDragon »

Add to this list Hollis DG02.
Andrew Forget
PADI IDC Staff Instructor 212158
KCDiver
Posts: 1
Joined: Thu Jan 29, 2009 21:22

Wisdom log file

Post by KCDiver »

sent wisdom logfile from portmon, and the mem dump when i ran the vtpro test app. I can do the same for a wisdom2 and a genesis react and an isight when i see one (could be soon).
AndyDragon
Posts: 110
Joined: Tue Nov 14, 2006 08:38
Location: Penetanguishene, Ontario
Contact:

Post by AndyDragon »

Warren, I posted on the dive computer library site a new application which should be able to download from the React, the Insight and your Wisdom. I'm not sure that it will download from the Wisdom 2 however ... if and when you get a chance, Jef and I would love to see the portmon from SCI to the computer on that one.

You also mentioned some older Oceanic computers ... are they OceanLog/USB computers or older software and serial port?

Thanks for the Wisdom log and dump. It was really helpful having that one.

Quick link to the application is here: http://www.divecomputerlib.com/download ... Dumper.zip

Must be run on Windows with .NET 3.5 installed (WPF).
Andrew Forget
PADI IDC Staff Instructor 212158
bperrybap
Posts: 4
Joined: Sat Jan 20, 2007 20:25
Location: Dallas, Tx USA

Re: Need testers for dive computer downloader

Post by bperrybap »

Andy,
Your dumper application doesn't work on the atmosAI.
It gives up really early during initialization with the error:
"Index was outside the bounds of the array."

Perhaps this is due to init PPS mode returns 14 bytes, while
init MOD mode only returns 13 bytes?


In looking at the messages sent, the application is definitely violating the Pelagic message protocol.
It is slamming out more than one command back to back without waiting for the initial
command to complete. This is not a good thing to be doing. I have seen this cause problems.

After the application sends the "MOD mode init" it slams out 2 "exit download mode" commands.

Here is the thread where I described the necessary commands to initialize the group 1 PDCs.
http://www.divecomputerlib.com/viewtopic.php?f=45&t=51

I would ditch the "exit download commands" as part of the early initialization.
(I don't do them) They are not needed.
In fact if you go back to the early 1.x ACI software prior to 1.5 they were not done.
All they do is force a PDC to exit download mode should it have been left in download mode
from a prior failed download attempt from something like the cable being yanked.
By sending the "exit download mode" commands you force a PDC left in download mode back
to surface mode which cause the retried download operation to fail. The user must then
manually put the PDC back into download mode and retry the entire operation.
If you leave them out and the PDC is still in download mode when the next download
operation is attempted, the "enter download mode" command will
succeed and the PDC will remain in download mode and the retried operation will succeed by
reconnecting to a PDC that is already in download mode.
(I guess I left that off the PDC state diagram, I'll update the PDC state diagram to reflect this).

To me, it makes life easier on the user, because you reconnect to the PDC in download mode
vs forcing the PDC back to surface mode which causes the operation to fail and the necessity
to start the entire operation all over again including setting the PDC to PC countdown mode.


I believe that they were done simply as a matter of convenience in Oceanlog user documentation.
The documentation tells the user to start a download operation by putting the PDC in countdown mode.
When a download fails from a cable being yanked, the PDC is "stuck" in download mode until
it times out after 2 minutes or receive a "exit download" command.
I believe that these "exit download" commands were merely sent to try to start the operation
over from the users perspective because it looks kind of scary that the PDC is stuck in a mode
with all the LCD segments lit up.

In reality, the most important thing to do is to toggle the RTS line which will reset the PIC
so that it is ready to start the initialization process.

But if you do decide you do want send the extra "exit download commands"
you should wait for the "init MOD mode" command to finish and send them one at time
waiting for each command to finish before sending out the next command.
Also keep in mind that the response to the "exit download" command is only 1 byte when the PDC is not attached
or in surface mode vs 2 bytes if the PDC is in countdown mode or download mode.

--- bill
AndyDragon
Posts: 110
Joined: Tue Nov 14, 2006 08:38
Location: Penetanguishene, Ontario
Contact:

Re: Need testers for dive computer downloader

Post by AndyDragon »

The bug is in that code, I had changed most of it from 14 to 13, but for some reason, in the loop, I changed it to 15?!?

I have uploaded an updated copy with the fix. I also removed the two 'exit download mode' commands. However, I think it's a bit far-reaching to say that sending more than one command at a time is 'violating' the protocol. Neither you nor I are privy to the protocol - only PPS is and I was simply doing the same thing OL/ACI/SCI/HCI/GCI all do. They all fire all three commands at the computer at once. While this application is hardly the role model for communication of the protocol, following their example is a prudent course of action since it's written by PPS.

In any case, the updated code is available for download at the same location.
Andrew Forget
PADI IDC Staff Instructor 212158
bperrybap
Posts: 4
Joined: Sat Jan 20, 2007 20:25
Location: Dallas, Tx USA

Re: Need testers for dive computer downloader

Post by bperrybap »

AndyDragon wrote:The bug is in that code, I had changed most of it from 14 to 13, but for some reason, in the loop, I changed it to 15?!?

I have uploaded an updated copy with the fix. I also removed the two 'exit download mode' commands. However, I think it's a bit far-reaching to say that sending more than one command at a time is 'violating' the protocol. Neither you nor I are privy to the protocol - only PPS is and I was simply doing the same thing OL/ACI/SCI/HCI/GCI all do. They all fire all three commands at the computer at once. While this application is hardly the role model for communication of the protocol, following their example is a prudent course of action since it's written by PPS.

In any case, the updated code is available for download at the same location.
Bummer.... Sounds like something goofy I'd do.
I'll try the newer binary.

True, while we don't know the exact protocol, I disagree that in this case it is prudent to model things after what
has been shown and is known to be a broken communication sequence. (back to back commands)
I have done much testing in this area with actual hardware and have posted several times and have pointed out
real examples where not waiting for one command to complete
before sending the next command causes commands to not be processed, lost command responses,
and unpredictable behavior.

In MOD mode, when commands are sent 1 at a time, the PIC *always* returns a status even when a PDC is not attached.
The timing and the number of response bytes will vary from when the PDC is attached and in the proper mode,
but the PIC will always respond to a command.
When multiple commands are sent back to back, behavior will depend on the commands and the actual timing of
how they are actually delivered to the PIC inside the data cable which depends on how the application delivers
the bytes to the driver along with the speed of the host system and how busy the USB bus is with other devices.

If you interrupt a "Calibrate" command on the AtmosAI, with another command, by trying to send back to back commands,
which is easy to accidentally do since this operation takes so long to complete, and you might have timed out
because the wait for the response was too short and you reset the PIC or sent an "exit download" command,
or simply closed the com port, reopened it, and retried the operation, you will lockup/crash the dive computer.
This then requires removal of the battery and then takes 2 battery removal power cycles to get the computer to come
back to life.
I accidentally did this and thought I trashed my computer, so this is why I am so vocal about not doing more
than 1 command at a time.
Sending back to back commands is not necessary, in the worst case can cause big problems, and
I would argue that based on my testing doesn't really work anyway.

So when it can be demonstrated that sending back to back commands without waiting for the previous command
to respond, causes issues like commands being ignored or status responses to be lost, or worst case cause a lockup,
while waiting for appropriate responses from sending commands 1 at a time predictably works with
a status being returned every time,
I would argue that the first method is "violating" the protocol - even though we don't really know
what the protocol is.

The only reason that you might want to send the "exit download" command after the "init MOD" mode
would be to try to detect if the PDC was plugged in and in "PC countdown mode".
The status returned is different if the PDC is in "PC countdown mode" vs no PDC attached or
PDC still in "surface mode".
But in order for it to return proper status, you have to wait until the "init MOD mod" command is
completed, which won't happen if you send back to back commands.
If you post the 2 "exit download" commands back to back directly after the "init MOD mode",
then no status is returned for either command.
(I would also argue that if this option is chosen, that only a single "exit download" is sufficient)


Email me and I can fill you in on the specifics.

--- bill
bperrybap
Posts: 4
Joined: Sat Jan 20, 2007 20:25
Location: Dallas, Tx USA

Re: Need testers for dive computer downloader

Post by bperrybap »

Andy,
The downloader still doesn't work on the AtmosAi. Not sure what you are looking for in response
to the "enter download command". While all the response bytes read look correct,
for some reason the application is breaking up the read into multiple reads requests and is not
happy with the response. Breaking up the read into multiple reads should not be necessary.
Also, when the application gave up it didn't send an "exit download command" to attempt to
return the PDC to surface mode before it closed the port.
This leaves the PDC hung/stuck in download mode with all the LCD segments lit up.
While the PDC would return back to surface mode in 2 minutes on its own,
I think it is good practice to always try to attempt to return the PDC to surface mode
before exiting, even under most error/exception conditions.

This is an example where not sending the "exit download" commands during
initialization can be useful.
I can bring up my application after running yours and re-establish a session to the PDC
(which was left stuck in download mode) and continue a download operation
before returning the PDC back to surface mode. No additional user interaction of button
pushes to put the PDC back into PC countdown mode was necessary.

Email me and we can discuss the details and I can show you the portmon logs of your application
vs my application.

--- bill
AndyDragon
Posts: 110
Joined: Tue Nov 14, 2006 08:38
Location: Penetanguishene, Ontario
Contact:

Re: Need testers for dive computer downloader

Post by AndyDragon »

Updated. New update will record a log for me even on failure. Also, any time there is an abort, I fire a single 'exit computer mode' command at the interface in hopes to not leave the computer in unhappy state. I know that if you hook it up to ACI and read the settings, the computer defaults back to normal mode.
Andrew Forget
PADI IDC Staff Instructor 212158
AndyDragon
Posts: 110
Joined: Tue Nov 14, 2006 08:38
Location: Penetanguishene, Ontario
Contact:

Re: Need testers for dive computer downloader

Post by AndyDragon »

Sent you an email (several actually). Seems the checksum routine is different (sum of nybbles instead of sum of bytes).
Andrew Forget
PADI IDC Staff Instructor 212158
AndyDragon
Posts: 110
Joined: Tue Nov 14, 2006 08:38
Location: Penetanguishene, Ontario
Contact:

Re: Need testers for dive computer downloader

Post by AndyDragon »

New version of the downloader is up and Mark I (MOD-protocol) computers seem to be working...
Andrew Forget
PADI IDC Staff Instructor 212158
haarald
Posts: 12
Joined: Mon Apr 14, 2008 12:53
Location: Munster
Contact:

Re: Need testers for dive computer downloader

Post by haarald »

Hey Sven, TnT, Andy,

i think I have something to contribute concerning two Suunto Cobra devices read via COM1 with an 'ebay brand' interface cable. :D Due to the fact that the original cable is very expensive (as the actual cobra :wink: )

Situation: Suunto DM2 is able to read both computers, DivingLog 4.0 does not find the device.

So I thought, it might help providing additional information here instead of complaining something like "This does not work..." I decided, not to send any stuff via email to several recipients but to show the results on a dedicated page under hinznet.de written in english language. (Sorry, the rest of the page is held in 'guttural german' :mrgreen: )

Everybody involved in diving computer interfaces is kindly requestet to visit http://www.hinznet.de/downloaderin order to review the dumps and logs already available.

What can I provide? Well, I followed TnT's first request in this board and installed PORTMON and VIPER.EXE and already took a dump from a brand new cobra with no dives in memory.

As soon as my beloved wife (also equipped with a 2 year old cobra) will hand out her cobra in order to read the last dives I will also take a dump and post it here.

And, by the way: Anybody interested in an Aladin Air Z 4 years old nearly unable to read the transmitter in salt water? :twisted:

Have a nice day

Harald
--
ttfn Harald
TnT
Posts: 262
Joined: Thu Nov 29, 2007 14:53
Contact:

Re: Need testers for dive computer downloader

Post by TnT »

None of the logfiles on your website contains anything interesting because you made a mistake while capturing with PortMon and running my test application. It appears your interface is attached to COM2 (because that's what you write on your website), while you are capturing with PortMon on COM1. So the logfile only shows the SDM probing for the interface which obviously does fails because there is no cable on this port. The same problem with my test application. You need to pass the correct portname on the commandline (otherwise it uses COM1 by default). Thus something like:

vyper.exe COM2

BTW, the Suunto XML downloader that is currently being used by divinglog was not written by one of us (Andy or myself), but by James Connell.
Post Reply