Support for Subgear XP10 ?

[Shizen Shrestha]

Hello everyone ~ 

I just found out about this software and downloaded version 4.9.6 on my iMac.

I have Subgear XP 10 which is listed as supported dive computer but I do not see it within the software.

Can someone confirm if this is supported ?

Also if it is supported, can you also advise me what I should buy to make communication between my dive computer and computer ? Some soft of IR interface ?

Thank you so much for help !

Shizen

[Linus Torvalds]

On Fri, Jul 17, 2020 at 4:55 PM Shizen Shrestha
<shizens...@gmail.com> wrote:
>
> I have Subgear XP 10 which is listed as supported dive computer but I do not see it within the software.

It's an IRDA dive computer, and IRDA is not afaik supported any more
anywhere else than on Windows..

Linus

[Shizen Shrestha]

Thats a bummer ... but thank you for quick reply.  :)

[Linus Torvalds]

We've been hoping somebody would just do a user-space IRDA stack
(afaik, many of the IRDA chips are basically just UARTs, and you have
to just parse the IRDA stuff manually).

I think that's what some other dive logs do.

But despite some discussion about it a year ago, nobody ended up
standing up and doing it, probably because all the dive computers
using it are old and most people have moved on to bluetooth and just
left any IRDA equipment behind.

Linus

[Charles Plante]

I got an XP10 dive computer too. Im hoping to make it work with and Arduino IRDA shield. How is Subsurface accessing the serial COM port ?

[Linus Torvalds]

On Wed, Aug 19, 2020 at 10:15 AM Charles Plante
<charlesplan...@gmail.com> wrote:
>
> I got an XP10 dive computer too. Im hoping to make it work with and Arduino IRDA shield. How is Subsurface accessing the serial COM port ?

Right now libdivecompuer marks the XP-10 as IRDA only, so subsurface
wouldn't even try to access it with a serial port.

That said, if you make the Arduino do all the IRDA connection parts,
and the serial port would act as the transport only (ie there would be
no sign of irda as far as libdivecomputer is concerned - it would just
see the raw data as serial), then I think supporting it would be
literally as simple as adding a DC_TRANSPORT_SERIAL flag to the
device, ie something like this in libdivecomputer:

- {"Subgear", "XP-10", DC_FAMILY_UWATEC_SMART,
0x13, DC_TRANSPORT_IRDA, dc_filter_uwatec},
+ {"Subgear", "XP-10", DC_FAMILY_UWATEC_SMART,
0x13, DC_TRANSPORT_IRDA | DC_TRANSPORT_SERIAL, dc_filter_uwatec},

and if you're doing an Arduino shield thing, I'm assuming you're also
able to build libdivecomputer and subsurface with that change?

HOWEVER.

The libdivecomputer packetization is different for serial and IRDA. So
you'd have to not just do the IRDA connection part, you'd have to
re-packetize the IRDA data as "serial packet" data.

The serial packet format on sending is very simple. For one "packet", you'd see:

- 7 bytes of fixed header:

FF FF FF A6 59 BD C2

- 4-byte LE size of data packet (command byte + arguments), and since
the size is limited, it's just

xx 00 00 00

- payload (cmd byte + data bytes)

- one final checksum byte that is just the xor of the 4 bytes of
length and the payload

and when the arduino receives this data, it should just send the
payload as a IRDA COMM packet (which involves whatever IRDA COMM
protocol stuff you need - I don't know what the Arduino IRDA libraries
look like, I assume they have that part).

Going the other way, when you receive an IRDA COMM packet, your
Arduino logic should send it back as

- 4-byte size LE payload size

- payload (cmd byte + data bytes)

- one byte xor checksum of the above.

So it's really the same format going both ways, apart from that extra
7-byte synchronization header that libdivecomputer sends and you
should basically ignore.

NOTE! I have not tried any of the above. This is purely by reading
what libdivecomputer does. I've never used an IRDA dive computer. I'll
be happy to help if you get to the point where you see serial and IRDA
data flowing, though.

Linus

[Jef Driesen]

On 19/08/2020 19:59, Linus Torvalds wrote:
> The libdivecomputer packetization is different for serial and IRDA. So
> you'd have to not just do the IRDA connection part, you'd have to
> re-packetize the IRDA data as "serial packet" data.

That's not necessary. You only need to *pretend* to have an IrDA transport. This
is trivially done by wrapping the serial transport inside a custom transport
with the IrDA type:

dc_status_t
fake_irda_open (dc_iostream_t **iostream, dc_context_t *context, const char
*devname)
{
dc_status_t status = DC_STATUS_SUCCESS;

const dc_custom_cbs_t callbacks = {
dc_iostream_set_timeout, /* set_timeout */
dc_iostream_set_break, /* set_break */
dc_iostream_set_dtr, /* set_dtr */
dc_iostream_set_rts, /* set_rts */
dc_iostream_get_lines, /* get_lines */
dc_iostream_get_available, /* get_available */
dc_iostream_configure, /* configure */
dc_iostream_poll, /* poll */
dc_iostream_read, /* read */
dc_iostream_write, /* write */
dc_iostream_ioctl, /* ioctl */
dc_iostream_flush, /* flush */
dc_iostream_purge, /* purge */
dc_iostream_sleep, /* sleep */
dc_iostream_close, /* close */
};

dc_iostream_t *tmp = NULL;
status = dc_serial_open (&tmp, context, devname);
if (status != DC_STATUS_SUCCESS) {
ERROR ("Failed to open the serial port.");
return status;
}

return dc_custom_open (iostream, NULL, DC_TRANSPORT_IRDA, &callbacks, tmp);
}

I use this kind of trick all the time for testing libdivecomputer without
needing a real IrDA, USB, bluetooth, or whatever transport. This works really
well, and is one of the nice advantages of the iostream interface.

And of course it's not limited to using a serial transport. You could equally
well implement some custom transport that transmits the data over the network,
of whatever you prefer.

Jef

[Willem Ferguson]

--
You received this message because you are subscribed to the Google Groups "Subsurface Divelog" group.
To unsubscribe from this group and stop receiving emails from it, send an email to subsurface-dive...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/subsurface-divelog/6937d06f-5186-4009-8794-6557e2746533o%40googlegroups.com.

Charles,

Would you be prepared to keep contact with me about progress with this project? I ordered an IrDA breakout board about 6 weeks ago but I am still waiting for it to be delivered from Sweden.

Kind regards,

willem

This message and attachments are subject to a disclaimer.
Please refer to http://upnet.up.ac.za/services/it/documentation/docs/004167.pdf for full details.

[Linus Torvalds]

On Thu, Aug 20, 2020 at 12:45 AM Jef Driesen <j...@libdivecomputer.org> wrote:
>
> That's not necessary. You only need to *pretend* to have an IrDA transport.

Fair enough. That will make libdivecomputer happy, but it might not
make the actual *device* happy.

Because the device might actually depend on the exact IRDA
packetization, so you might actually want to use the packet boundary
information from the serial packetization to then create the right
IrDA packets.

Now, admittedly nobody should ever do that for IrCOMM users (it's
supposed to be just a plain serial protocol), but who knows. A lot of
dive computers have been known to have very limited protocol stacks,
because the internal microcontroller is traditionally fairly limited.

Linus

[Linus Torvalds]

On Thu, Aug 20, 2020 at 11:10 AM Linus Torvalds
<torv...@linux-foundation.org> wrote:
>
> Now, admittedly nobody should ever do that for IrCOMM users (it's
> supposed to be just a plain serial protocol), but who knows. A lot of
> dive computers have been known to have very limited protocol stacks,
> because the internal microcontroller is traditionally fairly limited.

Side note: irda is such an unholy mess that probably people use a chip
that does it all in hardware (well, has a internal state machine), so
I guess both the dive computer and the arduino irda hat are doing
that.

Looking around, probably using something like a MCP2150.

But irda really is messy and horribly badly documented (as in:
"documentation exists, but it's complete gibberish to any normal
person"). It's why we ended up giving up on it on the Linux side - our
implementation was a mess, there weren't enough users to really worry
about, and nobody could figure it out enough to fix the known issues
(and by "known issues" I most definitely do not mean "_understood_
issues" - they were things like "it works for some people, not for
others").

Linus

[Jef Driesen]

I doubt this is going to be a problem. Libdivecomputer will send the exact same
data as it would send to a real IrDA dive computer. That's the only thing the
DC_TRANSPORT_IRDA type does. There is no such thing as IrDA packetization at
this level because the socket based IrDA api is stream oriented.

The actual IrDA packetization is handled by the underlying IrDA stack, and not
by libdivecomputer. Whether you send the data directly to the Windows or Linux
IrDA stack, or first over some intermediate transport (serial or even the
network) and then to the IrDA stack of some external microcontroller is probably
not going to make much of a difference.

And if it turns out to be a problem after all, you can always add some framing
over the serial link.

Of course, if the IrDA stack of the microcontroller is not compatible with the
one of the dive computer, then yes, that would be a major problem. I would
expect two IrDA devices can talk to each other. Otherwise what's the point of
using a standardized protocol?

Jef

[Linus Torvalds]

On Thu, Aug 20, 2020 at 12:48 PM Jef Driesen <j...@libdivecomputer.org> wrote:
>
> Of course, if the IrDA stack of the microcontroller is not compatible with the
> one of the dive computer, then yes, that would be a major problem. I would
> expect two IrDA devices can talk to each other. Otherwise what's the point of
> using a standardized protocol?

Oh, you clearly haven't seen the low-level details of the crap that is IRDA.

It's a truly wonderful protocol. And by "wonderful" I mean "Oh Gods, I
need to use forks to dig out my eyes after seeing it".

IrCOMM as a design tried to support various different use cases, but
almost nobody actually implements even half of it.

So there are different versions of IrCOMM, all subtly incompatible,
and with the hardware dongles supporting one but not the other.

Of course, almost all of IRDA is "optional protocols", so everybody
can claim to be standards-compliant. They just didn't implement all
the optional parts.

End result: you can have two standards-compliant IRDA things that
won't talk to each other, because they used different optional
protocols.

You'd really think that some IR standard designed in the 80's would be
simpler than it is.

And maybe I know just enough about it to think that it is horrendously
ugly, but not enough to understand the true beauty of the thing.

In the parable of the blind men and the elephant, I may have been
putting my hand up the proverbial arse of IRDA, without understanding
the majesty that is the whole thing.

Linus

[Jef Driesen]

Well, in that case, I guess the only way to find out whether it works is to try
it...

Jef