What is the minimum configuration for connecting Blue Robotics Ping 1D Sonar Altimeter over RS485 to the surface via a long (100m) cable to a top-side computer.
The BLUART USB to TTL Serial and RS485 Adapter does not seem to do this by itself but I maybe wrong. We tried the BLUART adaptor connected to the Altimeter to get RS485 up the cable, then to a RS485 to USB converter, then to a computer.
It seems we need an adaptor that goes from TTL to RS485 to get data over a the 100m long cable. Then I am guessing we need to go from RS485 to the BLUART adaptor (USB) to connect to the topside computer.
Ping Sonar ↔ (microcontroller? +) Serial to RS485 converter ↔ cable ↔ RS485 to USB converter (e.g. BLUART) ↔ topside computer
Our BLUART can do Serial to USB or RS485 to USB, but not Serial to RS485. As described on the product page:
In order for the half-duplex RS-485 communication to work there needs to be something to tell the RS-485 transceiver when to operate in transmit mode vs receive mode, which is generally handled by the device that’s trying to communicate over RS-485.
In the BLUART Schematic that’s handled by an output on the FT231XQ chip, which must be based on the USB signals (since RS-485 as a protocol does not specify when a node should be receiving or transmitting - that’s left up to the connected device(s)):
Setting aside the fact that the receive/transmit connections are the wrong way around on the BLUART to connect the Serial and RS-485 outputs together (which can be fixed by external wiring connections, and isn’t a problem on modules that are actually intended for Serial UART to RS-485 communication), the receive/transmit state determination is problematic.
While the Ping Protocol is designed to be synchronous (and hence RS-485 friendly), the Ping Sonar does not provide an RS-485 output, so converting to one would require something like a microcontroller (potentially running custom firmware) that can analyse the signal lines and set the transmit/receive state of an RS-485 transceiver as relevant.
It may be possible to do that ‘naively’ by toggling the state after a gap in either direction, but that may fail / corrupt messages due to timing inconsistencies. The main alternatives would be to analyse the messages in real time in order to actually understand when each side is expected to be transmitting, or to use the microcontroller as a proxy device that communicates via TTL Serial with the Ping Sonar and RS-485 with the topside (e.g. handle communication directly instead of trying to eavesdrop fast enough to allow it to operate normally).
