Hardware Design, optional modules

Well, these are not going to be optional, they will be installed from day 0. It is more that the use of them is for providing lesser importance services, that is, things someone can live without.
But since someone can live without all of this ship computer, this is not much of a distinction, is it!

Back to the subject, the "optional" modules that will be used from day 1, have as follows:

1. Barometric Sensor (BMP085)

This one:

This is an I2C device and as such, it will be connected the same way the magnetometers are.
Obviously, this will be used for providing Atmospheric Pressure and the UI will also have a graph of the atmospheric pressure of the last 24 hours.

2. Accelerometer (ADXL345-based)
This one:

I2C-based. Will be used for logging of the sea condition. It's a bit of a gimmick but the readings could also be used as inclinometer!


3. Noise Sensor

This will be placed under the cockpit, to the left side of the boat, as close as possible to where the outboard is fixed. That way, there's going to be a engine run-hours log! (I might add tachometer functionality at a later stage).

4. Ampere Sensor
The whole system relies on a single 12V battery for operation. I have a solar panet and charger, by using a Ampere Sensor connected straight to the battery, I will monitor charging and discharging.
The sensor that will be used is this one:

This sensor has an analog output, which has the value VCC/2 when there is no current flowing, and it changes 185mV per Ampere flowing plus or minus the 0 Amp voltage depending on the direction of the current.
That way, I can have an indication of charging or discharging of the battery and the amperage of the current.
This sensor will by connected to the I2C ADC board that was mentioned on the previous post.
Now that I am to it, and since there are 5 analog unused inputs, I might use an input (through a voltage divider) to measure battery voltage.

That's it about the additional hardware, on the next post I will provide descriptions of system operation, both for version 1 and version 2 of software.

Regards!

Hardware Design, essential modules.

I will be using Raspberry PI's I2C interfaces for connecting the modules.
The hardware that I will be using has as follows:

1. Raspberry PI Model B, Version 2.

Since Ethernet connectivity is not needed and in order to minimize power consumption, model A could be used in field. That said, during development and testing, model B will be used.

2. The digital Compasses will be based to a HMC5883L Triple Axis Compass Magnetometer Sensor Module:

This module is I2C based.
I2C bus enables multiple devices to get connected to the master device (in this case the Raspberry PI), as shown in the following image:

The I2C devices have a 7-bit address so there can be up to 127 interconnected devices in a single bus, as long as these devices have different addresses.

The problem is that on these devices I cannot change the address, and I need to connect 2 of them!

Luckily, Raspberry PI Model B V2 (and any Model A) has available a second I2C bus, as shown in the Raspbery Schematics and described here.

So the simple solution is to connect each of the magnetometers to a different I2C bus (problem solved!).

3. The existing apparent wind direction indicator produces two analogue values. In order to read them I will use an I2O-based A-to-D converter, probably this one:

Information on using and programming this module are shown here.
This is a 8 port A/D converter, for the apparent wind direction I will be using 2 (6 left, one will be used for power consumption measurement, see later!)
The relation between this values and the wind direction, will be mapped manually, by means of testing.
(UPDATE: I bought one of the above but couldn't make it work, so I opted for using a Adafruit ADS1115 instead. The Pi Chips PO11 ADC not working could be of my fault, I will investigate whenever I find time to do so...)

4. The apparent wind speed is measured by the wind cup rotor that produces a number of pulses per revolution. I intend to feed these signal to a I/O port (via a voltage divider) and use interrupts in order to measure the width of the pulse without wasting precious CPU cycles on the Raspberry.
The actual way to do it is described here.


5. The last essential module is a GPS that will communicate with the Raspberry through the Serial port.
I have bought this SUPERB GPS module:

It's so good I will probably keep it for a project that a 10Hz refresh would be crucial, Instead I will probably use a TTL version of the Garmin 18-5, that has been left from behind a previous project some years ago:

The serial connection on the RPi is described here.
Everything needed for connecting the GPS, programming it and using it can be found here (Thanks Adafruit for everything!)

This concludes the description of the essential modules.

Ship Computer V1, Initial Hardware Design

I will be using a Raspberry PI as the heart of the system.
In order to have a working system, we need various readings, and have the corresponding sensors connected to the PI

The compulsory sensors/readings have as follows:

1. Magnetometer (Compass Sensor) for indicating the boat magnetic heading
2. Magnetometer for the mast in order to calculate mast rotation.
3. Existing apparent wind direction indicator, interfaced to Raspberry PI
4. Existing wind speed indicator, interfaced to Raspberry PI
5. GPS unit, for calculating Speed Over Ground (SoG) & Course over Ground (CoG) etc

These measurements would be logged to a database.

Using these measurements, the system would also be able to calculate the following:

1. Apparent wind direction using the mast rotation (the difference of the two magnetometers, one on the boat and the other on the mast) and the data from the apparent wind direction indicator.

 2. Real Wind Direction and Real Wind Speed using data from GPS (SoG & CoG)

3. Leeway angle (from boat magnetic heading and CoG)

Additional but not critical sensors that can be added in version 1 of the ship computer could be:

1. Barometric Sensor for logging atmospheric pressure
2. 3D accelerometer for logging sea conditions
3. Current Sensor Module, that will be used for logging of battery charging and power consumption.

Ship Computer Requirements, Software Versions and functionality

OK, on my previous post I tried to sum up the situation.
Here, I will describe my needs, what I want from a ship computer.
In the next couple of posts I will describe the design, and possibly some draft of the implementation.

So, what I need.

to start with, I need to have indication of apparent wind angle. Now, one might thing that this is rather entry-level requirement, why do I have to create a custom device in order to have this indication? simply because I have a rotating mast!

the next obvious requirement is to have apparent wind speed (Kn).
This should be straightforward, at least when the wind cups rotor works!.

Then I want to have magnetic heading and course (GPS) heading, along with Speed Over Ground.

Having this measurements, it is easy to calculate True Wind Speed, True Wind Angle and leeway.

More functionality and measurements will be added in subsequent development cycles.

To sum it up, the basic info I want to have, are as follows:

1. Apparent Wind Speed
2. Apparent Wind Angle
3. True Wind Speed
4. True Wind Angle
5. Speed over ground
6. Heading
7. Course over Ground
8. Leeway angle (=heading-CoG)

I want to have realtime update for these as well as logs.

This is for version 1 of the software.
For version 2, I will provide mechanism for uploading route and waypoints so that I can have VMG and ETA calculated in real time.

The ship computer will be headless.
It will be equipped with 2 Interfaces, a WiFi setup as Access Point, and a Bluetooth.
A third interface could be added, that of a GSM/GPR/3G usb modem, in which case the Ship Computer when within 3G/GSM range, could provide Internet Access for all onboard and the same time push on a land-locked server, info on it's whereabouts and environment, providing means of fleet management (this functionality will come on Version 3 of the software).

In all software versions, the UI will be divided in Primary UI and Secondary UI.
 
The PRIMARY User Interface will run on a tablet (an iPad on version 1, might use android for subsequent versions).
Through the Primary User Interface, the Ship Computer will:
In Software Version 1 report to the user all values, either collected or calculated. Early version of the V1 UI could be made up as a web page created by a apache server running on the ship computer, but eventually, Version 1 UI should be a native tablet application with lifelike instruments, animated needles, etc. Version 1 UI shouldn't need two way communication, the information flow should be only from the Ship Computer (the server) to the Version 1 UI (the client).

Software Version 2 UI will be a native application built on Version 1 but will additionally provide:

• MapView, that will enable route creation.
• Ability to upload route(s) to Ship Computer
• Ability to activate specific route
• Ability to show on map current position along with heading

Needless to say, the virtual instruments should be visible or readily available.

In Software Version 3, the UI should be almost identical to V2, the main difference being on the software running on the ship computer itself that should be able to send regular notifications with location and other critical information (heading, speed, sea condition (see the 3D accelerometer, later in the descriptions) etc. Also V3 of the software would need server-side software for collecting these info and for presenting them to users (users could be from your mom that wants to know you are sailing safe, to the yacht charter administration office that needs to know your whereabouts in order to better assist if required)

I have started talking on the Primary UI and ended up on the V3 Server-Side software!

So let's go back to the UI!
As said before, there's going to be a SECONDARY UI too.
This will be a one way (ship computer to device) communication, that will provide quick notification on major metrics, eg Speed Over Ground (SoG), Course Heading, Wind, etc.
On VERSION 2 of Secondary UI there's also going to be VMG, Distance to next Waypoint, ETA to Next Waypoint, ETA to Finish. etc.

I have decided to implement the SECONDARY UI on a PEBBLE watch:

The Pebble smartwatch is a fully programmable device (the SDK is freely available for download) and in contrast to most of the other SmartWatches or GPS Watches, it doesn't try to do all by itself, it doesn't even have a GPS!.
Instead, being programmable, it can communicate with a master device (server, smartphone etc) and get functionality through the other device's mechanisms.
It is slim, light, with a great paperwhite display, it's a breath of fresh air! (check out reviews on the net, eg  this one).

For the secondary UI to work, the Pebble should be paired over bluetooth with the Ship Computer.

The secondary UI will word independantly of the Primary UI, that is, the tablet can be turned off, run out of battery, fall in the sea or whatever, the Secondary UI will still work.

(just for the record, my initial design was with the Pebbled paired on the tablet, that might have been easier to implement but the Secondary UI would be tied up to the Primary. Instead of doing so, I added a bluetooth dongle on the Raspberry PI and set up communication between Raspberry and Pebble using libpebble, a library for OSX and linux, which I installed on Raspberry.)

Anyway, enough said, will provide all info on the solution presentation on a later post.

The Ship Computer, intro

Hi all!

I set up this blog in order to keep notes on the development of what I call "the Ship Computer"

Some background notes first:

I have a Corsair F24 MKII.
This is a small trimaran, a pocket cruiser and (in other parts of the world) a racer.
It is this one:

It's great fun to sail, on the proper conditions it is much faster than what you would expect from a normal boat (i.e. monohull) of that size, and because of the nets, it has enough room to be used as a summer cruiser, sort of sailing camping that is, luxuries are what you would expect when backpack camping in the mountains. That is, the bare essentials and possibly a bit less than that!

Now, the boat has a rotating mast that is supposed to reduce drag and help with the mainsail shape on the luff. As a side effect, causes wind indicator to go bananas.

The same time, the instruments on board are not sufficient.

I have a GPS-Plotter that has north England and Scotland on rom. Living in Athens and sailing in Saronic gulf, the plotter is of not much use to me.
The GPS itself, without the plotter, has a 20-year old UI. It used to be nice if all you wanted was to get the current coordinates and plot it in a normal (paper!) map, but who does this nowadays (I don't...), adding waypoints and marking them is a total pain, and hence I tend to keep it switched off.
The wind instrument, a low-budget "NASA Clipper" is, as I said, of no use for showing wind direction and lately is also failing to show the wind speed, sometime this winter I'll take down the mast and check the transducer, hopefully it won't need replacing.

The "instrument" I use most onboard is my iPad with Navionics Marine:Europe HD app, placed in a waterproof(-ish) case.

From time to time, I also use a GPS-equipped watch (I had a Garmin 305 but it proved to be too fragile and I replaced it with a Sunnto Ambit) that I use for track recording and instant speed monitoring.

For electricity I have a single 12V battery, a 120W (nominal) semi-flexible solar panel and in case of emergency, the battery can by charged through the outboard that has a 60W charging coil.

Since I have been sailing mostly shorthanded (double-handed most of the time) I am also, when weather permits, using a Simrad tiller autopilot.

To make the long story short, I am not happy with the instruments I 've got.

I guess, I could go out and search for the instruments that fit my requirements. This has two disadvantages: 1. Cost 2. I have specific ideas on what I want and and I feel no matter how much money I spend, I won't be satisfied with the result.


So,  I decided to design and build my own "Ship Computer".

Simple as that.

More on the next post...