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.
