<div dir="ltr">Hi Linus, <div><br></div><div>Thanks for the suggestion. </div><div><br></div><div>I actually started out using subsurface as a test app - I actually started out by reading through all of your commits on the deepblu cosmiq to get an idea of what's required to add a new BLE computer - I did get subsurface to see the computer and initiate the pairing (the icon on the sync screen on the dive computer switches to the plugs being connected) - so the BLE part worked, and it's just the communication part that will take me a lot of iterations to work through. </div><div><br></div><div>I ran into a few issues that are entirely my fault and not the fault of subsurface - namely I couldn't figure out a way to get my IDE to launch the built subsurface app and attach to it and hit breakpoints inside of libdivecomputer  (again - totally my "not normally a c/c++ application developer" problem) - but after spinning my wheels for a while I figured I'd try to see if the dctool from libdivecomputer could be a faster path to "can I get code to communicate with this thing?" </div><div><br></div><div>Some of the notes I was working through are up here: <a href="https://github.com/ryangardner/excursion-decompiling/blob/master/Protocol%20Info.txt">https://github.com/ryangardner/excursion-decompiling/blob/master/Protocol%20Info.txt</a> (it's a combination of examining a decompiled android app that syncs with the computer and the captured hci packet logs, looking at how the android app parses the responses / communicates with the computer and comparing it with the hci logs) </div><div><br></div><div>I can take another stab at the subsurface route. (or some of the suggestions that Jef replied to after this - replaying communications logs etc). (and I can take basic subsurface build questions over to their list or irc channel if I get really stuck)</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, May 6, 2021 at 11:00 AM Linus Torvalds <<a href="mailto:torvalds@linuxfoundation.org">torvalds@linuxfoundation.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto"><br><br><div class="gmail_quote" dir="auto"><div dir="ltr" class="gmail_attr">On Thu, May 6, 2021, 07:43 Ryan Gardner <<a href="mailto:ryebrye@gmail.com" target="_blank">ryebrye@gmail.com</a>> wrote:</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="auto"><br></div><div dir="auto">What do you think is the easiest way to test / debug adding a new BLE device? I was hoping to use the simple dctool as a way to test things as I implemented it - but maybe there's a better approach? Do I need to build my own simple test app that sets up the ble connection and then hands things over to libdivecomputer?</div></div></blockquote></div><div dir="auto"><br></div><div dir="auto">Most of the libdivecomputer BLE code has been developer using Subsurface (and a lot of BLE packet traces).</div><div dir="auto"><br></div><div dir="auto">It's not some small convenient simple test app, but it does work.</div><div dir="auto"><br></div><div dir="auto">I've done everything on Linux, but Mac should work too at that point - although Mac had it's own BLE headaches.</div><div dir="auto"><br></div><div dir="auto">         Linus</div><div class="gmail_quote" dir="auto"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
</blockquote></div></div>
</blockquote></div>