Home        Store        Docs        Blog

Fathom-X not re-linking after power cycle

(Phil Malone) #1


we-re using your Fathom-X interface on our MATE explorer class rov.

The modules link fine after being off for a while, but when we power cycle the robot, the modules don’t want to re-link.
We have found that if we just power the ROV down, we need to wait a full two minutes before we can power it up and get a good link (this is regardless of whether we power down the topside link or not)

We can tell if the ROV is going to link, because when we power it on. If there is an initial green link flash, the modules will connect. If the green Link LED does not flash, then it will not link.

Note: the ROV is powered by 48V and we use this power pair for the Fathom X link.
48V is down converted to 12v on the robot, and this is used to power the fathom X.

We checked and the 12V drops to a few mV when we power down, but the 48V tends to drop to a few volts very quickly and then slowly ramps down to oV over several minutes.

We did some experiments and found that if we discharge the 48V line(at the fathom X) after powering down, then the modules link up right away without having to wait the two minutes.

So it seems like the residual voltage on the link lines is preventing the modules from re-linking on power-up

Is this possible?

We are considering adding a high load resistance to the 48V line to drain the caps in the voltage regulators more quickly, but since the supply is a high voltage, we can’t go too low with the resitance, so it may not be that effective.

Do you have any other suggestions.

(Rusty) #2

Hi Phil,

Thanks for the post. This is an interesting issue and I don’t think we’ve seen this before. We have some other customers using the Fathom-X in parallel with power, but we aren’t doing that yet ourselves.

The signal to the Fathom-X is coupled through a transformer, so any residual voltage should have no effect on the signal. However, if that residual voltage is causing the Fathom-X board to remain powered up, I suppose that could cause issues.

There’s also the possibility that the voltage regulator is introducing some high frequency noise into the power lines that the Fathom-X can’t handle.

Have you tried to run this on separate wires just to verify that the 48v power is definitely causing the issue?

Have you tried checking connections or wiggling connections once it has failed to see if it relinks?

Hopefully we can figure this out soon. I’m curious to know what’s going on.


(Phil Malone) #3


We haven’t had much luck making the re-link more dependable.

We don’t believe it is loose wires, because once the link is established, it stays working solidly no matter what. No no link loss other than when we power down.

We also know that the residual power is not getting through the 48v to 12v regulators as we see this voltage drop to 0.
So the effect we are seeing on the tether lines may be a red herring.

I could beleive that the regulators and the main supply (all of which are switchers) could be causing noise issues, but once again, it only seems to be a problem at startup, and it always happens if the ROV supply is turned of and then on again shortly after.

If it was noise, I was considering adding some bulk capacitance at the ROV, but I was concerned that this would also inhibit the Fathom-X signal. In fact, could the large amount of existing capacitance be a problem?

Any suggestion for something to try here?

We haven’t run dedicated lines because even if it does work, it’s not a viable solution for us based on our tether.
I’m not sure what it would actually prove, other than it works if you don’t power the module with the same tether lines.
And you already know that.

Does the fact that the LINK LED always blinks once before successfully link help any with a diagnosis?
When it’s going to fail, it never does a pre-blink. As that first blink an indication that the processor is running properly?

Is the module always re-trying to re link?.. that is, what might trigger it to re-try.
We can power the topside off, and leave the ROV powered, but the ROV still doesn’t blink or re-link when the topside powers up.

It really seems like some startup condition is preventing the ROV’s module from initializing properly, since we’ve never gotten it to re-link after it fails the first time…

This is a major show stopper for us if we ever need to power down as a 2 minute wait is a LONG time in a 15 min competition :slight_smile:

I guess I should try power cycling JUST the ROV fathom-X module after 48V is present just to see if I can force a re-link.

(Phil Malone) #4

OK The plot thickens.

I tried several methods to get the ROV to relink after a power down, but to no avail.

I tried JUST cycling the power on the ROV’s Fathom-X after the rest of the ROV was on. I was hoping I could encourage it to start looking for the link again. Nope

I tried replacing my 48V switching supply with a bank of 12V batteries (t eliminate this possible noise source). Nope

Eventually I decided to just switch the LX200V2 modules between the topside and the ROV.

This caused very interesting results… The different topside/downside behaviors that I had been observing switched places.

That is: Now, the ROV Always comes up after a power cycle, but the topside sometimes refuses to show any link LED after a power cycle. So now I know it’s not ROV or Topside specific.

So either there is a code difference between the two modules, or one is faulty in some way.
I’m racing to get my Explorer Demonstration video made, and this is a real problem.

What’s the best way to address this?

I purchased these with my phil.malone@mr-phil.com email account login.

(Jacob) #5

Phil please email support@bluerobotics.com in reference to this issue, it sounds like a replacement is in order.

(Phil Malone) #6

I have sent an Email to support.


(Phil Malone) #7


I received my replacement LX200V2 and I replaced the rogue interface chip.

Now, both ends of the tether work as expected. (Instant relink after power cycle)

Thanks for the fast response.


(Rusty) #8


Great! Glad that was the culprit.