I would like to enlist the help of OpenCPN
developers to support the newly released Sailtimer Wind Instrument
. This is a wireless, solar
powered wind transducer
with some very cutting-edge design attributes. It delivers its signal by Bluetooth 4.0 LE (low energy) mode, which allows it to run off the very small solar
cell/battery that is built into its fin. It comes with no display (which lowers the cost substantially) and relies exclusively on a computer, phone
, and/or tablet to display the wind
data. This is where my request for OpenCPN
support comes in. I think this device is potentially a perfect match for OpenCPN with dashboard plugin.
I've exchanged some emails with them about their software
support, and it could use some improvement IMO. Those guys live in an iOS-centric world, which positions them poorly for OpenCPN support. They are developing some Android software
which play well with the new OA release (more on that later), but Windows is being left out in the cold. And I still believe that, even with OA available on Android, Windows 10 tablets will be a viable and growing platform for high performing, low cost, sunlight readable tablets for the marine
envrionment. So getting some support is a worthy effort IMO.
To summarize the contents of the 10 or 20 emails that we have exchanged, the Bluetooth LE transmitter embedded in their wind instrument puts out an encrypted signal that their API app (on iOS and Android) needs to decode. It would be nice to have a Windows API to do this, and if we can convince them that Windows is viable, they have expressed willingness develop one or partner with someone else in the OpenCPN community to develop one. They say that the support for BT4.0 LE mode is sketchy on all platforms, and has required a lot of custom coding to work
out the kinks. I'm not a programmer, so that's the extent of my knowledge about the alleged BT4.0 issue.
In Sailtimer's current
software design, their API app reportedly does calculations to determine actual wind speed and true wind direction. A few words of explanation on this: The vane has a compass
built in, so it uses that for magnetic direction. The vane needs to get GPS
location for magnetic deviation (to calculate true direction) and GPS
speed (to calculate actual wind speed). The current
iOS and Android API apps pull this information in from the internal GPS chip on the phone/tablet. Personally, I don't think this needs to be done in the API. In a Windows/OpenCPN world, where the GPS is often external from the laptop/tablet, it may be better for the API to pass magnetic direction and apparent speed to OpenCPN, and let OpenCPN calculate true direction and actual speed (as it already does for other vind vanes). But I digress...
For display of thier wind data in iOS or Android, they tell me that they use UDP port 55554 to pass the data internally (presumably on localhost, i.e., 127.0.0.1:55554) to an app residing on the same device (iOS or Android). They claim that this data is encrypted NMEA
and needs decryption in the receiving program. I have my doubts whether this data is encrypted (for reasons that I'll explain later). Based on the emails I received, I'm not sure the guy giving me this information is a programmer, and he may be passing on others' comments and getting confused about the data coming into the API vs. the data going out.
At present Sailtimer has their own iOS app (in addition to the API) that displays the wind data, as well as some other authorized 3rd party software products that are displaying the data on iPads. I am underwhelmed by the Sailtimer app. They seem to be very focused on calculating optimum tacks for racers, but their graphical display is a north-up only dial at the corner of a chartplotter
display. (Just what i need, yet another chartplotter
display!) I would like to see a course-up or heading-up dial of apparent wind data so you can easily see at a glance whether you're pinching or reaching, etc. In other words, a digital equivalent of a traditional wind display, just like is done on the Dashboard plugin. But they don't provide this on their software.
Their Sailtimer iOS app does have a "retransmit" feature that sends out unencrypted data to other programs in the same device, to other devices, and (in the future) to the Internet
where others will be able to access the crowd-sourced data. (Their vision is a whole club of racers who have their vanes and share their data so they have a real-time GRIB-like display of the whole race
course. I'm skeptical over whether racers are that altruistic.) They tell me that this unencrypted data will be sent between devices on UDP port 55554. I do not believe that it is possible to commingle unencrypted data and encrypted data on the same UDP port, so that's why I think some of the encryption and/or port information that I've gotten is incorrect.
The "retransmit" feature was rolled out for their previous model of wind vane
, and they told me that it is not yet implemented for the new model of vane. When it is implemented and working, I should be able to run the Sailtimer app on an iPad
and retransmit that data on UDP 55554 through my boat's Wifi
router and over to my Windows tablet for display in OpenCPN. This is a lot of overhead just to get the wind data into OpenCPN (which is the only program I really want to have running), and obviously what I would like to see is native Windows support for the wind vane
to eliminate the iPad
(which I've never liked as much as Windows or Android tablets).
My wind vane's transmitter was defective, so I was not able to do much testing with it. I am awaiting a replacement. When that replacement comes, I want to run the Sailtimer API on my Android phone
and see if I am able to pull unencrypted wind data into OA. That will help to determine whether their API is sending out encrypted or unencrypted data. If that works, then I can have OA receive the stream on UDP 127.0.0.1:55554 and retransmit it on port 10110, like I already do with other instrument data. That will be less overhead than running an iPad, but still more hardware
than I would like. The best way forward IMO is to get native support fully within Windows so OpenCPN can run there without additional devices also running.
Are there any volunteers (Dave? Sean? others?) who might be willing to take this on? Or is Windows considered a dead platform for mobile computing? (It's certainly not dead in my eyes!)