We are working on a project where we need to measure conductivity alongside other stuff. Does anyone have any experience with using conductivity sensors with QGroundControl (QGC), is it possible and if so, how does one get the data out? We have a conductivity Probe K 1.0 and a EZO™ Conductivity Circuit from Atlas Scientific.
Any advice is greatly appreciated, Thank you in advance.
Kindest regards
Struggling mechanical engineering student project group
Hi @Nicklaslb,
Is it a requirement to have the data displayed in QGroundControl? I’ve previously written a post about adding a sensor to the MAVLink stream, which went through the relevant steps, although it assumes you’re using our old Companion software. If you’re using BlueOS the startup process will be different (and ideally would be handled as an extension rather than a standalone python script).
The EZO™ Conductivity Circuit you’re using seems to have support for USB, I2C, or UART communication. I expect USB will be simplest if that’s available. You should be able to use the Raspberry Pi example code provided in the documents on the product page 
Feel free to follow up with additional questions, although if you do so please provide some more context on the hardware and software versions you’re running / planning to use, and what your usage requirements are (along with “nice to have” features that aren’t strictly required).
Hi @EliotBR,
It’s not a must have that the data is displayed in QGroundControl. As long as we can log it somehow with timestamps.
We are using blueOS 1.1.0-beta.10 and QGroundControl 4.2.3 on a Raspberry pi 4. Does this mean we can’t add the sensor with MAVLink stream?
I suppose “extension” is the way to go then? How is this done exactly? I’ve looked at the link but I’m still not quite sure.
Thank you a lot for the response.
Ok, either way is possible, it’s just a bit more complicated if QGC and MAVLink are required
Nope - it just means that the steps for how to do so aren’t already clearly written down in a single convenient place.
Unfortunately I haven’t yet had the chance to properly document the extension creation process, because our extensions infrastructure is new, and there’s some other documentation I’m trying to finalise first.
We do have an examples repository, which is intended to be a set of steps of progressively more complex extension features. We’re planning to have a persistent logging example, but in the interim it’s hopefully helpful to refer to example 4 (which includes persistent file saving).
What kind of timeline are you working on?
Basic sensor integration is something we expect to be a reasonably common use-case, so is definitely something we could benefit from having a simple example for, and we’d be happy to work with you to make sure you’re able to create that if you want to.
That said, the fastest and simplest way to get data when starting out will likely be:
pylibftdi (with pip) on your topside computer (you’ll need Python first, if you don’t already have it)USB over IP should enable minimal “data retrieval” functionality from a script running on the topside, but means you need to manually start your program each time you want to start collecting data. If you want the convenience of your code automatically running on the vehicle, when the vehicle turns on, and/or additional features like having a graphical interface and being easily installable on other vehicles then we can work together to turn your script into an extension
Hi Eliot,
We are due to turn in our rapport the 21. of December, but could alternatively get to keep working on it afterwards.
We are looking in to this way of doing it, but have not yet made it work.
This is also due to trouble with getting the Atlas Scientific examples for USB to work. We have made it work on a stand alone raspberry pi with serial but not USB and not trough BlueOS. We suspect that the example code from Atlas might be outdated.
We would be very interested in working with you on a solution!
We have tried this but have more trouble than expected to getting the Atlas code to work. We are using a vitualbox to run linux on a windows computer but can’t seem to find the USB-connection this way.
At the moment we have a failsafe in the form of a standalone arduino that logs the conductivity data along with a timestamp on a SD-card. Although this means we can’t have a live feed with our conductivity data.
Thank you for the great feedback
I think a nice option would be to have an extension reading data and sending it to the autopilot as a NAMED_VALUE_FLOAT MAVLink message.
I added it to the list of examples I’d like to implement.
Hmm, ok. Serial (or I2C) should also be doable on BlueOS, but it may require some additional effort on your part, and may have other incompatibilities with the existing instructions from Atlas.
USB over IP should at least allow connecting, as long as your network is passed through to your virtualbox setup (with a “bridged” configuration). Try updating BlueOS , then uninstalling the VirtualHere extension, and then installing the latest version (there was an issue with the previous version that may have prevented it from working properly).
Good to know there’s a fallback option. I’m unsure how much development resource you have available to work on this at the moment - if it’s quite limited then it may be preferable from your end to make use of your known working approach so you can collect data and write your report, and we can focus on creating a more integrated approach through BlueOS afterwards.
Otherwise, if you’re able to spend some time on testing different approaches then we’re happy to help out where we can, especially with the BlueOS integration side of things
We have made a solution where we run Atlas’s code on an Arduino nano and then feeding the data into the the RPi’s USB and getting it out with the VirtualHere extension. It works and we can get our data.
Thank you for all your help, if we keep working on it we will be sure to include you guys
Can you explained a little more? Are you able to see the data live at the surface? In QGC or a separate application? or at the end of the day? I actually have a multiparameter probe on my rov but I gave up for now to see the data in realtime. I only get them at the end of the run…
VirtualHere is a USB over IP system, so it’s like plugging the USB into your topside computer. Since they’re sending the data themselves they should be able to see it live at the surface by writing a program that can read it (possibly just viewing it with the Arduino Serial Monitor/Plotter), but it won’t be integrated in QGC.
We are getting the data live to topside with virtualhere and then we read and plot the data with a program called CoolTerm. So as Eliot mentions it is not integrated in QGC.
We use a Ardoino Nano in the robot to run a template code given by the probe manufacturer and the feed the data in to the raspberry pi’s USB port, that is connected to the topside computer with virtualHere.