IGaging EZ-View Jumping Position

[ycroosh]

After the lively conversations about the relative merits of TouchDRO when used with iGaging EZ-View scales. That whole discussion "triggered" me a bit, so I decided to experiment more with the code. I'm working on a new version of an improved version of the adapter for iGaging EZ-View scales that is based on a much more powerful processor (ESP32). One of the benefits is that it has gobs of extra processing power, compared to the previous adapter model [and the EZ-View display]. After two evenings on the laptop, I think I have a decent fix. In short, here is what's happening:

• The code oversamples the scale on each reading and averages the values (the whole thing takes about 80 milliseconds).
• If the delta between the old value and the new average is within 1 encoder tick, the code then checks to see if 75% of samples are at least 1 tick away from the old value. If they are, this means that the scale has likely moved by 0.01mm, so the value is updated. Otherwise, the new average is ignored and the old one is used. I could've gone for 100%, but that felt a bit weird on very small movements. The DRO felt sticky.
• If the delta is larger than the "max reasonable distance a scale can move in 0.1s", the code "suspects" a jump. It then checks the samples and if there is only one outlier, it is removed and the position is recalculated.

This doesn't completely fix the flickering of the last readout digit but cuts it down a whole lot. Random momentary jumps are completely gone, though (unless the jump stays, and then it's a different problem). I need to spend some time in the garage and test drive this on a real mill, but on the bench, it worked really well and there is no added lag.

Now I need to figure out if I can cram any of this into the old MSP430 firmware...
Regards
Yuriy

 

[C-Bag]

Interesting you use the term “triggered” as for most people it can mean it made them mad. But it seems like you might be like I am where your mind gets stuck on how to solve a problem. Very commendable. Especially for those of us who don’t have the electronic skills to come up with something like this.

i get what you said to this before but I wish this interface didn’t rely on Bluetooth. I use Bluetooth headphones to listen to stuff on my phone in the shop and on my twice daily walks all over the county. And in the shop drop outs happen all the time. Like if I’m close to my powder coat oven, it drops out when I trigger my powder coat gun. Sometimes around my mill and my lathe. I guess the error correction you mention could make the DRO remember where it is, but the whole thing just doesn’t seem as reliable as hardwired. I don’t care about .0001”ths and the flicker of .001.

Having all my readings on the tablet instead of three read outs like the old EZ view was and the other great features along with not having to mess with batteries is wonderful. I can’t help but think because of my bluetooth headphones dropouts the unreliability is linked to it. But this is WAY more complicated to my pea brain can deal with but I just have to put this out there.

I also get what an impossible task it is to make something for the public. There is no such thing as idiot proof. And any mechanic will tell you cannot get a car to do something intermittent in a shop. Its usually blind luck or past experience that fixes those things. Good luck and best regards.

 

[Winegrower]

I also get what an impossible task it is to make something for the public.

Folks who have not tried to make a product for the general market do not realize how difficult it is, and how much time and thought goes into every facet of the design and development. It's one thing to get a design to work on the bench, and to make a few copies, but putting it into a box and selling to anybody, skilled or unskilled, and into any environment, controlled or uncontrolled, is entirely different. My hat is off to Yuriy, and I wish him well.

Edit: I remember as a young engineer at HP taking my first product to market...my seasoned old boss asked how the pilot run went and I said "great, out of the ten units, I only had two problems". He said, ok, but that's 20 out of the first 100 and 200 out of the first 1000. Oh, I never had it explained to me like that before.

 

[markba633csi]

Sounds good Yuriy. Of course we still don't know why the large jumps occur. Perhaps eventually that will reveal itself.
Looks like the last item on your list would give the most improvement, if you can cram that in the old board I think you nailed most of it
-Mark

 

[ycroosh]

Interesting you use the term “triggered” as for most people it can mean it made them mad. But it seems like you might be like I am where your mind gets stuck on how to solve a problem. Very commendable. Especially for those of us who don’t have the electronic skills to come up with something like this.

i get what you said to this before but I wish this interface didn’t rely on Bluetooth. I use Bluetooth headphones to listen to stuff on my phone in the shop and on my twice daily walks all over the county. And in the shop drop outs happen all the time. Like if I’m close to my powder coat oven, it drops out when I trigger my powder coat gun. Sometimes around my mill and my lathe. I guess the error correction you mention could make the DRO remember where it is, but the whole thing just doesn’t seem as reliable as hardwired. I don’t care about .0001”ths and the flicker of .001.

Having all my readings on the tablet instead of three read outs like the old EZ view was and the other great features along with not having to mess with batteries is wonderful. I can’t help but think because of my bluetooth headphones dropouts the unreliability is linked to it. But this is WAY more complicated to my pea brain can deal with but I just have to put this out there.

I also get what an impossible task it is to make something for the public. There is no such thing as idiot proof. And any mechanic will tell you cannot get a car to do something intermittent in a shop. Its usually blind luck or past experience that fixes those things. Good luck and best regards.

Well, I got "mad" at the problem. Does that count?

I get a lot of questions about BlueTooth, so your concerns are not unique, but in practice, those problems are not an issue. Bluetooth protocol has layers of redundancy and error correction built into it. It uses a packet protocol with parity check and receipt acknowledgment, so any time there is a glitch or a packet is missed, that packet gets resent until it's received correctly. The anecdotes about Bluetooth headphones dropping out are not really an apples-to-apples comparison. BlueTooth 2.0 [that many headphones still use, because it's much cheaper] wasn't designed for audio. To get any sort of fidelity in 2.0, audio devices have to fully sturate the "bus", which leaves little space for parity check. If the link is bad, the overhead of resending the same packet over and overuses up the bandwidth. TouchDRO uses less than 0.1% of the available bandwidth, so even when 99% of packets are bad, the position will still get through. Think about it, in every office building there are hundreds of wireless mice, keyboards, and headphones and the protocol can handle that. Similarly, it works just fine in most cars next to noise ignition coils, alternator, gas pump, and who knows how many other motors and computers.
In my experience, I've had a LOT more complaints from people using a USB connection. The only issues I get with BlueTooth are the HC-05 modules crapping out randomly, but even that happens very infrequently in the field (I test the crap out of them before sending them before assembly and my defect rate is about 7%. In the field I've had around only a handful of failures over the years).

Hope this makes sense
Yuriy

 

[C-Bag]

As often happens when I’m trying to explain something a solution to another problem also falls out. This happened as I was writing the last post.

One thing I’d not been able to figure out was how to run the DRO and tablet on battery power and it “dawned” on me I had big stand alone battery pack that I bought for when we were on the road a lot and couldn’t charge our phones and tablets in the airport. It can easily run both things for days as it has the capacity to charge my iPad and phones several times. So I’m charging it back up to full capacity and see if that makes any difference in this mess and possibly isolate a possible problem. Sorry I didn’t think of this before.

 

[ycroosh]

Sounds good Yuriy. Of course we still don't know why the large jumps occur. Perhaps eventually that will reveal itself.
Looks like the last item on your list would give the most improvement, if you can cram that in the old board I think you nailed most of it
-Mark

Mark,
I have a decent theory about the momentary jumps, but not the permanent ones.
iGaging scales get the data clock from the display unit. One think that I noticed was that the time between the rising clock edge and the scale changing the next bit is not constant. The MCU either does that with software polling, or disables the interrupt while it does some other critical task. My theory is that the scale can miss a pulse in some cases. I set up an experiment where I ran a scale for a week [connected to Raspberry Pi] and recorded any readings that were more than 10 picks below or above average (the scale was stationary). I got a few dozen readings and they all had one thing in common: a single bit in the data stream was different from the previous reading. Furthermore, in all cases the bit had the same value as the bit right before it. I surmised that the sale must've missed or ignored a clock pulse and didn't flit the bit as needed.

 

[markba633csi]

I think you deserve a beer, maybe two