I’ve hooked up the S500 using QT on a Raspberry Pi through a USB serial connection and it seems to be working. I’m able to connect, I can send codes, and I get responses. Thanks to Larry for the qtpacket class (in a different post) which streamlined things a lot.
However, I’m having problems with a few API ID codes from Appendix F of the S500 online user manual. Here is a very quick summary of issues before I provide a more detailed explanation:
- There appear to be several typos in the S500 user manual related to the processor temperature command (113), including a possible error in the command ID code
- The set_ping_params command (1015) does not provide a response to the host
- When the report_id parameter is set to distance2 (1223) by the set_ping_params command (1015), the transducer starts to ping, but the module does not appear to send any distance2 packets to the host. Not any bytes (not even erroneous ones) were observed.
First, for those interested, let me confirm that the following codes have been tested and are working on my unit: fw_version (1200), speed_of_sound (1203), range (1204), ping_rate_msec (1206), gain_index (1207), altitude (1211), and set_speed_of_sound (1002). These all send the proper response and adjust the relevant parameters correctly (in the case of ID 1002).
What does not do what I expected:
First, processor_mdegC (113) does not work. When I send the code I get an ascii response that says it is an unrecognized code. No big deal to me, though it is nice to stay ahead of the processor temperature. I looked at the other IDs and this one seemed like it might be a typo in the online user manual, so I tried (1213) instead. I got a response that is possibly valid, though the S500 only returned a u16 instead of a u32, so I don’t trust that it is in millidegrees C, though it could be in centi-degrees C. In fact, this is what is stated in the ping1d protocol, so I suspect that there are a few typos in the S500 manual with respect to processor temperature (id number, variable type, and the units of the output).
Second, set_ping_parameters (1015) appears to partly work. It appears to correctly set the start_mm, length_mm, gain_index, msec_per_ping, report_id, and chirp. I had no way to check decimation. However, it does not send a response packet after making these changes. I’m not sure if the module is supposed to send a response to the host, but that would seem natural based on all of the other commands. No response packet or response bytes are observed. There is not even an ACK or a NACK packet. That’s fine with me, as long as it does the trick, but maybe should be documented. I don’t know how the command is able to set the parameters without it being fully received by the module along with a proper checksum, so I have to assume that the command is operating properly for setting parameters other than that there is no response from the module.
I have a more serious concern about the (1015) command, though. When a distance2 (1223) report id is sent in the (1015) command, the transducer begins pulsing as it should, but no ping response packets are received by the host. I expected to receive distance2 (1223) packets for every ping, but I did not observe a single byte of data at the host, even though the transducer was clearly pinging. In my case, it is possible that none of the echos returned valid depths and that the unit only sends packets if it detects a valid depth, but that is not documented in the manual, and my assumption is that it sends packets even to report a measurement with no confidence. I did try the device in a jar of water - the jar was not very deep, but I would expect a result of some kind, even if the signal was garbage.
The profile6_t (1308) report id does appear to work when sent in the (1015) command and the module is regularly transmitting profile data for every ping. I have not parsed all of the data to see what it says, yet, but the bytes received look to be about the right number and I have verified some of the parameters in the profile packet. I’ll have to check this in more depth later, but the profile6_t packets are promising.
If anyone has any insights regarding the issues I encountered, I would be appreciative.