On 2012-03-28 19:21, Thorsten Peter wrote:
Hi guys,
I tried to get my Mares Nemo Sport (in combination with the Mares Nemo Sport interface) working using libdivecomputer. Unfortunately I wasn't able to do so. I have to say that I was able to extract the data from the computer using Windows and the corresponding Mares tool
- so the hardware should be working fine.
I'm using Ubuntu 10.04 LTS - Lucid Lynx. I've tried with the newest GIT version, as well as with the latest snapshot from the website. The logs which I have attached were recorded with the latest snapshot (in the revision file it says 55a0a3fe0fff5b4b766003a5f09fce027b88572c)
Then I saw on the website that you are looking for any data concerning the Mares dive computers - and here it is:
EDY.log: command line call was ./edy /dev/ttyUSB0 output.log: command line call was ./universal -b edy /dev/ttyUSB0 output_dParam.log: command line call was ./universal -b edy -d xmlout.xml /dev/ttyUSB0
The xmlout.xml file during the last call was empty.
Obviously the Nemo Sport computer switches back to normal mode (you have to set it into PC mode before connecting) if a test runs a long time - this is why there is no more data in the log files.
If you need any more data I'm ready to support.
Your attachments have been stripped because the mailinglist was configured to strip attachments. I looks like I was a little over-enthusiast when configuring the mailinglist to use plaintext emails only. Should be fixed now.
Anyway, I do have the logfiles now and I noticed two things. First of all, there is an unusual high number of errors. Nearly every packet fails at the first try, and then succeeds when trying again. Because of these temporary failures the download takes a very long time. The second thing is that both the EDY.LOG and output.log show a fatal error after having downloaded exactly 8K of data. This could indicate that the Nemo Sport has less memory than the Cressi Edy (32K). This suspicion could also explain why you get the "Invalid ringbuffer pointer detected." error in the output_dParam.log file, because with the "-d" parameter the application will try to parse the data. Since the code assumes 32K of memory, that doesn't work of course.
I'll look into this in the next couple of days.
Jef