PCB repair for cliff sensor fault

[barry1602]

Hi all.

Having successfully repaired a couple of PCBs in the past for 500 series robots I am about to start researching a fault with another PCB I have but I wanted to see if anybody on here has any input first that might save me some time, or better still somebody on here may have already come across a fix for said problem and save me the trouble!

So the issue is thus:

I have a 560 PCB which comes up with "please inspect and clean Roomba's cliff sensors" either when clean is pressed or sometimes a little way into the cleaning process.
Now obviously I have done all the usual checks etc to confirm that the fault is actually on the PCB and not on the cliff sensors (nothing would thrill me more than just to replace the cliff sensors and be done with!).

I was wondering if anybody has any ideas on parts to check or replace on the board to rectify the problem?

I know I could just buy a new PCB but I don't want to spend £50 on a PCB when the fault is actually a small component that will likely cost less than £3 or that I could take from another dead Roomba PCB.

Thanks in advance.

Barry

[Gordon]

...Now obviously I have done all the usual checks etc to confirm that the fault is actually on the PCB and not on the cliff sensors ...

And did all that checking include dismantling cliff-sensor assemblies down where you get inside the clear plastic enclosures to wipe out all accumulated dust (that might be interfering with sensor ops)?

[barry1602]

I have done extensive testing on this to confirm that it is the Pcb at fault and not the actual sensors. I have several other working roombas that I have switched the board with. I can get a perfectly working roomba, switch this Pcb into it and it will come up with the same fault.

[Gordon]

I have done extensive testing on this to confirm that it is the Pcb at fault and not the actual sensors. ...

All right then. I suggest using your O-scope to probe the base pin of Q56 (a bottom mounted S8050, NPN xstr in TO-92 case) to verify pulsed wave train activity. Reference the measurement to "GND". Measure to base and collector solder pads on top side of PCB (to keep the task easy).

If pulsed action is seen on the base, shift the probe to Q56c to see whether similar pulse action exists there. IREDs will light up as collector voltage is pulled low, and go dark as collector voltage rises to ~ VBAT level. If you find that S8050 has gone kaput, it'll not be the first one to bite the dust!

[barry1602]

OK Gordon, so you caught me out... I don't have an oscilloscope!

But what I did have was an S8050 spare from a historical repair to a different robot. I have switched that out just for the sake of it really and it made no difference.

Also what I forgot to put in my original post is that if I do the BIT procedure, the cliff sensors test out ok.

What I have is a digital metre, a heap of spare parts and some good soldering ability!

[Gordon]

...Also what I forgot to put in my original post is that if I do the BIT procedure, the cliff sensors test out ok. ...

Well !! That's a horse of a different color!

You might try this test process (in which you use your DVM for relative measurements):

1) With measurement access to top face of main_PCA, do:
2) step into the Cliffs' BiTs.
3) Take and record 'voltage' readings at Q56b & Q56c.
4) Quit the BiTs.
5) Starting with Roomba in its (so called) OFF state, press Clean once (to initiate what I call "STBY" state).
6) Repeat element (3). {I'm thinking all IREDs will be activated, even though motors are OFF}
7) Cease data acquisition, turn OFF Roomba or let time out to OFF.
8) Compare results of (6) with those of (3).

I'm expecting you will measure no base drive to Q56 in step (6).

If you question whether the Cliff IREDs will be driven with the robot in STBY, you should locate xstrs Q54 & Q55, which drive the Light Touch IREDs, and verify driving action by measuring to Q54b & Q55b. (Both xstrs are w/in 4 to 20 mm of the PCB's curved edge.

Thus, IF you find Q54 & Q55 acting properly, but find Q56 not 'acting' at all, there is no base signal to Q56.
Therefore, IMHO, the only culprit to blame is U28, the robot's MCU. More specifically it would be the contained firmware that fails (due some induced code fault) to control the MCU.

[theirobotchannel]

I have a slightly different situation, I have over 20 PCB laying around that dont work properly, so right now trying to fix one, and doing the BiT the cliff sensors dont pass, I check voltage going to the IR LED and there is none, so what is the situation, and I did check with the working Cliff sesonrs, since I have a ton of them that do work, so where do I begin, let me know, thanks.

[barry1602]

Thanks for your help Gordon.

Apologies for the delay in getting back to this but some other projects have kept me away from playing with robots.

I have done as you said above and I am finding that I get the same reading at Q56 at points 3 and 6. so there is a base drive to q56.

[barry1602]

Ok so a further update......

It would appear I made a mistake when carrying out the BIT!
It's difficult as the fault keeps coming and going - at least this is my excuse for the mistake - basically I am finding that the left inner cliff sensor is showing a constant cliff (again I know this to be a PCB fault and not a faulty cliff sensor) but the fault does come and go. It would seem that I can carry out the BIT and it fails but after a couple of minutes it will clear and the test will pass and the robot will work fine for a few minutes before the fault returns.

Thanks in advance if anybody is able to help.

[Gordon]

Ok so a further update... - basically I am finding that the left inner cliff sensor is showing a constant cliff (again I know this to be a PCB fault and not a faulty cliff sensor) but the fault does come and go. ...

By ascribing faulty Roomba operation to a specific cliff-sensor module's detected signal you rule out everything except for how that signal is treated on its way to the MCU, or within the MCU.

I know the components between R2-Roomba's cliff-phototransitors, (cliff-PTs), and that Roomba's MCU are 1k resistors, bypass capacitors (and possibly voltage clipping diodes), but I do not know what the R3-Roomba signal path looks like between its four cliff-PTs and their MCU ports. However, I think that left inner cliff-PT collector output is the signal path that requires study while the failure is at hand.

[iMayne]

Barry, before needing to do any technical stuff you can place the robot on a light-coloured carpet or clear tiles and do a cleaning mission. I assume the robot goes over a much darker area then issues out the error. Second I would make sure the cliff sensor clear plastic is cleaned ( I'd say was them). I have seen scratches on the clear plastic that DO cause the issue. Experienced with 4 with that issue. If all what I have said solves nothing then it's time to get technical.

I have seen you have tried different boards but what about cliff sensors?

Try Roomba on clear tiles or swapping cliff sensors.

[barry1602]

Thanks iMayne but these are all simple things I checked out before going anywhere with this task. I tried the PCB in a few different working robots and determined that the fault was definately with the PCB.

I traced the fault back through the circuits to the MCU, so have assumed the fault is within the MCU.
(Another PCb for parts!)

Thanks Gordon and others for all your help.

[matofill]

Now i have completely the same problem like Barry1602, Roomba 530 PCB , they do not want start, they only said “please inspect and clean Roomba s cliff sensors”.

Also i put this PCB to 2 different robots and it is the same, then i put another PCB to that Roomba 530 and it works fine, so I am sure problem is at PCB.

Roomba do not put any error, but they do not pass test for cliff sensors ( all another tests done OK ). i have more defective PCB plate for Roombas, but i do not know a lot about all electronics,
but I can measure some component or replace some component on PCB . Can someone suggest which elements on boards can be defective in this case.

Thanks for helping and i apologize for my bad English, i hope you can understand all.

[supradupafast]

I've gone through several robots with this problem. (All of them 4xxx)
To find out which Sensor isn't working, I use the digital camera from my cellphone to determine which one isn't working (or you can run the BIT). Once you determine that, use a multi tester to find out if there's any voltage going to the IRs LED / Detector. If there is, then you have a burnt sensor, if you don't, then most likely the board. In the burnt board case, I don't bother replacing it, I just plug the defective sensor in series to one of the middle ones and voila...
Easy and cheapest way to fix, and works just as new.
Just my 2 cents, i'm no tech guy...

[matofill]

Sorry, but it is not sensor it is 100% problem on PCB board series 500, so which elements at board can be responsible for that fault ?

[matofill]

No new ideas ???

[matofill]

[Gordon]

... it is 100% problem on PCB board series 500, so which elements at board can be responsible for that fault ?

You have had more than a month to read this thread and, by doing so, learn one answer to your question.

If you have indeed read all posts that preceded yours in this thread and failed to recognize that information, then troubleshooting this problem may be beyond your means.