Hi,
I’m running two BlueROV’s - currently one is on BlueOS 1.0.1, and the other is still on Companion 0.0.31 / Ardusub 4.1.0. I have one WaterLinked DVL A50 I’m trying to get running on either platform. I have not been able to communicate with the DVL at all, on either system. Following the instructions at Networking - Documentation, I put the DVL in a bucket of water, plugged an ethernet cable directly into its I/O board connected to an ethernet port that I set to a static 192.168.194.90, plugged in the DVL, and addressed a browser window to 192.168.194.95 (the DVL’s fallback IP address). No connection. But the DVL’s LED is lit steady green, so it’s powered and apparently has bottom lock in the bucket.
Alternatively, for the ROV running Companion 0.0.31, I reset the computer to 192.168.2.1 and connected via browser to the ROV at 192.168.2.2. On the WaterLinked tab there, in the DVL section I specified 192.168.194.95 (the DVL’s fallback IP address), and the Status box at the bottom said “Looking for Waterlinked DVL A-50… (waterlinked-dvl.local)”. But that’s where it sat, and never went further.
Any clues how to get going with this DVL?
Thanks,
Scott
I’m jumping into this active DVL thread with a follow-up to my prior post (not sure what the best procedure is when returning to questions in conversations that have since moved on…).
Still no connection to DVL after taking these steps:
installing a new Navigator board and Pi4 (works fine; running BlueOS 1.0.1, Ardusub stable 4.1.0)
following the instructions in this post, I updated the DVL docker container to Willian Galvani’s current version. I accomplished this using ssh from a CMD prompt, because the BlueOS terminal is not working for me (is this relevant somehow? I just get a spinny wheel when trying to start the terminal in Pirate mode). LATER EDIT: I followed the tip in this post and installed the latest BlueOS version (“master”) using the version chooser; this fixed the Terminal problem, but did not succeed with the DVL connection.
tried again to connect directly to the DVL to configure the IP address per WaterLinked instructions, but can’t establish a connection
verified that the DVL board is working (can see green flashing on the LED for port 3 on the ethernet switch). Also tried a second DVL board (from my other ROV); same result.
During all this, the DVL is in a water bucket and is displaying a steady green LED. I do see the DVL service running, and the Status on the DVL driver page at http://192.168.2.2:9001/ says "could not talk to dvl at waterlinked-dvl.local, looking for it in the local network…
Any ideas @EliotBR or @williangalvani? I’m pushing hard to get on the water here but totally stuck at the moment.
Thanks,
Scott
Sorry to hear you’re having connection issues with your DVL.
I’ve moved your follow-up here into your original post, since this topic is more specific than the general “DVL integration not working” one (which has several tangential discussions in it).
Thanks for providing a run-down of what you’ve tried so far
Do both DVLs work as expected when (individually) connected to your other ROV? I’m not clear on whether you’ve confirmed that both DVLs actually work properly, or just that they both light up an LED on an ethernet switch when plugged in.
This makes it seem like perhaps the DVL is faulty / not communicating correctly? If it didn’t work with a direct connection to your computer then it seems unlikely BlueOS would be able to establish a connection with the device.
If the DVL is confirmed to work but BlueOS is unable to connect to it then we can try to figure out why by looking at the DVL service’s logs*, but if the DVL isn’t working/communicating then you’ll likely need to get help from Water Linked.
*The logs are currently not persistent, but are available while it’s running by going to the web Terminal, then running
To clarify: I am currently planning to use one of the ROVs as a “backup unit” only, so I just bought one single DVL. But both ROVs have DVL I/O boards, and I installed BlueTrails Cobalt bulkhead connectors, so I can swap the one DVL between the ROVs as needed.
So this statement:
… means that for this test, on one ROV running BlueOS with the Navigator, I just grabbed the other DVL I/O board from the other ROV and swapped it in (I have a connector on each of them).
And no, I have not established that the DVL works properly because I have never successfully established a connection, either directly with an ethernet cable plugged directly into one of the DVL I/O boards (attempting IP specification as above), or through the ROV tether.
Yes, it does seem like a communication issue. Clearly the instructions provided by WaterLinked regarding direct connection at the fallback IP address of 192.168.194.95 are not working; I just wasn’t sure whether this was a “meaningful failure” because (I think) none of the BR instructions spell out this procedure explicitly and I wasn’t sure if WL’s instructions were still pertinent or not for this BR integration.
Other users (e.g. WaterLinked DVL A50 integration not working - #14 by Jnyberg) seem to have initially configured the DVL IP address to 192.168.2.95, but I seem to be unable to do that. Can you confirm that the following procedure should have succeeded? :
If so, then I can’t implement this suggestion:
… because I don’t see any GUI when I try to connect.
The observation that the BR ethernet switch has a blinking green LED on port 3 (during tests where the DVL is connected through the ROV) led me to discount the idea of a bad I/0 board. And the actual DVL’s LED behaving as expected (solid green, with an occasional blip off to signal it’s “alive”) suggest the unit is powered and functioning; when I said “apparently has bottom lock in the bucket”, I’m just inferring this from WL’s info about what the LED is signaling.
Thanks Willian. I actually had already pushed up to the latest beta version (the master) in order to get the terminal working (which succeeded…), but I just didn’t know where to find the dhcp feature. I’ve now tried it and it didn’t make a difference.
We are going to double-check that the wiring from the DVL to the I/O board is correct… it turns out that WL did not actually use color-coded wires for TX+, RX+, and TX as their spec sheet indicates (all 3 are just plain white wires). So, it’s possible that we’re mis-wired (though I doubt it because we tried to maintain continuity).
Can you confirm that, if the DVL is communicating correctly, I should be able to connect to it for the first time through the ROV (BlueOS latest beta) at 192.168.2.2:9001, even if I have not first connected directly to the DVL to re-assign its IP address?
re-terminated the DVL cable, double-checking continuity through to the DVL I/0 board and confirming with WaterLinked support that our wiring was correct
tried DHCP mode:
… and then followed Eliot’s suggestion (above) to look at the log:
This should be the starting point. We need to figure out why this doesn’t work first. Maybe running wireshark on that interface could give you a hint of what is wrong.
The DVL is now working; the problem was inadequate supply voltage. Following up on this:
… and a clue from WaterLinked support, we gave it 16 V instead of the 12 V we had been supplying, and the DVL started communicating (even though the DVL spec sheet indicates a 10 - 30 V input range).
It turns out that sometime between when we bought the DVL last winter and now, the BR integration installation instructions changed “quietly”. We had captured the instructions into a local document for working offline, and they specified installing the DVL with a certain voltage regulator supplying 12 V, which we installed. Now, cross-referencing the current version of the instructions, the line about installing a voltage regulator is absent.
So, here’s a suggestion to avoid this kind of headache: could there be a change log of hardware/procedure changes, similar to the change log that documents software updates? Perhaps the log could also be a repository of known issues; i.e. obviously somebody had learned that 12 V was not suitable for this DVL, but that information was not accessible.
As far as I’m aware the only Blue Robotics DVL documentation is software focused. Water Linked have an integration guide for the hardware, but that’s not something we monitor or have control over.
Looking at Water Linked’s DVL-A50 product page, it doesn’t seem like the specified voltage range has changed (it still says 10-30 V). If Water Linked have stopped recommending a voltage regulator in their integration guide then perhaps there were issues keeping it in stock, or maybe it was found to have insufficient current capacity, or not perform to its specification - you would need to ask them if you want more information about it.
Change logs are great, and definitely something I advocate for. For Blue Robotics products, changes to hardware and specifications are captured in the Revision History in the Technical Details section on the relevant product page, and we put notes and warnings as relevant if there are known issues. As you’ve mentioned, changes to our software are captured in the release notes. I’m also in the process of making “what’s new” sections in our new documentation system, to cover a summary of the main changes of each new software version we release
Perhaps you can suggest to Water Linked to do something similar, if they don’t already (although I believe they do have at least some device and API revision history in their documentation pages).
As a general principle I would recommend against using locally stored datasheets and/or procedure guides (especially for electronic devices), except as a short term offline backup when/while an online version is unavailable. Guides get updated, improved, and simplified over time, and there may be recommendations for new software versions or easier ways of doing things that could otherwise get missed.
Ah, right, I was thinking that the integration guide was a BR document, rather than a WL document as you correctly state.
FYI for others using the DVL, the old WL integration guide had a recommendation for a specific third-party voltage regulator, but now the guide instructs to wire straight to the battery terminal. We did see the DVL reset itself (it re-established a new origin position) during one dive when we unfortunately let the system voltage drop too low (but still well above the 10 V minimum listed in the WL spec sheet).
I do think you’re making great progress in organizing and clarifying a very complex universe of information here, Eliot-- keep it up!
As Scott mentioned in the discussion above, they were originally using a 12V regulator to power the DVL. Most likely they stopped using that regulator and either switched to a different one, or connected the DVL directly to the vehicle’s battery terminals.
