G.9.2) GPS & Fishfinder v1



(See also DIY Bathymetric Mapping)

Introduction.

My current boat is fitted with a Garmin GPS, a Garmin FishFinder and a fuel flow sensor. All of these are potential sources of interesting information. Having tried to process data with a VB.Net application running on a netbook proved tricky - the software was huge, there were timing issues and the netbook wasn't always as robust as might be needed.

This ended up being 'Project of the Week' on the Parallax website.

The Challenge

The challenge was to gather all of the useful data from the GPS, the Fishfinder and the fuel flow sensor and write it to an SD card. The three lots of data are not synchronised in any way - making it an ideal task for a Parallax Propeller. Why? Well, let me explain...

Functional Architecture

The Propeller is a great little micro-controller. As an almost blank sheet of paper it has eight separate processors (cogs) kept in step by a central hub that also has 32 Kb of RAM. Start to add software objects and all of those cogs can start to be put to some use, without any restrictions on hardwired input/output connectors, etc. It doesn't need any interrupts - at all. Ever! I didn't need all of the cogs but I allocated:
  • One cog to the receipt of GPS data. References to an open source object provide an RS232 interface capable of receiving NMEA-0183 data. All it has to do is keep looking at the incoming GPS data and strip out the useful parts.
  • One cog to the receipt of FFdata. References to an open source object provide an RS232 interface capable of receiving NMEA-0183 data. All it has to do is keep looking at the incoming FFdata and strip out the useful parts.
  • One cog to the receipt of Fuel flow pulses. All it has to do is sit there counting pulses from the fuel flow sensor and updating the quantity in a global variable.
  • One cog is dedicated to monitoring the position of the 'on-off-on' three position momentary-make switch.
The main code could take as many of the remaining cogs as it needed. It included another RS232 interface for the connection to the LCD display and an SPI interface to the SD card holder.

The SD card holds a file "calib.txt" which contains a three digit number that represents the volume of fuel associated to each pulse from the fuel flow sensor. The specification of the flow sensor states one pulse per 0.4 ml; experience measuring fuel usage against the amount of fuel required to re-brim the tank suggests this is slightly too much - a value of "393" in the calib.txt file tells the Prop that each pulse is worth 0.393 ml of fuel.

Figure 1: Overview of Functional Architecture.


NMEA-0183 Data

There are a huge number of sites providing information on NMEA-0183 datastreams from all sorts of devices. NMEA stands for National Marine Electronics Association and standard 0183 describes the format of information transmitted to/from devices that might be found on vessels of all sizes. I was interested in two:

GPS Data

The image below (taken directly from the comments included in the code, shows the structure of the GPRMC word transmitted by the GPS unit.

The GPS code sits there reading the data stream, looking for the leading '$' and the asterisk towards the end of the sentence. If the word starts with 'GPRMC' the fields transmitted are processed (other sentences are transmitted but they are not directly relevant). Fields such as speed are converted to decimal values for subsequent manipulation and storage.

Figure 2: GPRMC Sentence.

(click to enlarge)

                                                        ┌───────────────────────────────────────────────────────────────── Header
                                │     ┌─────────────────────────────────────────────────────────── Hours
                                │     │ ┌───────────────────────────────────────────────────────── Minutes
                                │     │ │ ┌─────────────────────────────────────────────────────── Seconds
                                │     │ │ │    ┌────────────────────────────────────────────────── Latitude     
                                │     │ │ │    │          ┌─────────────────────────────────────── Longitude
                                │     │ │ │    │          │           ┌─────────────────────────── Speed
                                │     │ │ │    │          │           │     ┌───────────────────── Course
                                │     │ │ │    │          │           │     │     ┌─────────────── Day
                                │     │ │ │    │          │           │     │     │ ┌───────────── Month
                                │     │ │ │    │          │           │     │     │ │ ┌─────────── Year
    Array ref: 'Tens →          0     0 0 1    1          2           3     4     5 5 5  ┌──────── Magnetic variation, that we don't care about!
     Array ref: 'Units→          0     6 8 0    5          6           8     4     0 2 4  │      ┌─ From this point on is only CRC. 
     Typical Sentence:          $GPRMC,123519,A,4807.038,N,01131.000,E,022.4,084.4,230313,003.1,W*6A                                
    We need (•="Needed"):       X••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••XXX
    i.e., 12 comma-delimited fields + trailing comma

    

Fishfinder Data

The image below (taken directly from the comments included in the code, shows the structure of the SDDBTword transmitted by the GPS unit.

Figure 3: SDDBT Sentence.

(click to enlarge)


                                    ┌───────────────────────────── Header - used to identify the start of the data
                                    │     ┌────────────────────── Depth
                                    │     │     ┌──────────────── Feet
                                    │     │     │ ┌────────────── Depth
                                    │     │     │ │    ┌───────── Meters
                                    │     │     │ │    │  ┌────── Not used by this code
                                    │     │     │ │    │  │┌───── Asterisk marks the end of the data in which we have an interest
                                    │     │     │ │    │  ││┌──── Checksum - no use to us.
    Array ref: 'Tens'  →            0     0     1 1    2  222
    Array ref: 'units' →            0     6     3 5    0  234
    'Typical sentence:              $SDDBT,XXX.X,f,22.5,M,,F*cs
    'We need(•="Needed"):           X•••••••••••••XXXXXXXXXXXXX
    'i.e., seven comma-delimited strings + trailing comma   }}

Connections

The following connections were made to the the Propeller Project Board used as the basis for prototyping. The Project Board provides a 3.3V supply:

  • 12V DC from the boat's regulated supply
  • 5V (using a 7805 regulator), gnd and RS232 connection (transmit only) to the LCD
  • Gnd and signal from the fuel flow sensor, with 12 V supplied to it.
  • A DB-9 connector for the fishfinder (the fishfinder is terminated with a DB-9 connector to connect to a PC/Laptop)
  • A DB-9 connector for the GPS (the fishfinder is terminated with a DB-9 connector to connect to a PC/Laptop)
  • Connections to the SD card holder, which is mounted on the protoboard
  • Two wires from the switch 'make' connections, one wire to 3.3 V
  • Three LEDs ("GPS data received", "FF data received", "data write")
  • Various other LEDs to help debugging.
  • The USB connection of the Protoboard allows code to be uploaded and for debugging data to be displayed on the PC during development.

Figure 4: Connections.




This is a prototype, hence the poor soldering and routing.

The details of the connections are included in the code (the Propeller Tool contains a font that includes symbols for components, etc.,). These diagrams are included below. The pin names used in the code are shown also.

Figure 5: LEDs Connected to the Prop


(click to enlarge)

Figure 6: Connections to the Prop

(click to enlarge)

Figure 7: Switch and Flow Sensor Connections to the Prop

(click to enlarge)

The connections to the switch are sunk to gnd through 10K resistors. When the switch is moved to one side 3.3V is applied to one of the prop pins.

Objects

The hierarchy of objects associated to the main code is :
Main file
    • "fsrw2_6A.spin"
      • "safe_spi.spin"
    • "Propeller EEPROM.spin"
    • "FullDuplexSerialExtended.spin" (Instantiated two times)
    • "Simple_Numbers.spin"
    • "FullDuplexSerial.spin"
    • "Serial_LCD_Devantech.spin"
      • "Simple_Numbers.spin"
      • "Simple_Serial.spin"
With the exception of "Serial_LCD_Devantech.spin", all objects can be found in the Propeller Object Exchange ("Obex")

Displayed Data

Data is displayed on a 16 x 2 LCD from Devantech. The LCD is yellow/green in colour - this combination generally suggests a that the display is transflective and therefore readable in bright sunlight. 

Fuel Efficiency

An estimate of fuel used per nm is developed from the fuel flow data (from which fuel flow rate can be derived) and the GPS speed. It should be noted that the measurement period for the determination of rate is accurate to a few micro seconds.

Data Count

The user is able to view how many sets of data have been written to the SD card.


No Fishfinder Data

This is displayed in the absence of data from the fishfinder. An equivalent exists for GPS.

Fuel Flow Rate

It should be noted that the measurement period for the determination of rate is accurate to a few micro seconds.

Lat / Long

GPS position data is displayed on the LCD.

Maximum Speed

The code keeps an eye on the speed measured by the GPS and tracks the maximum speed that has been seen.

No Device!

This is displayed if neither GPS or Fishfinder is connected.

Speed Trend

Using a scale of 0 - 60 kts  a bargraph displays the trend in speed over the last 30 s. The image below shows a steady (simulated 20 knots).

One of the first things the software does is to define eight custom characters in the LCD - from completely empty to a solid block by way of different numbers of horizontal rows. When the bargraph goes into the upper line a solid block is placed underneath.

GPS Time

GPS date and time is available.


Speed and Heading

The speed and course information determined by the GPS can also be displayed.


Recorded Data

The data can be read into any spreadsheet, etc., that can read Comma Seperated Value (CSV) data.

Figure 8: Data Presented in a Spreadsheet



Acceleration Data

A second Propeller board was added to the first: it had an additional SD card holder, an MCP3208 ADC and a three-axis accelerometer soldered to it.

Functional Architecture

One cog of the second Propeller was dedicated to reading the data from the accelerometer and writing it to the SD card.

A serial connection from the first prop sends to the second the count of the number of data items that have been written. This value is also written to the SD card (when it changes) allowing the GPS/FF and acceleromter data to be synchronised at a later data (the accelerometer data updates very rapidly).

No accelerometer data is recorded until the first item of data is received from the first prop; it stops when data stops being sent - this ensures data is only recorded when GPS or Fishfinder data is available.

Figure 9: Updated Architecture


Connections

Figure 10: Connections to the Second Prop


Data

A few data samples were lost when the DB9 connector got a bit wonky during some lump sea, but here is some sample data:


Figure 11: Depth Under Keel


Figure 12: Latitude and Longitude


Figure 13: Speed


Figure 14: Vertical Acceleration

Not yet converted to 'g'. About 1/3 of the way in I throttle back and the acceleration is down to the movement of the waves.


Figure 15: True Heading


Using KML

The data recorded can easily be converted to KML via a simple bit of VBA in Excel. The KML (attached to this page) can then be viewed in Google Earth.

Figure 16: Speed and Scale (0 to 30 kts)

(Click for larger)


Figure 17: Heading

(Click for larger)



Next

The nest step is to record engine speed (rpm). There are a couple of cogs free, either of which could quite happily sit there looking at some sort of sensor input. I intend to use the voltage from the charging circuit as a means of doing so.

The engine has multiple coils that are fixed and multiple magnets that are attached to the flywheel. As the engine rotates voltages are induced in the coils. These are full-wave rectified and supplied to the battery and other accessories (accessories that don't mind a voltage that goes from 12V to 18V depending on the state of the battery and engine speed).

The plan was to chop the voltage to less than or equal to 3.3V - the input voltage of a Propeller pin. Figure 11 shows the full-wave rectified output from the engine (blue) and the output chopped to 3.3V by a zener diode in a circuit such as Figure 12.

Figure 12: Waveforms


Figure 13: Circuit Diagram


This was superceded through the use of an LED driven by the HT lead..

The number of poles in each set of coils varies between engines (manufacturer preference, available space, etc.,). Tachometers typically have a selector switch to match the number of poles to the displayed engine speed - in the Prop it would be just another configuration file, along the lines of calib.txt.

The attached files contain the code and the Prop tool:




ċ
ACC11_serial - Prop 2.zip
(1647k)
Hugh Neve,
Jul 9, 2013, 10:43 AM
ċ
FFGPS60_serial - PROP 1.zip
(1676k)
Hugh Neve,
Jul 9, 2013, 10:44 AM
ċ
TEST.KML
(321k)
Hugh Neve,
Jul 25, 2013, 3:10 AM
Comments