SP200 T-BOX Compatibility #1
Comments
|
Hey @rpverret, happy to hear someone gave this a try! Yes, the daemon should just print NMEA0183 DPT messages to standard out, and then you can pipe that to whatever (e.g. netcat). There's quite a few things that I didn't understand in the protocol so it's really exciting to see these logs. On the T-POD, the thing I found that made it easiest to identify different message types was the message size (see sonarMsg_t::type()). The reason your pings aren't being decoded is because the ping size from your sounder appears to be 360 bytes (0x68 01, decoded little endian to 0x0168 or 360), whereas the T-POD always outputs pings that are 340 bytes. Fortunately, it looks like the temperature part of your ping message might be lining up. As far as I can tell, it's reading 20C (~68F). I'll push a branch shortly with a temporary fix to see if we can at least get it working by using the different size parameter. I've also got some mildly organized notes on the protocol that I can clean up. |
TODO: This isn't a permanent fix, there's probably some better
indicator than the message's size. Now that we've got
two logs to work with from different devices this may
become clearer.
|
Wow @scherererer, that was incredibly fast! I just saw your branch with the changes for the longer pings, so I'll recompile and push the updated program to my boat computer. Unfortunately my boat is about an hour away (with the permanently mounted sonar transducer), so it might be a bit before I can test it out. I suppose I could bring the interface/wifi box back home next time, but I'm not sure how it would behave without the transducer. At any rate, I'll let you know whenever I have something to report. I also want to say thanks for publishing this project. I purchased my T-BOX a couple years ago as a cheaper alternative to all the hard-wired (and expensive) boat transducers. But as I added more stuff, I realized I needed to move away from wifi for the transducer interfaces. So I added a raspberry PI running Kplex with a second wireless interface to connect to the T-BOX, the primary creating a hotspot for my onboard iPad running iRegatta (it is a sailboat). I was going to try to hack something together for the T-BOX interface, but this is much, much better than anything I would have done, and it has saved me loads and loads of time. So thanks again! |
|
Just a quick update that I believe I have everything working... virtually, at least. I had to add an fflush(stdout) in the daemon to get the behavior I wanted, and at the moment I changed the IP address to receive data locally from my "virtual" T-BOX (just netcatting the above data files out on port 5000). But in theory, I should be able to put all the pieces together the next time the boat is on the water. I'll try to get some screenshots of the GUI, as well as few pics of the overall setup, if anyone is interested. |
|
Another quick update... I had <10 minutes at the boat before heading out for a race, and I wasn’t able to get things working. I was definitely connected to the sonarphone. The daemon did not report any output, and the GUI reported “Handshake,” and nothing else. In retrospect I should have logged in on my phone (using the actual vexilar app)... I believe that may have prompted the sonarphone box to initiate things and begin spitting out data. Not sure if this app has the ability to do that from a cold boot of the WiFi interface, or not. I’ll spend some time looking at the code and perhaps put in some debugging statements. If you have any ideas or suggestions, happy to try them out. Unrelated, I’ve had a helluva time trying to get the daemon to run at boot on my Raspberry Pi running Raspbian (Stretch, Debian-based). Is there some kind of Qt dependency that might not work until the shell loads? Just curious if you’re aware of anything. This could also be an artifact of my own decade-long hiatus from any serious Linux use. Thanks again, and zero expectation of any kind of support. Just posting my comments here in the event that they’re helpful to others. |
|
Another quick update. I happened to be passing by the boat, so I stopped in to test my earlier hypothesis. If I connect using the Vexilar app on my phone, I am able to get valid data on the sonarphony app and daemon. I was even able to get the whole setup working and present depth on my boat display app (iRegatta) by sharing the NMEA sentences. So this obviously has something to do with the initial handshaking with the T-BOX. Also notable is that I cycled through the “return/beam selection” on the Vexilar app, which would present unknown messages to sonarphony. I suspect this is changing the packet size? @scherererer, do you happen to have any notes on the handshaking? I suppose my next step is to capture the handshaking process using Wireshark or similar, then diff that with the approach in sonarphony. Here is the Vexilar app with default settings:
Here is a successful connection:
Here is the phone after cycling through the “return/beam selection” (bottom button left of center with the delta and back arrow). Note the erroneous depth:
Further cycling:
Capture mid-cycle, after unknown messages started coming in:
Valid depth (under transducer) in iRegatta:
|
|
Looks awesome! I kind of expected that it would have problems if you changed which frequency you were using. My model is a single frequency model. It probably is going to have a similar problem to the workaround I already gave you -- it will have a different resolution ping so the message size will be different and so it won't identify it as a "ping" message. What really needs to be done is a better routine for identifying the message type rather than just using the size, then it should be stable for all models. With respect to your startup issue, I don't know how authentication works -- I purposefully didn't set a password on mine so I wouldn't have to deal with the issue. You'll probably see in the masterHandshake.C file that there's a few sections of it I refer to as being "magic" and are just all 0's. It's very possible that's where the password is encoded (hopefully as a hash but maybe it's just plaintext). You'd have to capture the handshake from the phone and then try and match up your password with the message. This is what the handshake from my phone to my sonar looks like (hex):
I think FX means F="function code" X="handshake". There's also FC when you're doing a ping request. All of the things I've listed as "magic" numbers are things I haven't identified. I think it's very possible that in those "magic" numbers the password is ordinarily encoded, most likely in that middle chunk. Not sure what comes in that footer of magic after the checksum. Not exactly related, but so you're aware, the other major thing I didn't investigate thoroughly was how the "slave" devices are handled. So if your phone connects as a master, I don't know what SonarPhony will do to the system (as it is presumably pretending to be a master as well). |
|
Ok, I've pushed a new commit to the issue branch. It should at least be better at dealing with ping messages of different sizes because it doesn't depend on the message size anymore. |
|
Thanks much, @scherererer! Just to confirm my understanding, you set a blank password, or you didn't change the default password (12345678)? Or is there a way to disable the password altogether? FWIW, mine is using the default password for all of the above. I'm out of the country now, but I'll give this a shot whenever I get back home. WRT the master/slave thing, yeah, I'm not sure about that. In most of the screen grabs above, I was mostly (but not always) connected via sonarphony and the app, so from the perspective of the T-BOX, I guess sonarphony was taking advantage of any provisions for slave devices. And either way, I needed the app to bootstrap this whole process (getting the box into a mode such that it was broadcasting whether or not the phone app was running). From the description in the manual, I suspect the master/slave designation is really limited to whether or not a client is allowed to change settings. |
|
@scherererer, this project is tremendous. I haven't found any other way to integrate a fishfinder into a boat PC. I have been testing this on my raspberry pi with the transducer of my sp-200 in a pitcher of water. The issue branch appears to be correctly displaying both frequencies. I've attached my log and I'm going to attempt to go back through your code to understand how everything is working and see if i can offer any improvements. Thanks for this! |
|
Excited to see that this project exists! I just bought the SP-200 and was thinking it would be awesome to be able to get an arduino display I have on my dash able to display some data from the transducer. Has any progress been made connecting to the SP-200? |
|
This is an awesome project to see! I've got an SP100 (and SP200 on the way) for a thesis project I'm working on, and I've come across a problem when using the For reference, I'm using Qt (version 5.14.2) on macOS Mojave (version 10.14.5). Alternatively, I attempted to use Wireshark (packet sniffer) to follow the same process of decoding the data, but I just received two alternating packets of standard queries and |
Works fine on linux. Just has extra command line options defined that clang on macos doesnt like. You may get other issues but if you comment out the line in common.pri that looks like: to make it instead You can avoid these optional extra command line opts that I think are probably causing issues compiling for clang/osx. There may be other issues but that will the one shown. |
|
@bjcosta I've switched over to a virtual machine running Linux Ubuntu to hopefully save myself some time. I did try your solution and as you mentioned, the first issue was solved and another issue was created: Cheers |
|
@bjcosta Are you using a virtual machine for your OS? SonarPhony is now working on my Linux VM but I get the debugging comment My current assumptions:
|
|
I've noticed that this project does not connect as the master. I've only been able to get the project to work if I first connect with my phone using the official sonarphone app and then this project will send valid data, I've been meaning to make an issue for this and try to fix myself but haven't had time to research packet sniffing |
|
@jwake2448 Thank you so much, that seemed to have solved the last issue I was having. |
|
@rpverret I am now looking to extend this project with Kplex on a raspberry pi, is it possible for you to tell me how you consumed the data into kplex from the T-BOX? I want to then add GPS data via USB to the NMEA data and output over wifi to my Navionics software... |
|
Such a great job @scherererer , thank you so much! As I would like to connect to my TP200 with an ESP32 and make a little gauge to monitor depth and temperature only, would it be possible to write some fast instructions on the commands required ie handshake and query data? I am not good at QT and it makes it a bit difficult to analyze the code. Thanks! |
|
For SonarPhone to ESP32 you may want to have a look here:
https://github.com/jim-mckeown/SP200A-Client
Depth is sent to a chart plotter via SeaTalk but you could modify it to
show on a dedicated display.
The method for a single or second master client is documented there also.
…On Fri, Feb 9, 2024 at 4:12 AM nikgangas ***@***.***> wrote:
Such a great job @scherererer <https://github.com/scherererer> , thank
you so much! As I would like to connect to my TP200 with an ESP32 and make
a little gauge to monitor depth and temperature only, would it be possible
to write some fast instructions on the commands required ie handshake and
query data? I am not good at QT and it makes it a bit difficult to analyze
the code. Thanks!
—
Reply to this email directly, view it on GitHub
<#1 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AFQQBRI22L2KBZUHFD6ZMCDYSU5SPAVCNFSM4EMYMCV2U5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TCOJTGQ4TIMBQGEZA>
.
You are receiving this because you are subscribed to this thread.Message
ID: ***@***.***>
|
|
Jim thank you so much for your answer! It is what I was looking for! Now do I have to sniff my packets and replicate the mac address of my phone or will it work as it is? Maybe I will open an issue in your git so I will not hijack this very nice git here! |
|
It should work for any SP200 as is. But please let me know what issues you
find. The SSID is hard coded so you may need to change that if it is
different. Use the serial port to set your WiFi password at runtime to
allow the ESP32 access. The FX message contains the mac address that was
set when the master client was set so you do not need to determine that
yourself.
…On Fri, Feb 9, 2024, 14:22 nikgangas ***@***.***> wrote:
Jim thank you so much for your answer! It is what I was looking for! Now
do I have to sniff my packets and replicate the mac address of my phone or
will it work as it is? Maybe I will open an issue in your git so I will not
hijack this very nice git here!
—
Reply to this email directly, view it on GitHub
<#1 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AFQQBRNNK6YUXJ5MM4ROLIDYSXFB3AVCNFSM4EMYMCV2U5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TCOJTGU2DIMZXGQ2A>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
|
Thank you Jim! I already changed the SSID as I found that my tablet has the wifi saved as Sonarphone-272. When I go to the boat I will report back! Can't I hardcode the password? It is the default 12345678.. |
|
@jim-mckeown So excited you got this working on the esp32! I got a new boat so I'm working on my new systems, I previously used the SP200 but only with the navionics app. I run a pi with home assistant to control several functions on my boat so I'm going to look into modifying the code to communicate via a UART library to another esp32 which is running esphome to communicate back to home assistant. My new SP200 is arriving this weekend so I'll fork and post any questions I have to your repo. Thanks! |
|
|
@jim-mckeown Cool yes. Sorry I got confused by the serial port and beacause there were hardcoded credentials in the code. |
I just set this up with my SP200 T-BOX and was not able to get it working. The GUI simply reported a continual string of unrecognized commands. Foolishly I did not try the daemon, but I would expect similar results.
@scherererer , do you have any additional documentation on the format of the data and any potential handshaking with the transducer interface? I spent a bit of time looking through some of the code, but it was a bit tough to reverse reverse engineer.
Ultimately I'm just trying to pull the depth and get it translated to NMEA. I'm not familiar with Qt, so unless the modifications are fairly straightforward, not sure I can contribute back here. But if there is an obvious place to pull this info off the wire (looks like bytes 23-25 on some kind of "ping packet" in the data stream?), I will try to accomplish via other means.
In case it is helpful to anyone else, I'm uploading a few files. The "sonarphoneoutput" ones are just the output of netcat connecting to the box on port 5000. IIRC, this one:
sonarphoneoutput.txt
was just my PI connected to the box. This one:
sonarphoneoutput2.txt
might show a record of my iPhone connecting and disconnecting (if it set some parameters or initiated actions that applied to all connected devices). And my phone was connected for the duration of this one:
sonarphoneoutput3.txt
Doubtful that will be reflected in the data, but I'm not familiar with the protocol/handshaking. Finally, this file:
2018-01-20T12_21_22.690.sonarphony.raw.txt
Is the actual log of the SonarPhony GUI. I was playing with the logging functionality off and on, so I'm not sure if anything interesting might have happened while logging.
As for the contents of the data, the sonar transducer is epoxied to the hull of my boat, and the boat was out of water, so it wasn't picking up any depth or reflections on the sonar display. I believe the ambient temperature was around 65F.
The text was updated successfully, but these errors were encountered: