Hi,
Strange behaviour for Nemo Excel. If I readout my dives, they are set to Nitrox 32 while the internal Logbook shows them as AIR (which they actually were!). My guess: there is an additional AIR/EAN flag.
Tschau,
Bjoern
On 2012-03-26 22:45, Björn Spruck wrote:
Strange behaviour for Nemo Excel. If I readout my dives, they are set to Nitrox 32 while the internal Logbook shows them as AIR (which they actually were!). My guess: there is an additional AIR/EAN flag.
It's not unlikely there are bugs in this area. Patches are always welcome.
Jef
Am 27.03.2012 10:33, schrieb Jef Driesen:
On 2012-03-26 22:45, Björn Spruck wrote:
Strange behaviour for Nemo Excel. If I readout my dives, they are set to Nitrox 32 while the internal Logbook shows them as AIR (which they actually were!). My guess: there is an additional AIR/EAN flag.
It's not unlikely there are bugs in this area. Patches are always welcome.
hmhm... and I have the next one: Suuntu Gecko: Years off by 5, Nitrox not noticed (no gas mix?).
On 03/27/2012 07:52 PM, Björn Spruck wrote:
Am 27.03.2012 10:33, schrieb Jef Driesen:
On 2012-03-26 22:45, Björn Spruck wrote:
Strange behaviour for Nemo Excel. If I readout my dives, they are set to Nitrox 32 while the internal Logbook shows them as AIR (which they actually were!). My guess: there is an additional AIR/EAN flag.
It's not unlikely there are bugs in this area. Patches are always welcome.
hmhm... and I have the next one: Suuntu Gecko: Years off by 5, Nitrox not noticed (no gas mix?).
I'm not aware of any Gecko bugs. Since it's a very popular model, I would think that such obvious errors would have been reported long time ago already. Doesn't mean there can't be a bug of course :-)
Can you send me a memory dump of your Gecko to confirm the errors? The procedure is explained here:
http://www.divesoftware.org/libdc/contribute.html#memory
Can you also send one for your Mares M1, to check your other patches?
Jef
hmhm... and I have the next one: Suuntu Gecko: Years off by 5, Nitrox not noticed (no gas mix?).
sorry my fault, year in the computer was off and not noticed.
PS: why does it take minutes to transfer 8kb of data? At 9600baud this should be order 10seconds?
On 2012-03-28 22:42, Björn Spruck wrote:
PS: why does it take minutes to transfer 8kb of data? At 9600baud this should be order 10seconds?
The baudrate is only one part of the story, and for the vyper protocol the slow baudrate is in fact the least important one.
When sending a request to the device, the protocol requires to wait some time (500ms) before sending the command, and again some time before reading the response (200ms). Since the 8K is send in packets of 32 bytes, that means those 256 packets require already 3 mins of waiting. In addition, you also have to take into account that the device doesn't respond immediately and the time to read a 32 byte packet is much larger (typically 300 to 500ms) compared to the theoretical transmission time.
Thus it's not the slow baudrate that makes the downloading slow. Luckily downloading dives is a little faster than doing a full dump, because the protocol requires only a single request for each not dive.
Jef
-
Björn Spruck -
Jef Driesen