On 2014-07-06 19:25, John Van Ostrand wrote:
I've started writing libdivecomputer code for the Cochran and I have a few questions that I expect are easy answers.
- I'm wondering how much I should read in the _init function. It seems
I should read enough to verify I'm talking to the right device and get the serial number. Is that right?
There is no init function, so I assume you mean the open function? There you should do whatever is necessary to setup the connection with the device. For some devices, that means opening the serial port and that's it, but others may need some extra steps. It all depends on the communication protocol.
- There are other reads I can do that will get things like # of dives,
gas mixtures, conservatism, etc. I need number of dives to read the log book. Should I do this in _read? And does it make sense to do this read before setting progress information?
None of this belongs in the read function. The read (and write) function is an optional function for devices that support random access to the internal memory (e.g. read X bytes at memory address Y). If a device doesn't support this feature, then it shouldn't be implemented. The same is true for the dump function. The only mandatory function is the foreach function. That's the one that is used by applications to download dives. Depending on the communication protocol this function may be implemented on top of the dump or read function, but that's just an implementation detail.
Thus the foreach function is where you implement the logic to download the individual dives, and you may read whatever piece of information is necessary there.
- I have extra information that I can offer the user, pre- and
post-dive things like battery voltage, tissue load, time to fly, previous SIT, repetitive dive count and dive profiles samples like tissue load every 24 seconds, NDL remaining (I think), deco required (I think), ascent rate. I can also get post dive off-gassing tissue load and temperature samples. The DC continues to log samples until off-gassed I can't see any structure for all of this, or a way to carry around that kind of data.
Libdivecomputer doesn't offer an api to retrieve this kind of information because it's too device specific. That's on of the reasons why libdivecomputer does provides access to the binary dive data. If an application wants to get some info which isn't available through the libdivecomputer parser api, it can still get it from the raw binary data. Of course that's not as convenient as using the api, but it is possible.
- The DC requires some prodding to accept commands, after being
prompted it emits a byte every second. Initially it's a 0xAA but after reading dive samples it's a 0x00. The only way I've been able to prompt it is to send a byte to it. The vendor software doesn't do this. Could it be a USB signal of some sort. I see "Sync Reset Pipe and Clear Stall" in the USB capture and "Vendor Device" and "Control transfer". Any ideas on what I might try?
It's hard to tell without seeing the communication you captured. Some protocols do indeed use the dtr/rts lines, breaks, etc. Although most modern devices usually don't. (I guess usb-serial chips make this harder compared to real rs232 hardware.)
Jef