TouchDRO Build 2024-03-11 (Beta)

[ycroosh]

Hi, Yuriy, glad you’re feeling up to posting again.

A question regarding powering up: while I have always followed this procedure it can be a pain since I have backup batteries installed in both adapters so have to open the case to unplug the battery - is disconnecting the battery necessary?

Thanks & best regards, Charlie

Charlie,
The backup battery is only providing power to the scales, so no need to disconnect it, since the main processor will be powered down.
Regards
Yuriy

 

[ChazzC]

Charlie,
The backup battery is only providing power to the scales, so no need to disconnect it, since the main processor will be powered down.
Regards
Yuriy

Thanks, Yuriy! That makes sense and will make things easier in the future, particularly on the Mini-Lathe installation with how I routed the wires & mounted the box:

 

[ycroosh]

Thanks, Yuriy! That makes sense and will make things easier in the future, particularly on the Mini-Lathe installation with how I routed the wires & mounted the box:

View attachment 485425

View attachment 485426

You know, some people jump through all sorts of hoops to get these scales to behave. This includes careful cable routing, grounding, shielding, etc. The gods of electronics must REALLY love you if your scales work fine with that box of spaghetti (or, the cables are so tangled that noise can't figure out how to get into them...)

 

[ChazzC]

You know, some people jump through all sorts of hoops to get these scales to behave. This includes careful cable routing, grounding, shielding, etc. The gods of electronics must REALLY love you if your scales work fine with that box of spaghetti (or, the cables are so tangled that noise can't figure out how to get into them...)

Then you’ll really like the power side of things:

BTW, did you ever link up with George @ HSM?

 

[Backporch]

Hi Yuriy,

Starting off with a little history:

Between my purchase of a Drewtronics probe in February of ‘23 and last week my probe interface worked just as your setup - input ground for no-touch, high (open - pulled-up) when touching, relevant transitions are low to high. Invert setting in the app was always off.

The talk about the "invert" setting and electrically inverting my probe output were my flailing about in order to understand what was going on after this beta was pushed and things stopped working (for me) and turn out to have no material bearing on the real issue. (A "red herring" in mystery literature.)

On to some experiments:

In the normal case ((ground for no-touch) both of my v2 glass adapters produce these results (using a momentary switch between the board’s input pin and ground in place of the probe):
--------------------------------------------------
input ground at power-up
then connect bluetooth terminal
Opened (high) for something under a second then grounded again.

20:00:08.668 Connecting to TouchDRO ...
20:00:09.116 Connected
20:00:09.156 x0;y0;z0;w0;x0;y0;z0;w0;t0;x0;y0;z0;w0;x0;y0;z0;w0;x0;y0;z0;w0;x0;y0;z0;w0;x0;y0;z0;w0;x0;y0;z0;w0;p1;p1;p1;p1;p1;p1;p1;p0;p0;p0;p0;p0;p0;p0;p0;p0;p0;x0;y0;z0;w0;x0;y0;z0;w0;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;x0;y0;z0;w0;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;x0;y0;z0;w0;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;x0;y0;z0;w0;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;x0;y0;z0;w0;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;t0;p1;p1;p1;p1;p1;p1;p1;p1;p1;x0;y0;z0;w0;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;x0;y0;z0;w0;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;x0;y0;z0;w0;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;x0;y0;z0;w0;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;x0;y0;z0;w0;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;x0;y0;z0;w0;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;x0;y0;z0;w0;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;x0;y0;z0;w0;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;x0;y0;z0;w0;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;x0;y0;z0;w0;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;t0;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;x0;y0;z0;w0;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;x0;y0;z0;w0;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;x0;y0;z0;w0;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;x0;y0;z0;w0;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;x0;y0;z0;w0;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;x0;y0;z0;w0;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;
20:00:37.079 Disconnected
--------------------------------------------------

Clearly not the described behavior.

I put a scope on the probe input to the ESP32 (pad 9, IO33) and the signal looks clean with the switch bounce all finished by ~800us after the transition. Both the 5V and 3.3v supplies look fine.


You asked for the results for a normally open (touch-low) case:
--------------------------------------------------
input open (pulled high) at power-up
then connect bluetooth terminal
input grounded for something under a second then opened again

20:10:12.483 Connecting to TouchDRO ...
20:10:15.138 Connected
20:10:15.157 x0;y0;z0;w0;t0;x0;y0;z0;w0;x0;y0;z0;w0;x0;y0;z0;w0;x0;y0;z0;w0;x0;y0;z0;w0;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;x0;y0;z0;w0;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p1;p0;p0;p0;p0;p0;p0;x0;y0;z0;w0;p0;p0;p0;p0;x0;y0;z0;w0;x0;y0;z0;w0;x0;y0;z0;w0;t0;x0;y0;z0;w0;x0;y0;z0;w0;x0;y0;z0;w0;x0;y0;z0;w0;x0;y0;z0;w0;x0;y0;z0;w0;x0;y0;z0;w0;x0;y0;z0;w0;x0;y0;z0;w0;x0;y0;z0;w0;t0;x0;y0;z0;w0;x0;y0;z0;w0;x0;y0;z0;w0;x0;y0;z0;w0;x0;y0;z0;w0;x0;y0;z0;w0;x0;y0;z0;w0;x0;y0;z0;w0;x0;y0;z0;w0;x0;y0;z0;w0;t0;x0;y0;z0;w0;x0;y0;z0;w0;x0;y0;z0;w0;x0;y0;z0;w0;x0;y0;z0;w0;x0;y0;z0;w0;x0;y0;z0;w0;x0;y0;z0;w0;x0;y0;z0;w0;x0;y0;z0;w0;t0;x0;y0;z0;w0;x0;y0;z0;w0;
20:10:57.727 Disconnected
--------------------------------------------------

Looks more like what you described. But if I understand what you said in our PM, using touch-low is not optimal(?).


Sooooo, I’m thinking the underlying issue is with these particular adapters. Both boards (DRO Adapter for Glass Scales Standard Kit Item# WEB_QUAD_4_AXIS_SOLDER) were purchased in October, 2021 and are marked Rev 2.0 in the silkscreen and 1.0 in pen. Not sure where these are in the evolution of this board's hardware/firmware.

Ever since I started using the probe (again normally low, touch-high) I have had issues with “noisy” touch results. The UI is set for three samples with the spread alarm at .0008” and often requires two or three tries to get an error free acquisition even if I’m careful to approach very slowly. When it fails it’s usually by several mills. Annoying but useable and so never quite got to the point where I wanted to take the time to investigate. Perhaps this behavior was related to all the spurious “spam” data these boards are generating?

It would seem that the change in the touch-probe UI’s behavior between this beta and previous releases has to do with how the new optimizations to the touch algorithm react to all the “spam" these boards are producing - not an issue for properly working adapters.

Please advise on how to proceed.

Regards, Louis

 

[ycroosh]

Louis,
Message #19 is in response to this (when you sent it to me via email).
Can you post the terminal output for this:

1. Disconnect the probe
2. Reboot the board
3. Confirm that you are getting p0 (or no "p" input at all)
4. Connect the probe signal pin to the ground somehow
5. Confirm that you are getting p1 for as long as the pin is grounded
6. Disconnect the probe input from the ground
7. Confirm that you are getting a few "p0" data point and then no "p".

Thank you
Yuriy

 

[Backporch]

This is basically the second "normally open" test above but I did go back and verify that the P channel was quiet for a time until the input is grounded then the P1 state continues for as long as the input is grounded and then when opened would then output a few (8-10) P0s before the P channel goes quiet. Did several trials up to 20 seconds - all looked as expected.

 

[ycroosh]

This is basically the second "normally open" test above but I did go back and verify that the P channel was quiet for a time until the input is grounded then the P1 state continues for as long as the input is grounded and then when opened would then output a few (8-10) P0s before the P channel goes quiet. Did several trials up to 20 seconds - all looked as expected.

This is the expected behavior. There should be no lag in this case (the firmware treats P0 -> P1 transition as a high priority interrupt, so there should be no more than 4us (in the old firmware) before the encoder counts are captured (there will be some delay in the transmission, but it's not important, since the thing that matters is the position where the probe triggered, not the time when the app received it).
The firmware AND the app have debouncing code, so in practice the app will only care about the first P1 data point. The rest is just for "sanity checking".

 

[Backporch]

Hi Yuriy,

I'm confused, isn't the "normally closed" case (ground = no-touch, high = touch) the way the probe input is usually used? I believe it's how you described your setup works. This is the case where my boards are generating all the "spam" - kinda-sorta-almost working with the previous app versions but unusable with the new code. Definitely doesn't seem like normal behavior.

The fact that the "normally open" case works as it's supposed to makes me think the ESP32s are ever less likely to be the problem leaving the firmware shipped on these boards as the most likely issue(?). Can you tell from the nomenclature I described or is there another way to see what firmware I have and determine if any relevant fixes have been made along the way? Boards are circa October, '21 and are marked Rev. 2.0 in the silkscreen and 1.0 in pen ink.

In the interest of being useful for beta testing and not wasting anymore of everyone's (especially your) valuable time chasing red herrings, I would like to get things working as they're intended. Please advise.

Thanks for your help with this, Louis

 

[ycroosh]

Hi Yuriy,

I'm confused, isn't the "normally closed" case (ground = no-touch, high = touch) the way the probe input is usually used? I believe it's how you described your setup works. This is the case where my boards are generating all the "spam" - kinda-sorta-almost working with the previous app versions but unusable with the new code. Definitely doesn't seem like normal behavior.

The fact that the "normally open" case works as it's supposed to makes me think the ESP32s are ever less likely to be the problem leaving the firmware shipped on these boards as the most likely issue(?). Can you tell from the nomenclature I described or is there another way to see what firmware I have and determine if any relevant fixes have been made along the way? Boards are circa October, '21 and are marked Rev. 2.0 in the silkscreen and 1.0 in pen ink.

In the interest of being useful for beta testing and not wasting anymore of everyone's (especially your) valuable time chasing red herrings, I would like to get things working as they're intended. Please advise.

Thanks for your help with this, Louis

Louis,
Sorry for the delay - had to push a bug fix ASAP.
So, I'm a bit confused (I think) - I though you had the probe inverted to have the LED light up brightly. That would make your probe normally-open, no?

In any case, the hardware seems to be working (since you are getting correct behavior with NO probe).
The app should be working correctly since the last build. I tested the crap out of it over the last few days, and it handles probe input correctly.
The only thing that is left is firmware. I haven't had a chance to dig into it more, but will try tomorrow if nothing else catches fire.

Rev. 2.0 was the last revision of that adapter (Rev. 1.x had micro-USB connector on the front and the aux inputs were oriented differently. The circuit was identical. Rev. 1.0 written in pen ink is the firmware version. It was the only revision of the firmware.
The code checks the probe input during boot (it reads the pin status and sets it as the "default value" and sets the interrupt edge to be opposite from the default value). The code is brain-dead simple, so I don't understand how it's mis-behaving:

//get default probe state and store it for future use
sProbe.default_value = GPIO.in1.data & PROBE_INPUT_PIN_SEL;
//enable probe pin interrupt (we only care for the edge going from "off" to "on")
gpio_set_direction(PROBE, GPIO_MODE_INPUT);
gpio_set_pull_mode(PROBE, GPIO_PULLDOWN_ONLY);
gpio_set_intr_type(PROBE, sProbe.default_value ? GPIO_INTR_NEGEDGE : GPIO_INTR_POSEDGE);
gpio_intr_enable(PROBE);

I'll keep digging.
Regards
Yuriy