LDC1612 Eddy questions

General Discussion
1

Basic Information:

Printer Model: Voron 2.4
MCU / Printerboard: Fly D8
Host / SBC MiniPC
klippy.log

Fill out above information and in all cases attach your klippy.log file (use zip to compress it, if too big). Pasting your printer.cfg is not needed
Be sure to check our “Knowledge Base” Category first. Most relevant items, e.g. error messages, are covered there

Describe your issue:

I have no issue, may be i need use differnt category

I have a siboor cartographer. I have flashed it with Klipper and performed the initial setup. Overall, everything works well, but I would like to understand a little better what the correct reg_drive_current value is.

If I run the standard LDC_CALIBRATE_DRIVE_CURRENT test without changing the code, the auto-calibration gives values of 27-30.

As far as I understand, the siboor cartographer has only one coil, so it seems to me that HIGH_CURRENT_DRV can be enabled in the LDC1612 settings.

High Current Sensor Drive b0: The LDC will drive all channels with normal sensor current (1.5mA max). b1: The LDC will drive channel 0 with current >1.5mA. This mode is not supported if AUTOSCAN_EN = b1 (multichannel mode).

If I enable HIGH_CURRENT_DRV in the LDC1612 settings, the auto-calibration gives values of 18-24.
I enable it like this: self.sensor.set_reg(REG_CONFIG, 0x001 | (1<<9) | (1<<6))

At the same time, the scan calibration always gives approximately the same values.

reg_drive_current 18 with HIGH_CURRENT_DRV enabled

z_offset: 3.010 # noise 0.000122mm, MAD_Hz=2.328
z_offset: 2.010 # noise 0.000098mm, MAD_Hz=2.900
z_offset: 1.010 # noise 0.000086mm, MAD_Hz=4.227
z_offset: 0.530 # noise 0.000028mm, MAD_Hz=1.788
z_offset: 0.250 # noise 0.000032mm, MAD_Hz=2.328
Total frequency range: 137232.542 Hz
probe_eddy_current: noise 0.000157mm, MAD_Hz=4.261 in 2523 queries

reg_drive_current 24 with HIGH_CURRENT_DRV enabled

z_offset: 3.010 # noise 0.000102mm, MAD_Hz=2.146
z_offset: 2.010 # noise 0.000149mm, MAD_Hz=5.093
z_offset: 1.010 # noise 0.000150mm, MAD_Hz=8.196
z_offset: 0.530 # noise 0.000021mm, MAD_Hz=1.509
z_offset: 0.250 # noise 0.000151mm, MAD_Hz=12.589
Total frequency range: 154509.662 Hz
probe_eddy_current: noise 0.000167mm, MAD_Hz=5.763 in 2524 queries

reg_drive_current 27 with HIGH_CURRENT_DRV disabled

z_offset: 3.010 # noise 0.000351mm, MAD_Hz=6.609
z_offset: 2.010 # noise 0.000130mm, MAD_Hz=4.009
z_offset: 1.010 # noise 0.000071mm, MAD_Hz=3.426
z_offset: 0.530 # noise 0.000113mm, MAD_Hz=7.124
z_offset: 0.250 # noise 0.000122mm, MAD_Hz=9.152
Total frequency range: 139040.161 Hz
probe_eddy_current: noise 0.000157mm, MAD_Hz=4.756 in 2528 queries

reg_drive_current 30 with HIGH_CURRENT_DRV disabled


z_offset: 3.010 # noise 0.000030mm, MAD_Hz=0.644
z_offset: 2.010 # noise 0.000189mm, MAD_Hz=6.348
z_offset: 1.010 # noise 0.000217mm, MAD_Hz=10.915
z_offset: 0.530 # noise 0.000133mm, MAD_Hz=8.544
z_offset: 0.250 # noise 0.000171mm, MAD_Hz=13.003
Total frequency range: 147287.271 Hz
probe_eddy_current: noise 0.000179mm, MAD_Hz=5.915 in 2526 queries

I have the following questions:

Should I enable HIGH_CURRENT_DRV or leave it as default, and what values should I use?

Would it be worth implementing a dynamic reg_drive_current? According to the documentation, it is recommended to set it dynamically when there is a wide range to the measured surface.

Why is there no sleep implemented in the _finish_measurements method in the ldc1612.py code? Perhaps it is necessary to set SLEEP_MODE_EN to 1. Documentation say

Sleep Mode Enable Enter or exit low power Sleep Mode. b0: Device is active. b1: Device is in Sleep Mode.

…

1 Like
2

I did investigate the topic here:

The important thing, is this:
Measurements are taken with a multimeter on a 5V board supply.
(Weird drops of current or if there are no significant changes - N/A)

mode Current Boost=0 Boost=1
Standby 17.61 mA 17.70 mA
IDRIVE 1 +0.65 mA +0.67 mA
IDRIVE 7 N/A +0.81 mA
IDRIVE 9 N/A +0.88 mA
IDRIVE 10 N/A +0.93 mA
IDRIVE 11 N/A +1.04 mA
IDRIVE 13 +0.73 mA +1.20 mA
IDRIVE 15 +0.75 mA +1.43 mA
IDRIVE 16 +1.22 mA +2.02 mA
IDRIVE 17 +1.37 mA +2.33 mA
IDRIVE 19 +1.41 mA +2.63 mA
IDRIVE 20 +1.51 mA +2,82 mA
IDRIVE 21 N/A +3.17 mA
IDRIVE 22 N/A +3.57 mA
IDRIVE 23 +1.67 mA +4.06 mA
IDRIVE 24 N/A +4.20 mA
IDRIVE 25 +1.81 mA +4.67 mA
IDRIVE 27 +2.05 mA +5.65 mA
IDRIVE 29 +2.35 mA SKIP
IDRIVE 30 +2.42 mA SKIP
IDRIVE 31 +2.74 mA SKIP

So, your Boost=1 IDRIVE=18 is roughtly equal to Boost=0 IDRIVE=29.

The SNR noise 0.0000... is basically the only metric that we are interested in.
So, if there is no difference, then it mostly does not make sense.

Where it may be beneficial for the probe, if the current significantly increases the resolution, like 30kHz → 60kHz.

Hope that helps,
-Timofey

3

Thank you for your explanation.

Maybe then add a setting that enables boost to give the user the choise?

And what do you think about the other ideas:

Dynamically setting reg_drive_current depending on temperature, altitude, or both.

And setting SLEEP_MODE_EN in the _finish_measurements method.

I understand the last thing is not very important, but it can be done very simply.

4

The question then is:
How should the user make a choice?
In other words, why should “I” enable/disable boost current?

As mentioned above, the only thing one has to care about is SNR.
If one can prove that it substantially improves anything, it is worth considering.
Example of substantial improvements:

Example of improvements, where the justification of work is questionable in my humble opinion:

To sum up,
The amount of work to use M*N matrix of current/temperature/altitude & etc, seems x100 to me.
From all my previous tests, I expect zero practical difference.

This is the only thing that I would personally consider, but I did not find any reason to touch that.
For example, it seems not to affect the self-heating of the PCB coil.
Probably because currents are small.
Another possible reason can be that it is affecting other hardware on the PCB, for example, the accelerometer (EMI).

Alas, in my testing, there was no practical difference, so I can’t make a reason to propose this change, aside from “Probably we can make it sleep, because we do not use it in the meantime”.
On the other hand, I can’t reason against it.

-Timofey