Requesting OpenCPN support for the new Sailtimer Wind Instrument

[RhythmDoctor]

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!)

[bdbcat]

RD...

Sounds cool.

Issues/tasks....

1. BT/LE is "sketchy" on Windows. An understatement. BT on Windows has always been fragile, and I don't see recent improvement. Maybe W10 is better, I have not looked at it. Do modern Windows tablets support BT/LE? Or do we need a USB adapter chip?

2. So, software side first. When you get you environment up and running, we would want to look at the data stream, presumably from the iOS or Android bridging app. Somehow we need something like Wireshark to see if the data (any data?) can go out of the bridge, and into the Win box. If it does, we are golden. We just then need to decrypt if necessary, and patch it into the OCPN dashboard stream.


3. After getting the iOS/Android bridge mode going, then we can try some BT/LE adapters on the Windows box and see if we can get a stable setup.

So, I'm interested. Waiting for some sample packets....


btw, what is the point of encrypting the data? Does the vendor have any logic for that?

Dave

[RhythmDoctor]

Dave,

Thanks for your interest. I'll try to answer:

Originally Posted by bdbcat

1. BT/LE is "sketchy" on Windows. An understatement. BT on Windows has always been fragile, and I don't see recent improvement. Maybe W10 is better, I have not looked at it. Do modern Windows tablets support BT/LE? Or do we need a USB adapter chip?

I remember (and am grateful for) how you and team spent over 2 years fixing my quirky Bluetooth problem, which appeared to be a three-way combination of XP driver, Bluetooth-serial converter, and OpenCPN. Change any one of the three and the problem went away. I appreciate your persistence with that (fixed now!), and understand how that experience is not easily forgotten.

From a user perspective, I saw a big improvement in Bluetooth support when going from XP to Win8.1. I saw the improvement on headsets, speakers, keyboard, mice - virtually every device I have (including the serial-Bluetooth converters). I also have work computers with Win7 Enterprise, but they do not have Bluetooth, so I can't comment on the Win7 BT drivers. But my comments are strictly from the users' perspective, and what you see programming on the back end may still be a disaster.

I have three Win8.1 tablets - two Miix2 8" and an Acer Switch 10". All are low-end tablets at the $200-$230 price point. And they all have BT 4.0 radios built in, as stated in the specifications and the Device Manager ("Microsoft Bluetooth LE Enumerator") The LE specifies Low Energy mode that is specific to BT 4.0. I'm sure higher end tablets have it too. So I think it's a safe bet that built-in BT 4.0 support is now ubiquitous in all new tablets/laptops, and a dongle is not needed.

Originally Posted by bdbcat

2. So, software side first. When you get you environment up a nd running, we would want to look at the data stream, presumably from the iOS or Android bridging app. Somehow we need something like Wireshark to see if the data (any data?) can go out of the bridge, and into the Win box. If it does, we are golden. We just then need to decrypt if necessary, and patch it into the OCPN dashboard stream.

This will take awhile because I'm awaiting receipt of a replacement wind vane. The first one I received had a very weak Bluetooth transmitter with insufficient range, and that may have affected operation. At very close range (<6' away) I was able to get the data into their API app on both iPad and Android phone, and was able to get the stream into their own software. But I was not able to retransmit to another app or device. Then I learned that the retransmit function is not working yet for the new model hardware - just the older model.

Thanks for the tip for Wireshark. I'll try it out when the new wind instrument comes. I was looking for just that very thing, to see if I could pick up ANY data on ANY port. I could not find it coming across port 55554.

I seem to recall using either a web browser or maybe TeraTerm to detect a stream coming on 127.0.0.1:10110 when setting up my other instruments, but was unable to figure out how I had done that (it's been several years). So maybe Wireshark will work, especially if it can scan multiple ports so I don't have to guess.

Originally Posted by bdbcat

3. After getting the iOS/Android bridge mode going, then we can try some BT/LE adapters on the Windows box and see if we can get a stable setup.

So, I'm interested. Waiting for some sample packets....

btw, what is the point of encrypting the data? Does the vendor have any logic for that?

I should also mention that before I got the emails mentioning all the encryption stuff, I had tried just directly connecting my Windows tablet to the wind instrument with no API or iPad/Android in the middle. And, lo and behold, a Bluetooth scan showed the wind vane in the device list. When I tried to connect, it asked me for the pairing code. I tried the usual ones (0000 and 1234), but they did not work. So I wrote to Sailtimer and asked them what the code was, since I figured it must be hard-coded into their software. That's when I got the story about the encryption, and their claim that the passcode request is an artifact of BT 2.0. They claim the BT 4.0 is totally different, and it doesn't use paring codes and needs decryption codes instead. This is somewhat borne out by my quick read of the LE Security Spec. But something inside me tells me that if Windows asks for a "Pairing Code" then there must be a decryption code that could open up the connection, even if "Pairing Code" is a misnomer.

So it appears that Sailtimer's justification for encrypting the data coming directly out of the wind instrument is that BT4.0 (aka Bluetooth Smart and Bluetooth LE) requires it for compliance with the spec. That I can accept. And I hope that decryption could be done by the Windows drivers. If everything from BT4.0 is encrypted, then a driver that can't decrypt is totally useless.

The claim that the data coming out of their API is encrypted is far harder to accept. If they're sending this data out on UDP 127.0.0.1:55554 (as they claim), and their app is taking that data, doing some calculations, and retransmiting on the exact same port (but maybe broadcast over both localhost and the router's address), then any listener is going to see a hopeless hodgepodge of unencrypted ASCII text mixed in with encrypted stuff. It would be impossible to parse and decrypt, I would think. (Though I'm not an expert.) My guess is that their API is spitting out an unencrypted ASCII stream of NMEA sentences, OA running on my phone with their API active should be able to pick it up and retransmit it to my Windows tablet. I just need to try it when the new wind instrument comes, and maybe use Wireshark to help diagnose.

[CarCode]

I guess BT4.0 has nothing to do with TCP/IP, UDP or such networking and so you can't use wireshark. For receiving BT4.0 in your PC or tablet you will need however BT4.0 hardware and a BT4.0 stack. Only the latest machines have that otherwise you will need a BT4.0 dongle.

Gerhard

[RhythmDoctor]

Originally Posted by CarCode

I guess BT4.0 has nothing to do with TCP/IP, UDP or such networking and so you can't use wireshark. For receiving BT4.0 in your PC or tablet you will need however BT4.0 hardware and a BT4.0 stack. Only the latest machines have that otherwise you will need a BT4.0 dongle.

Gerhard

The wind instrument uses both BT and UDP, so Wireshark may be helpful for UDP. I need to try it before commenting further.

BT4.0 seems to be in most everything sold over the last two years, even pretty low-end stuff. Dongles rarely needed, and cheaply obtained. Someone who pays $450 for a wind vane isn't going to balk at $15 for a dongle.

[RhythmDoctor]

The Sailtimer guys just contacted me and let me know that there are discussions about developing an API for Linux. I urged them to coordinate that effort with Windows in a way that OpenCPN might support them using the same common code.

Dave - Are you willing to reach out to them? I am trying to get a specific contact person at the company.

[bdbcat]

RD...

Sure, lemme at 'em.


Dave

[mhasting2004]

Hi Guys

FWIW I have a new Sailtimer (latest version) on order and should arrive in 4 -6 weeks. Happy to help with testing on windows and Android.

Dave did you end up getting contact info for the sailtimer developers? if not I'll chase them down for you as the brief discussions I've had so far indicate that they are very keen to help get their hardware working with as many apps as possible and OpenCPN would be a great one IMHO.

I've posted similar over on the Android forum but not sure I'm getting thru (had login issues recently and am unable to PM)

Will post as soon as the gear arrives.

BTW as iRegatta has decided to pull their Android version its a big vacuum out there for a charting/race setup app....just saying having a cool wireless input device could win over a lot of smaller racier boats


Cheers

Mark

[Hakan]

Hi. A branch line if you please:
I was looking into this gear but the BT and encryption solution made me hesitate.
NASA wire less wind mast head and interface units are doing nearly the same job but pure serial NMEA0183 interface that will fit direct into OCPN.
What's your arguments for not use that one instead?
Clipper: NASA Marine Instruments
Håkan

[mhasting2004]

For me its the fact that the Sailtimer unit has an internal compass so it will work with a rotating rig.

I was not aware of the NASA unit but given the above criteria it would not have suited and also costs more.

One more thing reading the specs is it doesn't seem to transmit from the base unit so if its got a proprietary wireless interface to the head unit how can one connect (wirelessly) to a tablet?

[skipperearly]

Originally Posted by mhasting2004

For me its the fact that the Sailtimer unit has an internal compass so it will work with a rotating rig.

I was not aware of the NASA unit but given the above criteria it would not have suited and also costs more.

One more thing reading the specs is it doesn't seem to transmit from the base unit so if its got a proprietary wireless interface to the head unit how can one connect (wirelessly) to a tablet?

I own the SailTimerWindVane for 3 seasons now and had also tried to get the guys in Canada to open their mind for better sw support. Same experience - they do not wish to understand - just sell their rather user-unfriendly software. Nobody can read this round dial in daylight and generally the important figures like wind speed is hardly readable as too small.
Also calibration of wind direction/speed is very cumbersome or impossible.
Their claim to enable a rotating mast and inbuild compass sounds like a hoax to me. My unit arrived also DoA and got replaced FoC - those days I thought it can happen, as I now ready others experienced the same it lets me believe their manuf/QA process is somehow fragile.

Anyhow my unit connects proprietorially to the base unit which then opens a UPD 127.0.0.1:55554 wlan. I am now experimenting with the Openplotter/OpenCPN adding to the rpi another wlan tonggle for SailTimerWindVane.com. As the 2xAA batteries in the base unit last on approx 8 hrs I am also looking for a solution to wire the base unit up directly. e.g directly with voltage splitter 12V/3.2V for power. I also opened the base unit and discovered a 6 pin connector next to the wlan module. I suspect I can pick up the nmea 183 signal there, that way I could avoid the additional wlan sailtimer-network and connect directly to the rpi.
Has anyone tried this already?

Finally - if I would need to buy again a wireless wind unit I would consider the NASA mentioned above and connect it to rpi3-OpenPlotter. The price is nearly the same but much less proprietary stuff.

that for my2Cent

[Hakan]

mhasting...
Given your criteria I do agree of the SailTimer's advantages.

For me NASA's gear would fit fine although I'll need a serial to USB unit to transfer to my PC and OCPN. (I could also feed it directly into my Simrad IS15 system without the USB converter.)
I already have a compass, and COG/SOG, in my system so true wind speed and angle will be calculated from the MWV sentence.
I've a tablet as well but OCPN in my laptop is multiplexing all my signals and broadcast it to a wireless router. But normally I prefer running VNC on the tablet viewing the PC screen. (And I can close the laptop lid to save power)
The prize for the two gears are, at least in Sweden, close to equal.

[mhasting2004]

Well I hope I have better luck than you Skipperearly. I've delayed purchasing a unit for a couple years just because of lack of feedback out there on these units. Also the prices have been steadily dropping as newer versions are released..I got mine for $350 US which in Ozzie dollars is still expensive but competitive

By the sounds of it you have an earlier model that needs the base station? My understanding is that will not be necessary in my case as I have no need (or desire) for a wired network and using their API I can directly link to the unit via my tablet. iReggata on iOS supports it, and it also appears Sailracer will too very soon. Unfortunately iReggata on Android has been recently withdrawn.

Not sure why you think having an inbuilt compass is a hoax or gimmick. Its really IMHO the best way to deal with a rotating mast and the chips are a dime a dozen now as they are in every phone and tablet out there.


I'll be sure to give the unit a thorough testing when it arrives and post on my findings. Very curious why you would need to calibrate the wind speed or direction.

Cheers

Mark

[skipperearly]

Originally Posted by mhasting2004

....

By the sounds of it you have an earlier model that needs the base station? My understanding is that will not be necessary in my case as I have no need (or desire) for a wired network and using their API I can directly link to the unit via my tablet. iReggata on iOS supports it, and it also appears Sailracer will too very soon. Unfortunately iReggata on Android has been recently withdrawn.
[Skipperearly]
You may have misunderstood me there. The mast unit transmits by some probriatary 2.5Mhz standard to a base unit which translates the the signal into NMEA and sends them to the wlan UDP. That way it can be picked up by any wlan-connected devise/iPad/Android or W10. Problem is that you need teh SailTimerWindVane wlan, so as normally you have already a Ship-wlan and devise wanting to use the wind data needs now 2 wlan's.
I have done this on a RasperryPi with OpenPlotter which act as a NMEA router.
I dont understand SailTimers website as that the signal from the mast-unit beeing already NMEA 183 over BT4.0 ! The way I understand it is their base unit can transmit either wlan or BT4.0 - but I may be mistaken.
---------------

Not sure why you think having an inbuilt compass is a hoax or gimmick. Its really IMHO the best way to deal with a rotating mast and the chips are a dime a dozen now as they are in every phone and tablet out there.
[Skipperearly]
its another power-consumer and the solar is already struggling in poor weather - maybe for rotating masts the best option , but majority of vessels are still fixed masts.
-------------

I'll be sure to give the unit a thorough testing when it arrives and post on my findings. Very curious why you would need to calibrate the wind speed or direction.

Cheers

Mark

[Skippeearly]
I trust my compass setting, or the GPS-calculation of course more than the reading from the wind direction sensor. When fitting the unit on the masttop it is very difficult to calibrate correctly. This is also the reason why a correction is possible in their e.g. iRegatta setting - I complained about this and fortunately was heard
Speed: I agree! - is not so relevant but why not?

I had great hopes when I purchased the unit, struggled to get it working and had to insist to change the unit before getting it to work.Initially the supplier wanted to load all blame on "wrong usage" and finally I had to accept their strategy is not to have a open product but preferably to bunddle it with their sw. Cant blame them - the product is still working for me - but I am disappointed that a good product doesnt become great!
(In the meantime several other developers are producing solar powered Wind sensors, lets see how open-minded they will be)

cheers to the other side of the globe

[mhasting2004]

Hi Skipperearly... when I said why do you need to calibrate I meant why aren't they calibrated out of the box.

Apart from the possible need to do the whole twisting on 3 axis trick like with the sensors on a phone (Which BTW would be unacceptable in a fixed masthead setup and is just a guess on my part) the speed should be correct from the manufacturer as its just counting rotation pulses.

Current version doesn't have the base station box so its BT from the unit.

I believe one of the main purpose of the API is to filter the readings as well as bundle them into a usable NEMA format. Part of that being the need to report wind angle as it is constructed from the internal compass reading rather than a relative angle from the boat.

BTW I don't want to sound like a reseller of this unit...I'm just hoping that I didn't waste my $$. Time will tell if what I think it can do meets with reality and like you I am very surprised some other players haven't hit the market running by now.

Cheers