My 'Lake Survey' Boat

If you read my previous post you'll see I have a fish/depth finder that I was trying to reverse engineer the protocol of.
Since then I decided to build a radio controlled boat to drag the fish finder around.  The idea being that the boat will drive around the lake logging the depth and GPS position allowing me to build up a map of the lake bed.

After an initial failed attempt at a rather dubious airboat (that flipped over seconds into it's first test run) I decided I wanted something:

a. relatively cheap and simple to build
b. very stable/sturdy
c. able to carry a decent payload
d. have a battery life measured in hours rather than minutes.

After looking at various options I decided to base my boat on a Springer Tug, but increased in size by ~25%.

The idea was to build it over the xmas holidays, though it took me rather longer than that!

The hull sides and deck were cut from 6mm birch ply, and the base from 1.5mm birch ply.  The various spars and other bits were from whatever wood I had lying around the garage.

For the motor I decided to use an Mtroniks M600, which in hindsight is possibly slightly over kill.  I think I 500 motor would have been plenty.

The boat was predominantly glued together using 5-minute epoxy (though in the middle of winter it seemed to take rather longer than 5 minutes to cure!)

When complete I coated the inside with several coats of yacht varnish from the local pound shop, and coated the outside with several coats of black spray paint, again from the pound shop.

I built it fairly heavy as I'd heard springers typically needed a lot of ballast.  I obviously didn't build it heavy enough, as my initial flotation test showed I still needed several kilograms adding to get it to sit right!

The original plan was to use a pair of 6V 4.5Ah batteries, but as so much extra weight was required I thought I may as well use extra batteries as ballast and doubled it to four!

To control the boat I purchased a FlySky FS-i6 transmitter and receiver for £29 from ebay.  I have to say, I'm incredibly impressed with it so far.

I'll try to get some better pictures, including some of the inside, but for now, here it is on one of it's first test runs:

Lucky Laker WiFi Fish Finder

I own a LuckyLaker WiFi Fish Finder (FF-916) which I picked up fairly cheap (~£50).

Feature-wise it's very basic compared to more expensive models.
It only gives you an idea of water depth, and whether there are any fish under it (though I'm sure it gives a lot of false positives...).

What would have been nice would be some idea on the composition of the lake bed.
Unfortunately thick weed is indistinguishable from hard ground, so it's not clear whether for instance the water is 3ft deep with a clear bottom, or 10ft deep with 7ft of weed.

Even so, it's still a useful tool, and a few casts can provide useful information.

---

Out of curiosity, and to see if it was possible to winkle out some extra data, I decided to attempt to reverse engineer the communications protocol.

The device acts as a WiFi hotspot with SSID "FishFinder6", and IP Address 10.10.100.254.
It has a TCP 'server' on port 8899 which the client/UI connects to.

The client (UI) sends a packet to the server (Fish Finder), and the server responds with a packet.

The packets are in binary with the following format:

| Start Byte | Device Byte | Data-to-follow Byte | Data Bytes | Checksum Byte | End Byte |

where:

Start Byte = 0x68
Device Byte = 0x02 for client and 0x82 for server
Data to follow = number of data bytes to follow
Data Bytes = Data, variable length
Checksum Byte = Sum of all preceding bytes except start byte
End Byte = 0xED

I have identified 4 different packets:

1. Configuration Packet
This is the first packet sent to the device, and needs to be sent before the device will start doing anything useful.
I don't know what the contents mean, and have never seen them change.

  0x68 0x01 0x06 0x02 0x00 0x00 0x00 0x00 0x00 0x09 0xed

2. Request Data Packet
This packet is periodically sent to the device (~ twice per second?) .
The device replies with a data packet.

  0x68 0x02 0x01 0x01 0x04 0xED

3. Inactive Data Packet
If the device is inactive (i.e. not in the water) it will reply with this packet

  0x68 0x82 0x01 0x00 0x83 0xED

4. Active Data Packet
If the device is active it will reply with this packet

  0x68 0x82 0x07 0xDD 0xDT 0xTT 0xLL 0xMM 0xSS 0xBB 0xCS 0xED

where:

  DDD = depth in meters x10  (note: this spans byte 3 and the top nibble of byte 4, max value is 0x7D0)
  TTT = temperature in degsC x10 (note: this spans the bottom nibble of byte 4, and byte 5, max value is 0x7D0)
  LL = Large Fish Detected
  MM = Medium Fish Detected
  SS = Small Fish Detected
  BB = Battery level, Range: 0..4 where 4 = full battery, 0 = empty battery

Example:

 0x68 0x82 0x07 0x03 0x51 0x1d 0x00 0x00 0xd9 0x04 0xd7 0xed

Depth = 0x035 = 53(dec) = 5.3 meters
Temp = 0x11d = 285(dec) = 28.5 degsC
Battery Level = 0x04 = full charge
Large Fish = 0x00 = not detected
Medium Fish = 0x00 = not detected
Small Fish = 0xd9 = detected @ 4.5m

Note that while the UI displays the specific depth of each fish, I haven't yet been able to to find any correlation between the fish detected byte and the displayed depth.

---

So, unfortunately it looks like all the processing is done on the device, and it only reports the basic information shown on the UI.  Nevermind.

Skov's Blog

This is a place for me to record / share random thoughts/ideas/projects/etc.