Hi we have acquired 3 Bluerovs and are looking to have a simple Buckley’s CP system on it can anyone help as to how I can get the CP on the Overlay flying screen and how to connect it to the System please .It’s just a voltage that is required on the screen .I’m still learning these Rovs and it’s all new to me .Thankyou
1 Like
Hi @rovmig, welcome to the forum! 
I don’t have previous experience with cathodic protection instruments, but from a look at the Buckleys website (and a glance through this guide to CP electrode potentials) it seems like you’re wanting to measure the voltage across two wires from your sensor, which you’ve said you then want to send and display on the topside.
There are a few main steps involved here, and it may not be as easy as you’re expecting/hoping.
Measuring the Voltage
Your sensor outputs an analog electrical signal in the form of a voltage. As analog signals go, voltage is the most direct one to measure, but it still requires an Analog to Digital Converter (ADC) to convert the physical voltage into a digital number that can be passed around in software.
ADCs work by comparing an input voltage to a set of known internal voltages, so you’ll need to ensure the ADC you use has a large enough range to measure the possible output range of your sensor, and a fine enough resolution (enough comparison voltage levels, which are converted to binary bits of result) that you get a meaningful output for your application.
Our Raspberry Pi Companion computer is generally the easiest way to manage custom integrations, but Raspberry Pis don’t have ADCs, which means you’ll need an ADC board/chip that can communicate readings to the Raspberry Pi via a protocol like I2C or SPI, or serial via a serial-USB converter like our BLUART.
Alternatively it may be possible to use one of the existing 3.3V or 6.6V ADCs on the Pixhawk flight controller, but their values don’t seem to be automatically streamed to the topside, so I expect you would need to modify and build a custom version of the ArduSub firmware to read and transmit the values you want. I don’t have much experience with ArduSub modifications, so I’ve asked our software team whether this would be hard to achieve.
Sending Measurements to the Topside
The difficulty of this depends a lot on how well-integrated you need the measurements to be. If your readings are coming in via the Companion computer the easiest approach is to just print the values to a terminal window that you can access from the topside. If you need the values to be viewable in QGroundControl (and want them automatically saved as part of the normal telemetry logs) then you’ll need to use the MAVLink communication protocol.
ArduSub already uses MAVLink for all its communication to the topside, and for the Companion computer you can use the Pymavlink Python library, or some other MAVLink implementation if you prefer.
Receiving Measurements at the Topside
Viewing printed values on a Companion terminal can be easily done using a screen session which can be accessed from the webterminal.
QGC is unfortunately quite convoluted to modify/extend. If QGC access is required you can potentially piggy-back off an existing MAVLink message that it already tries to display but which ArduSub doesn’t actively use, but if there’s nothing suitable then you’ll need to make a modified version of QGC that supports your custom message, as outlined here.
Want something cheap … Zinc. I have dealt with the Submarine force for over 40 years now and we had Zinc strips out the ying yang in the superstructure of the sub. On the newer classes they have went to active CP systems but this is not something I would suspect that you would even remotely require on an ROV.
My main reason for saying this is you aren’t exactly hanging out in saltwater 24/7? I would approach a CP method by choice of materials and not an active electrical system. Since a lot of the materials are plastic … that eliminates that issue. The other things like screws etc. you can switch to 316 Stainless Steel or 304L grade.
My question would be, just how much metal do you have on your craft, what type is it, can you replace it with something that is more neutral on the electrovalent scale and the list continues.
Having an Active CP system just requires more power delivered to the craft, more processing power and that list continues. In my opinion, there is no meat on the bones to support it.
Ok, should have went to the website first. What are they using that probe for? If you just want to read electrical potential generated by the probe contacting a surface … this is what I am assuming … I would HIGHLY recommend that you do all of your measurements on the ROV with the probe cable as short as possible before it hits the electronics. Having your conversion circuits as close as possible and away from your high current conductors will give you a better reading.
If you want a real no crap system with a probe that will handle pressure, that is pretty easy to do too.
1 Like
Many thanks for the replies ,I’m looking forward to trying this out .Thankyou
1 Like
Hi @rovmig . From my experience, the cheapest and easiest way to do that is just connecting both wires from CP Probe to a spare pair on fathom tether. On top side you can use any Analog/Serial converter to output the voltage to your computer, or even measure it with a high impedance voltmeter. As the CP probe measures only the electric potential, the current is actually zero, and there isn’t any loss regardless the wire lenght.
It’s not the most beautiful way to do the job, but I have worked this way in work classes ROV before with more than 3.000m of cable, and I can assure it works well.
– VMartini
That’s an interesting idea I hadn’t considered - nice!
My main concern there would be with noise from other signal wires on the same lines, but given the tether uses twisted pairs and the signal being measured is differential that shouldn’t be a significant issue, along with the fact that the normal communication frequencies over the tether are far above the almost static voltage being measured.
If measuring it manually with a voltmeter is acceptable/sufficient for the use-case then I’d agree that this is the way to go
If the signal is going into a computer anyway, then assuming there’s room in the enclosure for the relevant electronics, and a port to connect them to, it may be preferable to just handle the measuring directly in the ROV. That comes with the added benefit of being able to relatively easily add the voltage measurements to the normal vehicle telemetry stream, in which case timing and depth information are automatically recorded.
In theory, ideal measurements have no influence on the phenomenon being measured. In practice that’s not entirely correct, but given the Fathom tether resistance of 0.127\Omega/m \times 3000m \times 2 \text{ wires} \approx 760\Omega that’s still a tiny fraction of even a standard voltmeter’s internal resistance (generally in the MΩ range → adds <0.1% error), so tether length definitely isn’t a particular cause for concern for this kind of application
It’s surely a neat solution. I used a 16bit ADC (ADS1115) I2C on RPI as an upgrade (great tutorial, by the way). One thought that comes to me is if it’s possible to have the value on MAVLink REST API…
1 Like
Cool!
Thanks!
Mavlink2rest can communicate both ways, but at the moment it only displays what it receives from the autopilot. I just had a meeting with the software team and brought this up, and they agreed it would be useful to also capture and display messages it receives from clients (for this kind of thing, and several other purposes), so it’s something we’ll try to make possible.
That said, Companion 0 is only receiving critical updates at this point, so I expect the feature will only end up in Companion 1 (which is currently available in Beta).
Hello everyone.
I have made some PCBs for this. It provides 3 different means of communication:
- Via twisted pairs to Surface using the PCB directly on the user’s PC via USB
- Via USB through raspberry pi subsea
- Via RS485 either through fiber channel or twisted pairs.
There is a 12bit ADC for the conversion that talks to an Arduino nano which then sends the string via the USB port.
String format: {,#CP,0.000,}
I sell a software for recording with overlay so I do not support 3rd party software. That said, I can change the string format if need be.
I still have some in stock. 250USD each. I can also put it inside a box for a finished product for 500USD.
Cheers,
E.
It would be a great improvement.
I’ll definitely try that out!
Eliot @EliotBR - I found this article from last year and it is something we are looking to add to our ROV.
Our thought was to use the 3.3V ADC in the Pixhawk and I noted in your write up that the values are not streamed to the topside and you were going to ask your software team about the difficulty in modifiying ArduSub to achieve that.
Is this something that you passed along and got an answer on?
As far as receiving the measurement and displaying the measurement, I think your soultion for either the terminal screen or the webterminal should work fine for us. (Not sure if those are two or one solution).
Thanks,
Alan
Hi @AlanB, welcome to the forum
I did ask about this at the time, but don’t believe I got a particular response.
I’ve asked about it again and been told that there seems to already be an appropriate MAVLink message for it (AP_ADC) but support for it doesn’t look to be implemented in ArduSub, and finding an appropriate place to add that would need to be looked into (but hasn’t yet).
As something of a follow-up, we have some new generated documentation on ArduSub’s MAVLink Support, which I noticed had AP_ADC included as one of the known (found) outgoing messages. Looking in the linked code file it seems like it is automatically sent, but only when the firmware is compiled with a specific debugging mode.
Making that available more generally would require changing that condition (perhaps to be dependent on a parameter or something), which should be possible but needs to be somewhat careful because it’s in one of the general ArduPilot libraries, so affects firmwares for all vehicle types (not just ArduSub).