[PATCH] Cochran_commander refactoring

[John Van Ostrand]

On Mon, Dec 22, 2014 at 2:48 PM, Jef Driesen <jef at libdivecomputer.org>
wrote:

> On 22-12-14 20:33, John Van Ostrand wrote:
>
>> On Mon, Dec 22, 2014 at 10:38 AM, Jef Driesen <jef at libdivecomputer.org>
>> wrote:
>>
>>  On 19-12-14 21:23, John Van Ostrand wrote:
>>>
>>>  I did more investigating of setting commands and encoding. I've updated
>>>> the
>>>> trac wiki with the full information. It should be complete but it's not
>>>> tested or strongly verified. There may be mistakes.
>>>>
>>>> I did some testing today reading raw data to see if I could download a
>>>> usable memory dump for the dump function and avoid all that work done in
>>>> _dump and eliminate the need for cochran_download.c.
>>>>
>>>> The read command (0x15 <start> <bytes>  0x05) only reads logbook and
>>>> sample
>>>> data. I suspected that the gap between logbook and sample contained
>>>> config
>>>> or other data but that isn't the case. There is no gap between Commander
>>>> logbook and samples and the EMC has no data of significance there.
>>>>
>>>> Also, when asked to read past the end of data on the Commander, It
>>>> returns
>>>> 0xFF for data that doesn't seem to be there. For example, the Commander
>>>> I
>>>> have has rolled the sample data buffer so all the memory has been
>>>> written.
>>>> Sample data stops at 0x100000 (1MB). When I asked for 8MB of data I got
>>>> 7MB
>>>> of 0xFF.
>>>>
>>>> Unless i discover a new command to read data I won't be able to deliver
>>>> a
>>>> raw memory dump.
>>>>
>>>> I'm also no closer to deciphering the feature data from the computer so
>>>> I
>>>> don't know how much memory is present and enabled.
>>>>
>>>>
>>> I'm not sure I'm understand what you're saying here. First you say you
>>> can
>>> download 1MB of data. But then you say you can't download a memory dump?
>>> I
>>> don't know what you consider a memory dump, but I would say it's that 1MB
>>> of data! Combined with the id, misc and config blobs that has everything
>>> we
>>> need. I have no idea what else you want.
>>>
>>>
>> What I meant was that I could not produce a contiguous segment of memory
>> that contained everything, which seemed to be what you thought would be
>> ideal for _dump().
>>
>
> Now I'm even more confused. If I'm right, then for the commander the
> logbook ringbuffer is from address 0x0 to 0x20000. And the profile
> ringbuffer is from address 0x20000 to 0x100000. So that's one continuous
> block of 1M in size. That would be perfect for a memory dump.
>
> Am I missing something here?
>

When I say "everything" I mean info, config and misc data too. That can't
be read the same way log and sample data is.


>
>  PS: Can you send me the data from your Commander too. If you have data
>>> from the other models, I would like to have a look at that too.
>>>
>>>
>> I'll send a separate email.
>>
>
> Thanks.
>
> If you're interested in the source code for my libdivecomputer simulator,
> then let me know and I'll package it for you.
>
>
I would be interested.


> Is it possible to install the Analyst software on my side, and make it
> talk to the simulator, or load the corresponding CAN files? That would help
> a lot. But I can only find a demo version, which seems to have the
> communication disabled


The software is an extra charge (with cable) and I recall but it seemed to
call home to authorize or log an activation.

Do you want screen dumps? I can also run a USB log and export to CSV. The
file would include lots of collateral data but it's parseable. The CAN
files are weaklly encrypted and I finished and submitted the Subsurface
code to read CAN files. The CAN file contains log entries followed by the
dive sample data in raw format. Since the addresses in the log don't apply
to the relocated sample data my code uses something similar to corrupt dive
parsing.

-- 
John Van Ostrand
At large on sabbatical
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://libdivecomputer.org/pipermail/devel/attachments/20141222/5389fd0b/attachment.html>