BLTouch Ghost Touch


I am using a HE161192 (Cocoon Create Touch - Australia) with a genuine BLTouch v3.1, a reseller supplied extension cable and ADVi3pp-BLTouch3-Mainboard-4.0.3.hex firmware.

For the most part it is working great, but I am getting “Ghost Touches?” when running the auto bed levelling process. The pin will deploy and then retract again before the Z axis moves, the Z then moves down and touches to plate and moves on, the result is that 1 of the 9 points will ready as being way higher that it actually is, this will happen roughly 1 in 30 touches, the result is I need to watch the level process and re-run if I get a false trigger.

I have checked all my wiring to ensure it wasn’t a loose connector, I have it hot glued on the mainboard end. Any suggestions on how I might be able to track down the issue?


Looks really like a wiring problem. Maybe your soldering on the mainboard? You solder them right? Not just with hot glue?


Yeah, I soldered on new header pins and hot glued the connects to stop them dropping off. I’ll re flow my joints but they were pretty easy spots to solder so I don’t think I will have messed them up. Could also be the pins on the connects so I’ll check those too.

Any other possible causes?


I compiled a while ago some common causes:

Thanks for your help,

I used your steps\guide when I did the install, I’ll check my solder joints and step through it again to be sure, it was purchased through the only Australian authorised re-seller so I know it is genuine.



I pulled my main board out, re-flowed the solder on the header pins (they looked fine), checked that the pins fit firmly, I also made sure to route the cables away from any mains power to ensure it wasn’t causing any interference, but I a still seeing the issue.

There is still some possibility that it is the vendor supplied extension cable, but the end connectors all look very well crimped.

If I go into the menu for the sensor tests it behaves as expected for all tests (self test, deploy, store, etc) and if I have it deploys it stays blue unless I use my finger to push the pin, so it doesn’t appear to be getting any false touches at that point, could it be somehow related to vibrations from moving while running through the leveling routine?

Apart from going back to the vendor to see if I can get another cable\touch to test I am not sure what extra steps to try, so I appreciate any suggestions.


I am seeing the same problem. I am using a HE161192 (Cocoon Create Touch - Australia) with a genuine BLTouch v3.1, a reseller supplied extension cable and ADVi3pp-BLTouch3-Mainboard-4.0.3.hex firmware.
During bed leveling occasionally the pin will stow before the sensor is moved down to touch the build plate, resulting in a false reading. It seems to only occur once in any given cycle (i.e. 8 good readings with one false reading) and the position in the cycle varies, although I haven’t seen it happen in the starting position. I have thoroughly checked all wiring, plugs and solder joints and can’t find any problems. It appears to be a code issue.

I am glad it is not just me, I have see in also stow when testing the home position, but that seems rare. As with you I also only ever see it once during a level routine. At times it can run 3-4 routines without issue, then it can run 3-4 with one stow even per routine, fairly frustrating.

Have you played with the sensor tests in the menu, mine seems fine when running through those. I guess it could be a faulty batch of sensor and\or cable? I purchased mine 23/10.


I have never seen the problem using the sensor tests in the menu. I decided to run it through the sensor tests, using both the self test and the individual deploy and stow tests, for an extended period and sat there doing that for about 30 minutes. There was no sign of any problem at all. This suggests that the sensor itself is fine. This testing doesn’t involve movement of the extruder and subsequent twisting of the wires, however if it was a wiring problem I would expect it to become more regular with use.

The “Test” menu is only testing (to simplify) the orange wire (i.e. the servo), not the white wire (the z-height). So if the “Test” menus are working, it does not mean the BLTouch is working.

Since I have implemented the BLTouch, there were many people with some issues like yours. As far as I know, here are the common causes:

  • Bad connection at the level of the Dupont connectors. This is by far the most common problem.
  • Bad soldering on the Motherboard. Especially, some soldering are close to a 24V line and I suspect that there are sometimes conductivity problems due to the soldering flux (which is conductive)
  • Bad motherboard. I suspect this is related to the previous point (flux, 24V)
  • Bad BLTouch. It happens at least one time.
  • Electronic noise: this kind of printer is very noisy and sometimes, it generated “ghost” signal on other wires. It is difficult to diagnosis without the appropriate tools.
  • New and incompatible BLTouch. It happened when the BLTouch 3 was released. That’s why there are two binaries. If you are not using the right binary, it will not work.

As far as I know, there is currently no problem in the firmware regarding BLTouch support. The implementation is from the Marlin project, so it is used by a lot of people. Of course, a bug is always possible. But I do not think it is the case right now.

The only known problem related to probes is the following:
and it will be fixed in the next release (this month).

Thanks for the reply,

Since the probe stows before the prob is lowered I assume this is most likely an issue with the servo wire?

I did tweak the Dupont connectors when I reassessed my soldering, the orange was little loose for my liking but after a tweak they all appear to have enough friction.

I am confident my soldering is not an issue, I was quite particular with my second run over the joints, I do have some PCB Cleaner so I will give the board a good clean to see if that helps.

I have the cable now routed as far away from power cords as I could to reduce noise.

I don’t really have the ability to test the BLTouch without another device, but with only 1 failure noted I am going to say that is unlikely. The vendor lists the device as a v3.1 and as mentioned above I ordered it a month ago, is there any way to identify if anything has changed?

I don’t think so. It is either a problem with the BLTouch, the z-height wire (white) or the firmware. But I don’t think it is at the level of the orange (servo) wire since it is apparently working well. This wire just gives an angle to the BLTouch and the BLTouch react accordingly.

What some other people have experienced is a bad pin on the motherboard. Some had to use another pin than the one I recommended in the instructions.

Antclabs makes from time to time hardware changes without informing users and without changing the version number. It happened at least one time. So this is another possibility.

On my side, I will look at the Marlin latest commits so see if they made anything related to the BLTouch.

I just solved this problem 10 days ago on my i3 Plus; then I saw this thread today.

I was getting these false readings where the sensor would retract before reaching the build plate. It would happen about once every 10-15 readings, meaning most auto-levelings would fail.

Even after I set DELAY_BEFORE_PROBING to 440ms in Configuration.h, I noticed the sensor would still retract prematurely after the nozzle reached a new location. So I reasoned that the vibration from the X or Y move was causing the problem.

After I added BLTOUCH_DELAY of 500ms the problem went away. Now even when the sensor retracts prematurely, it automatically recovers by deploying again before taking the reading.

It appears I need to use both these settings for it to work. I image these numbers can be slightly fine tuned, but I’m content with completely reliable auto-leveling that takes about 1 minute. I can now run it unattended in the starting G-code of every print.

@DSims which version of BLTouch do you have?

BLTouch V3.1

So it looks like there is something a little different between BLTouch 3.1 and 3.0. I own a BLTouch 2, 2.1, 3.0 but not a 3.1.

I will see if I can adjust the parameters like DELAY_BEFORE_PROBING and BLTOUCH_DELAY without breaking BLTouch 3.0 support.

Just mentioning I have the exact same issue. Same hardware versions of CCT and BLTouch .

For information, I have ordered a BLTouch version 3.1 in order to make tests and ensure ADVi3++ is working with version 3.0 and 3.1. The BLTouch should arrive in a few weeks (in December).

Great, thanks for the hard work,

Just an update, a few days ago I installed a new Y Carriage and a Ultrabase and this seems to reduced some of my vibration, I still get the odd false stow but far less than before.

I then compiled my own version of the firmware and used the same numbers @DSims suggested and this has fixed the issue, obviously the routine is much slower but I rather that than having to reset the print, slow and steady. I still see the odd false stow, but as @DSims mentioned it recovers and reads correctly.


FYI, just installed a bltouch V3.1 this week (same configuration as Wob76) and I am seeing the same issue.
Thanks for the good work on the ADVi3++,