Showing posts with label NMEA. Show all posts
Showing posts with label NMEA. Show all posts

Thursday, January 09, 2020

dAISy AIS HAT for the Raspberry Pi

Just received the dAISy HAT from Wegmatt, it just works!
Whoever can click can do it.

And this was the opportunity to keep working on the AISParser, and I have also added a custom TCP Forwarder to the Multiplexer, along with an AIS filter on the regular TCP Forwarder.

This way, you can forward NMEA data on one port, and AIS data on another one. This is not necessary, but it can be nice to have.

Here is an example of a yaml driving the Multiplexer:

#
# MUX definition.
#
name: "With a GPS and AIS"
context:
  with.http.server: true
  http.port: 9999
  init.cache: true
channels:
  - type: serial
    # GPS
    port: /dev/ttyUSB0
    baudrate: 4800
    verbose: false
  - type: serial
    # AIS
    port: /dev/ttyS0
    baudrate: 38400
    verbose: false
forwarders:
  - type: tcp
    port: 7002
    properties: no.ais.properties
  - type: tcp
    subclass: nmea.forwarders.AISTCPServer
    port: 7003
computers:
  - cls: nmea.computers.AISManager
    properties: ais.mgr.properties

And OpenCPN is happy in both cases.

See more details here.

Monday, March 11, 2019

Smart TCP Watch, prototype.

TCP, no BlueTooth (and as a result, no Smart Phone) is required. The "watch" can connect directly to the network.
See a first prototype here.
And a short video here.

Saturday, December 31, 2016

NMEA Multiplexer, OpenCPN, GPSd...

I have been working on an NMEA Multiplexer that can run on small boards, like the Raspberry PI Zero. The code is available on github, see the documentation in the README.md.

It allows to mix all kinds of NMEA Sources into a single (or multiple) stream(s). You can read from Serial Ports, Log file(s), TCP, WebSocket, Sensors (like BME280, HTU21DF, LSM303, etc), merge those data and rebroadcast them on Serial port, TCP, Log file, WebSocket, GPSd, etc. UDP is being worked on.

Data can also be computed and injected in the output stream, like True Wind, Current direction and speed, etc.

As a graphical desktop can be cumbersome on small boards, the Multiplexer comes with a tiny HTTP server that provides a Web UI and REST services to allow remote Admin.

It also comes with several demos and samples
This all works just fine with OpenCPN, SeaWi, that can take TCP streams as NMEA Data Input.
I was also wondering about GPSd. I had some mixed feelings about it. Mostly, I was asking myself "Why should I parse GPSd json objects if I can parse NMEA Sentences?", and could not find any satisfying reason. The topic is mentioned on the GPSd web site's FAQ pages, but nothing clear (to me) came up from that.
Interestingly, OpenCPN can also take GPSd streams as input. But there is a trick.
The first GPSd exchange begins with a ?WATCH request. It is followed by a JSON Object like this:
  ?WATCH={"enable":true,"json":true}
... and here is the trick, OpenCPN sends a
 ?WATCH={"enable":true,"nmea":true}
This nmea option is "poorly" documented, but very useful. Instead of sending JSON objects, GPSd spits out the raw NMEA sentences, as they were read. Then GPSd is just a regular TCP stream, and OpenCPN already knows how to parse the NMEA sentences it delivers. This way, GPSd is not limited to strictly GPS-related sentences. It can convey all NMEA sentences, Boat Speed related, Wind related, etc. This is what the GPSd forwarder that comes with the Multiplexer is doing.
Happy Streaming, happy new year!

Sunday, July 24, 2016

Live Wallpaper, offline

The Live Wallpaper (in the navigation console) has been improved. Several bugs were fixed (like the one for the daylight), and you can now use it offline, like when no NMEA data are coming. This can be useful when you are not on the boat (like at home).

You can give a default position (in the preferences), and it will be used when no GPS Data is available.
New features:
  • The tilt is based on the Sun declination
  • You can have Moonlight and Sunlight
  • The tide curve of the closest station is displayed (closest in a radius of 100 nautical miles)
  • Sun and Moon positions are displayed (when the body is visible)
Code and (some) doc are available on GitHub.

Thursday, November 19, 2015

Monitor the Boat, remotely

With a FONA connected on the Raspberry PI (where the NMEA Console is running), you can remotely monitor what's going on.
Sending a '?' returns the menu, all subsequent available commands are 1 or 2 character long.

The feature has been implemented - as usual - as a UserExit. This UserExit is in the Desktop repo, the FONA Java interface is here.
Add the following parameter to the command line:
 -ue:olivsoftdesktopuserexits.FONAUserExit

Just by sending an SMS, you can retrieve the data read by the Raspberry PI on board, like True Wind Speed, Battery Voltage, Air and Water Temperature, etc, all you need is a smart phone that can send and receive SMSs.

That sounds promising...

This assumes that the boat is docked in a place where there is SMS coverage, of course. I'm working on an Internet version, with a Particle Photon, or an ESP8266...

Thursday, May 07, 2015

Web Console improvements

With the Raspberry PI now able to behave as an Access Point, almost all devices can connect to it (Apple, Android, all kind of phones or tablets). Using an HTML5 enabled browser makes live easier than writing a dedicated application for the given Operating System.
That's why we now have some improvements in the Web Console:
See above the "Night" scheme, with or without borders for the displays
Same for the "Day" scheme.

The HTML5 console is accessed from http://machine:port/html5/console.html, default port being 9999.
If you have installed node.js and the WebSocket user-exit, then you access the WebSocket console from http://machine:9876/data/console.ws.html
It is still self-contained, no external framework is used (like JQuery et al). Those are great - for sure - but this is to be run on a boat at sea, with Internet out of reach.
Notice on the snapshots that several data come from some sensors hooked-up on the Raspberry PI. They can be shown or hidden from the preferences or from the Console Admin page.
Notice that the Console Admin page has been removed from the Console, it can now be accessed from a separate URL, on the admin port (8080 by default) at http://machine:port/html5/admin.html, started when the console is in headless mode:
The default values on the pages above come from the Desktop Preferences.
And there is now a CLI (Command Line Interface) for to access those preferences from a non-graphical environment (like on the Raspberry PI).
The class to launch is olivsoftdesktop.PreferencesCLI. An entry will added soon in the User Interfaces.

All this runs fine on the Raspberry PI, all the snapshots above have been taken with the Raspberry PI run node.js as server.

An idea...

Anyone with a smartphone or a tablet can access those live data. The problem is to type in the right URL...
Once you have chosen your configuration (IP address and ports), you can generate QR Code (https://www.the-qrcode-generator.com/ worked for me), print them, and post them somewhere in the boat. Whoever wants to reach the data just uses his QR Scanner - all smart stuffs have at least one - and boom! You're in!

HTML5 console

HTML5 WebSocket console

HTML5 Admin console
Those pages support query string parameters theme and border. theme can be 'white' or 'black', border can be 'Y' or 'N'.
Like in http://machine:9999/html5/console.html?theme=white&border=N

There are several QR Code generators, including some you can run off-line. This one works just fine, and can be installed on the computer on the boat, so you can generate your codes from anywhere. As you can see here.

Thursday, July 10, 2014

How the Raspberry PI makes sense on board

A computer can be helpful on board, for several reasons.
  • Some useful navigation softwares need one to run (SailMail, for example, that allows you to receive faxes through the SSB, send and receive emails, all kinds of useful things)
  • Some chart plotter softwares (like OpenCPN, the best) require a computer to run as well, to plot the current position on an electronic chart.
  • The on-board electronics can be read from a computer (through NMEA, or some other proprietary protocols), and the data they emit can be used as parameters for calculations, like performance evaluation, routing, current estimation (tricky, but so useful).

Electricity can be precious on board (specially on a sail boat, where it is in short supply), it is required to run several important devices, like the autopilot, the water maker, and to some extend, the fridge. A laptop can draw a substantial amount of current, specially if its battery is old (2 to 3 amps and more, I have evidences). In those conditions, leaving it on all the time can be questionable. On top of that, turning it down, and turning it back up takes time...

Serial port access

The data we are interested in usually (like in 99% of the cases) come from a Serial port (USB, or 9-pins). A big detail to mention is that a Serial port can only be accessed by one process at a time. That means that when your chart plotter accesses the serial port, no other program can access it, even it is is not the same data the other program is interested in.
The chart plotter will be interested in the GPS data, another soft might be interested in the wind data; but there is no way around, one program, one port.
GPSd does not address this issue (even if it pretends to), and - in my opinion - makes things more complex. It's only interested in GPS data (not in Speed Through Water, not in Wind Data, etc), but it locks the port like everyone else, and just rebroadcasts them in another bloody format! Why isn't it just rebroadcasting the NMEA sentences as they've been read?.., I have no idea.

Introducing the Raspberry PI

The Raspberry PI does much more than the boards like Arduino, Sparkfun, Beaglebones, and others (those are great, don't get me wrong, I am not spitting in the soup), it is a fully featured Linux (Debian) computer, that can - as such - do all a computer can do, like multi tasking, multi threading, remote access (SSH, VNC), network access (Ethernet and Wireless). It only has 512 Mb of RAM. But that is enough, as we will see. Its hard disk is replaced by an SD card, ranging from 4GB to whatever you want. I use 16Gb cards. And at work, it draws less than 500mA, which is ridiculous. You can plug several kinds of screen on the Raspberry PI, a TV screen using an HDMI port, or a rear camera car monitor (3.5", 4.3", or 7") using an RCA port. Turning those screens off when not needed will also contribute to save some energy.
The Raspberry PI can read the serial port - Ok, exclusively - and re-broadcast the data on whatever channel (TCP, HTTP, UDP, RMI, whatever). This way they can be accessed from this channel, the data remaining the same. As soon as a device is turned on, it can join the ad-hoc network created by the Raspberry PI, and immediately read the data it broadcasts.

A program like OpenCPN is smart enough to support several kinds of channels.
HTTP is also an option to consider, smart phones and tablets are ready for that, without any modifications. HTML5 and CCS3 will do the job. Those devices have browsers that understand those technologies. It is very easy to display the data read by the Raspberry PI on an iPhone.
In addition, the Raspberry PI can log the data read from the NMEA Port, its SD card is big enough to log several days of data. Another feature of the Raspberry PI is its GPIO Header. This is the bridge to the world of sensors. For example, the BMP180 will allow the Raspberry PI to read the air temperature and the atmospheric pressure. Those data can very well be injected in the NMEA stream (they both have an NMEA equivalent). Some navigation station already provide this kind of interfaces, but in case yours does not, you will then get those data for less than $10.
See some implementation details here.

Even further, it is not difficult to come up with a small setting the Raspberry PI can use to monitor the tension of the batteries on the boat. This one does not - as far as I know - have an NMEA equivalent. It can be injected in the NMEA stream though, it will be considered as a custom sentence. And it can be logged too, along with the rest.
If needed, the data can be displayed on the Raspberry PI as they are read. I did some tests with a graphical interface, as well as in character mode, just to keep the energy consumption as low as possible. The screen is turned off when not needed, for the same reason.

Useful links



Basically, you can reproduce the settings used during the last Aremica's Cup, for a tiny fraction of their budget! The Raspberry PI is less than $40.
Compare with this...

If it does not work for you, do let me know, it should. I might be able to help.

Sunday, July 29, 2012

NMEA Station Calibration

We intend here to show the importance and the impact of an accurate calibration and tuning of your NMEA station, in order to correctly evaluate the parameters to calculate, namely the current direction and speed. The impact of an incorrect tuning leads to completely useless computation, and wrong evaluation of the expected parameters.
For a better understanding of the mutual impact of all those parameters, we've illustrated this document with several interactive applets, which you can play with or interact with the different parameters for yourself.
Values in fields can be changed (hit the [Enter] key for that, after modifying the value in the field), sliders are draggable with the mouse, as well as the compasses that figure in the applets, to change the various headings.

Steps

In order to log and visualize data efficiently, you need to complete several steps, in a specific order:
  1. Instruments Calibration
    You need to make sure the values read by your instruments are accurate
  2. Polars Elaboration
    You need to know what your speed should be in the condition you sail in
  3. Data Logging
    You need to log the right data
  4. Data Visualization
    You need to render the logged data appropriately, rate your tacks and gybes, visualize laylines and frames, etc.

Instruments Calibration

Most of the in-board NMEA stations provide access to calibration parameters that will lead to an accurate data logging and display. The goal of this process is to evaluate the parameters we will need to feed the NMEA station with.
You need to simulate the values of the parameters to enter in the NMEA station. This process follows several steps:
  1. Log data on the boat
  2. Display the data in some graphical dashboard
  3. Elaborate the calibration parameters until the display looks good
  4. Set the calibration parameters in the NMEA station
  5. Log again, to make sure your evaluation of the tuning parameters was right

Polars Elaboration

Polars are a mathematic and theoric model that will tell you what BSP you should theorically reach for a given TWA and TWS.
Polars can be used to predict your potential track (routing), or to rank your boat handling.
There are two main ways to get the polars of your boat:
  • VPP (Velocity Prediction Programs)
    Those data are (or should be) provided by the designer of your boat.
  • Logging
    In case your designer did not provide them, or if the VPP is wrong...

Data Logging

For an appropriate rendering of your performances, you need to log the right set of data. The format of the data logged by your navigation station is NMEA.
Depending of the data your station is able to produce, you will have to choose the right ones.

Data Visualization

The main question to address is "What do you want to see?". And there is no ready-made answer to that question.

To summarize

  1. Appropriate Calibration leads to the right evaluation of the True Wind (Angle, Speed and Direction) and of the Current (Speed and Direction)
  2. With the right evaluation of the True Wind, you can refer to your polars, so you know what your speed should be
  3. Having logged the right data, comparing them to what the polars tell you, you can evaluate your performances
  4. Based on the evaluation of your performances, you can render your data appropriately, see where you did good, and where there is room for improvement


Instruments Calibration

Calibration impacts the data read on the boat through the devices attached to the NMEA station, like the boat speed transducer, the compass, the wind vane, and the anemometer.
We want here to
  1. show how the different data interact with each other
  2. see how to apply calibration factors (coefficients and offsets) to the values read from the station

The data are logged on the boat, that carries the devices (speedometer, compass, wind vane, anemometer).
It is far from unusual to have to tweak or tune those devices.
The anemometer is usually the most reliable one, as it is running away from most of the interferences that make the other devices in need for calibration.
For example, the compass and the wind vane could have been installed not exactly in line with the boat. This means that an offset is to be applied to the data they read.
Depending on the location of the boat speed transducer, the speed of the molecules of water does not necessary directly reflect the speed of the boat. A difference can even be seen from one tack to the other. A coefficient might then be required.
Many data can be recorded, we're only - in this document - going to talk about the data we need to evaluate the performances of the boat.
For example, DBT (Depth Below Transducer) is useless for us, in the framework on this document.
The main data recorded by the instruments are:
  • Boat Speed (BSP), sometimes aka STW (Speed Through Water)
  • Heading (HDG, HDM, HDT)
  • Apparent Wind Speed (AWS)
  • Apparent Wind Angle (AWA)
  • Boat Position (from the GPS)
  • Speed Over Ground (SOG)
  • Course Over Ground (COG)
One data is to be estimated:
  • Leeway (see about that the section about Damping)
    Mostly depends on AWA, AWS, and sea state (that involves waves, swell direction... pretty tricky).
The main data computed, based on the data above, are:
  • True Wind Speed (TWS)
    Depends on COG & SOG, AWA, AWS.
    Not on BSP & HDG, as usually admitted.
  • True Wind Angle (TWA)
    Depends on COG & SOG, AWA, AWS.
    Not on BSP & HDG, as usually admitted.
  • True Wind Direction (TWD)
    Depends on TWA, HDG
  • Current Speed
    Depends on BSP, HDG, SOG, COG, Leeway.
  • Current Direction
    Depends on BSP, HDG, SOG, COG, Leeway.
Note: The tuple (SOG, COG) is semantically (in this case) equivalent to the Boat Position. Both (SOG, COG) and Boat Position come from the GPS.
A note about BSP calibration:
This one can be very tricky, specially if the transducer is not exactly set in the axis of the boat, as it is usually the case.
When you're sailing upwind, depending on the tack, the reading may substancially vary, as for a given speed, the pressure of the water molecules on the transducer is definitely not the same on both tacks, the difference of reading between tacks being more or less proportional to the heel.
To address that issue, most of the NMEA Stations provide a way to set the boat speed calibration for each tacks.
Unfortunatelly, this is not good enough, the Apparent Wind Angle should be taken in account as well. You certainly do not want the same coefficient to be applied on the boat speed when you are heading close hauled or running downwind.

Calibrating the Boat Speed and Heading

Here is an interactive applet:

This browser does not support Applets.
This applet shows how to evaluate/compute the current. It provides the possibility to interact with the calibration parameters and see how they impact the final resiult.
Use the sliders in the applet on the left to modify the values of Boat Speed (BSP) and Leeway.
To change the Heading (HDG) value, drag the mouse over the compass.
Course Over Ground is fixed, set to 80°.
Speed Over Ground is fixed, set to 5.5 knots.
Both COG and SOG come from the GPS.
Current Speed & Direction are computed based on the five values above.
In green, data read from the NMEA Station
In red, parameters used for computation
In blue, computed data

At the bottom, are two calibration parameters.
The BSP Coefficient is applied to the Boat Speed.
The HDG Offset is added to the Heading.
To modify a parameter, change its value, and hit the [Enter] key.
The display on the right side render the value read by the station. The pane on the left displays the corrected values, used for the computing of the current.

Something to say about leeway:
Leeway - mentionned above, and used below - is a dimension proportional (among others) to the Apparent Wind Angle (AWA), and not the True Wind Angle (TWA).
The Apparent Wind is the wind moving the boat.
Sailing on a very fast boat (like a racing multihull, an ice-boat, etc), it is not unusual to fell the wind on the nose, and see the wind-generated waves (not on an ice-boat, I know) coming from the quarter. The sails are trimmed according to the Apparent Wind, and the force they generate is expressed accordingly.
If your sails are trimmed as if you're going upwind (i.e. up the Apparent Wind), then you make leeway accordingly.
Picture this:
Sailing in the same external conditions (TWD, TWS), we have two boats, well trimmed, sailing at about 135° of the True Wind (TWA=135°):
  • A cruising monohull, sailing between 6 and 8 knots
  • A racing multihull, sailing above 25 knots
The first one will be sailing with the spinnaker up.
The second will have - in the best case scenario - a closed hauled gennaker.

Obiously, their leeway will not depend on the same parameters.
The fast boat will make more leeway than the cruising one, because of his close hauled sails.
For now, in the Dashboard Preferences, you have a value named "Max Leeway". This value will be used in conjunction with the Apparent Wind Angle, when it is between 0°and 90°, as follow:
Leeway = MaxLeeway × cos(awa)
This browser does not support Applets.
The True Heading, corrected with the Leeway is called Course Made Good (CMG).

Calibration of the Compass

Usually under-estimated! You think that because you sail on a plastic boat, your compass does not suffer any deviation... Think again!
Unless you have a gyroscope, you will need a compass to know what your heading is. Your heading is the base of many calculations, see above.
The first parameter to take in account id the magnetic declination, noted D. This Declination depends on your location, and the time. It varies with time, because the magnetic pole navigates around the geographical one. Any nautical chart will tell you what the declination is in the region and at the time your sail. You can get its value from several web-sites, including the NOAA's one. The RMC sentence also returns this data. Some computer algorythms are also available to calculate this important datum. Declination is the same for everyone sailing the same waters at the same time.
This is not the case of the deviation. The deviation is a parameter depending on the boat you sail. It is generated by the magnetic masses around the compas. As such, it depends:
  • On the boat (holding those magnetic masses)
  • The heading, as those masses "move" around the compass.
Steel boats have a big one, ferro-cement ones have a huge one (50° is not absurd for them...). Plastic boats, you never know! A loudspeaker close to a compass will have quite an impact on its reading... An engine (or a generator), same. When the engine is running, it might even be different... There is a lot of litterature about this topic, go check for yourself if you are interested.

This browser does not support Applets.
The generic shape of a deviation curve is
d = A + (B.sin(Z)) + (C.cos(Z)) + (D.sin(2.Z)) + (E.cos(2.Z))
where Z is the magnetic heading. The deviation curve represented on the left is following this equation.

This interactive applet shows the 3 different headings: True, Magnetic, and Compass.
The Compass is the displayed (and recorded) one.
You can modify the value of the Magnetic Declination.
Plus (+) is East, minus (-) is West, for Declination and deviation.
The algebric sum of the Declination and of the deviation is called Variation, noted W.

The true heading is the one to be plotted on the chart, as the chart too refers to the true North (a.k.a. Geographical North).
The compass calibration is crucial. The data it provides is a parameter of all the computations we are interested in. If the deviation is not taken in account, its value will be put on the current's account, and that would be a big mistake.

Calibration of the Apparent Wind Speed and Direction


Here is another interactive applet. Like before, you can use the sliders, modify the values in the fields (hit the [Enter] key in the field to apply your changes), and drag the compass' rose left or right.

This browser does not support Applets.
This one shows how the calibration of the station interacts with the computation of the True Wind, which is the key to access the polars.
The displays (on the right) are the one you would see on the boat when sailing, the data displayed on the main pane, on the left, are the (ideally) "real" data, taking the calibration parameters in account.

Warning:
This vector combination is the usually admitted one, but this is a simplified one!
The real one - closer to the truth - will be exposed next.

Let's now go closer to the truth...
Unlike what's commonly admitted, the True Wind should be calculated with the Speed Over Ground and the Course Over Ground, instead of respectively the Boat Speed and the Heading.
Imagine that: you are "sailing" in absolutely NO wind, but you have a strong current, about 6 knots. Well, in that case, you feel an apparent wind of about 6 knots. If you do the calculation of the True Wind with the Boat Speed, the calculation will return a True Wind of 6 knots, in the direction opposite to the current.
But if you do it with the Course Over Ground and Speed Over Ground, then it will return a True Wind Speed of zero knot, which is right.
If the GPS data are available, they should be preferred for this computation.


This browser does not support Applets.
This one contains all the possible parameters (for now...), and computes the True Wind with the GPS Data (SOG & COG).

For the clarity of the figure, Compass calibration parameters (deviation curve) are not represented.

All the values are modifiable like previously. Heading and Course Over Ground have their own compass' rose, which is dragable on both cases.

As you can tell, the figure is quite complex. And it becomes even more complex when you modify the data and parameters.
Again, it is very difficult to isolate the parameters from each other, modifying one value impacts mostly all of the others...

As a matter of fact this reflects the reality of an NMEA Station calibration. It is a long and precise process, which should not be under-estimated.

Ultimately, what we look for here is the direction and the speed of the current, represented in green on the applet on the left, as this is what we will compute the route to give to the driver with, decide when to tack, etc.
All the parameters we mentionned so far have a direct impact on this evaluation. If one of them is wrong, then the evaluation of the current is impacted.


Full validation: Stability of True Wind Direction and Current Direction

Now, let's put all the parameters together, as in the real world. The main difficulty is precisely due to this fact, there is no clear way to isolate them...
Below is the display of some data logging, the logging is done with a non-well calibrated NMEA station.
It displays two legs upwind, and two legs downwind.
The True Wind Direction is displayed in blue, the Current Direction is displayed in red,
The vertical panes on the left display the True Wind Direction (TWD), and the Current Direction (CDR).
The horizontal panes display the Boat Speed (BSP), True Wind Speed (TWS) and Current Speed (CSP).
TWD, CDR, TWS, TWA and CSP are calculated, based on the data logged on board. Any error in the data read from the devices (BSP, HDG, AWA, AWS) will deeply impact this calculation.
You can impact the parameters to apply on the data read from the station by modifying their values on the right pane of the applet.
See how the current direction varies everytime the boat heading is changing... The TWD is less impacted, but it is not steady either.
This browser does not support Applets.
This interactive applet represents data logged with a non properly calibrated NMEA Station.

Play with the parameters, to see how they impact the rendering of the track. To modify a value, change the number in the field and press [Enter].

There is a slider you can use, just above the BSP Panel at the bottom.
To display the right data, you must enter the following parameters:
  • Multiply BSP by 1.1
  • HDG Offset 5°
  • Multiply AWS by 1.01
  • AWA Offset 2°
  • Max Leeway 10°
Those paratemers should be used later on to calibrate your NMEA Station.

Ideally, when the parameters are set correctly, the graphs rendering TWD, CDR, TWS & CSP should display a straight line. (Assuming of course that the wind and current conditions were stable during this logging session)
For now, the leeway is calculated as a function of the Cosinus of the AWA, from 0 to 90 degrees only (we assume no leeway beyond 90° of Apparent Wind Angle).
This is likely to be improved.


Data Logging

Logging everything the station produces is a possibility, but it can be a lot, and saturate the recording device.
For the best rendering, you need to log at least:
  • The Boat Speed (BSP)
  • The Boat Heading (HDG, HDM, or HDT)
  • The Apparent Wind Speed (AWS)
  • The Apparent Wind Angle (AWA)
  • The Boat Position
  • The Course Over Ground (COG)
  • The Speed Over Ground (SOG)
Those data can be found - for example - in the following sentences:
Required DataAvailable in NMEA Sentences
Boat Speed VHW
Boat Heading VHW, HDG, HDM, HDT
Apparent Wind Speed MWV, VWR
Apparent Wind Angle MWV, VWR
Boat Position RMC, GLL
Speed Over Ground RMC, GLL, VTG
Course Over Ground RMC, GLL, VTG
The NMEA sentences mentionned in the table above have the following meaning:
VHW Water Speed and Heading (Velocity Heading Water)
HDG Heading, Deviation & Variation
HDM Heading, Magnetic
HDT Heading, True
MWV Wind Speed and Angle
VWR Relative wind direction and speed (Velocity Wind Relative)
RMC Recommended Minimum Specific GPS/TRANSIT Data
GLL Geographic Position, Latitude/Longitude
VTG Track Made Good and Ground Speed
Note: RMC gives the boat position just like GLL, but also returns the Magnetic Declination.


Data Visualization


Damping

The damping is the kind of smoothing that will eliminate the aberrations. This is specially usefull when the data are logged in tough conditions. For example, when you are sailing upwind in choppy seas, the wind vane being set at the top of the mast will be shaked substancially. This will generate some data that will not reflect the reality.
The damping is taking for any given logged point X points before,and X points after, and calculates the average.

This browser does not support Applets.
Use the slider to change the damping factor.
Several panels of the Dashboard provide access to a damping factor.

A note about current evaluation

The way we've calculated the current so far is based on the values read and calculated at a given moment in time (BSP, TWS, TWD, COG, SOG).
Some of those values are themsleves based on others (TWS & TWA are based on BSP, CMG - based on HDG, leeway, Declination and Deviation -, SOG, COG.
The current calculation we've shown so far is a triangulation based on instant values.
Basing the calculation on damped values does not really help, but there is another way to smooth those values. We have seen that the current is the vector that sits between the tuple (CMG, BSP) and the tuple (COG, SOG).
The idea here is to evaluate over a period of time this difference between the position where the boat is, and the position where it should be with no current.
We can even simultaneously evaluate the current with different period of time, like 1 minute and 10 minutes, for example. This would be usefull when the boat heading is changing, for example when tacking or rounding a mark.
after one tack
After one tack. See the different values in the three panels
after two tacks
After two tacks. See the different values in the three panels
after two tacks, motoring head to wind
After two tacks, motoring head to wind. See the different values in the three panels
Notice in each case the differences between the current speeds, and current directions.

Evaluate and rate your tacks and gybes

We'll be talking here of the method well-known under the name of "Tack Loss".
Its principle is simple, and it is the same for tacks and gybes; we'll expose it for a tack, you'll be after that able to transpose it to a gybe.
  • You're sailing upwind at a constant speed
  • You evaulate you VMG (Velocity Made Good)
  • The tack begins
  • After the tack, and after a given amount of time, you're sailing on the other tack, and you've recovered your best speed
  • This is when the tack is being rated:
    • You calculate, based on the VMG before the tack, how far upwind you would have been if you had not tacked
    • You see how far upwind you actually are
    • You compare the two (the difference is evaluated in meters)
The tack loss is not - as one could expect - always negative. If you appropriately tack in a wind shift, you might have very good ratings!
The opposite can be true as well...
The tack loss is usually evaluated as a distance, measured - even on American and English boats - in meters.
It can also be rendered as a percentage, as we're going to explain.
A tack can be decomposed is three main steps.
  1. You're heading full speed, and you begin the tack. Your VMG increases, due to the momentum of the boat
  2. The boat not being anymore powered by the wind, and having the wind on the nose, the boat (and the VMG) slows down as the wind is crossed
  3. The boat bears away, about to re-catch the wind, the sails will soon be trimmed on the other tack, the boat is recovering its speed
The steps described above correspond to this figure:
Rating the tack as a percentage corresponds to the comparison of those two areas (in grey):

this area in grey...

... with this one.


Next time, we'll talk about the data rendering.
It's also a pretty vast topic.

Monday, June 25, 2012

NMEA Rebroadcasting

This post is more like a question...
This is always the same problem, most of the NMEA devices use a Serial Port, which is always accessed exclusively (i.e. by no more than one program at a given time).
The way around this exclusive access is to have the exclusive reader to rebroadcast the NMEA data using another channel, accessible from several other programs. This other channel can be HTTP, TCP, UDP... Those channels are machine, system and language agnostic. From Java to Java, RMI is also an interesting alternative.
SailMail reads the NMEA Stream to get the position of the boat, and thus is able to find the best SailMail station, provides the possibilty to rebroadcast the data it reads. Available channels are TCP, UDP, and even COM (rebroadcast on another serial port). It rebroadcasts the NMEA Sentence as it has been read, assuming - appropriately in my humble opinion - that if it is NMEA you are interested in, you know how to parse it.
There is also something else, which OpenCPN is aware of, this is GPSd.
It runs as a daemon - on the systems where daemons exist - and is only good for GPSs, not all the NMEA messages, because it's rebroadcasting the data after reworking them in another format, some proprietary classes over json (JavaScript Object Notation).
The GPSd protocol is not exactly documented, and the project leader does not return my emails...
In the NMEA Console, you can read any of those channels (Serial, TCP, UDP, RMI) and rebroadcast on HTTP, UDP, TCP and RMI (simultaneously if needed). I'm also working on a GPSd rebroadcast, running anywhere Java runs (no need for a daemon).
Anyway, both approaches have pros and cons (even if I'd rather rebroadcast the data as they come).
If anyone has any comment or idea, please speak up!
Thanks in advance.