Quick update on our progress.

Turned out the v4.3 scales use the same data format as the v3.1 scales, just with a lower resolution. The v4.3 scales are around 2,560 CPI vs the 7,680 CPI of the v3.1 scales.

The position “Jump”, as I’ve termed it, that I’m seeing is due to the nature of a recycling, fixed length binary number system. I’ll try giving a simplified explanation of why this is happening.

Think of it like a car odometer. As you drive, the odometer counts up linearly until it gets to 999,999.9 miles. At this point, traveling any further causes it to roll over back to 000,000.0 again.

A set length binary number sequence works much the same way, the only difference being if it is treated as a “Signed” or “Unsigned” integer. In this case, the 8-bit Coarse track can have a value from 0 to 255 as a unsigned integer or -128 to 127 as a signed integer.

When these scales were produced, the manufacturer used the encoded tape that recycled approximately every 50.5 inches where the sequence repeated itself over and over. They then cut the scales to the desired lengths with ~50.5” being the maximum possible length any one scale could be, although the longest scale sold that I know of was either 36” or 38”.

The gist of the problem lies in that if a particular scale had the tape segment on it where the Coarse track recycles from 255 back to 0, if treated as an unsigned integer, or when it cycles from +127 to -128, if treated as a signed integer. These are two different points on the scale tape since, as a signed integer, the sequence actually goes from 0 to 127 at the Coarse track mid-point where it jumps to -128 and starts counting (becoming less negative) back to zero.

For any single scale, the solution is easy. Just make it a signed or unsigned integer if needed. The problem comes about when combining multiple scale outputs together, as in the case of a 3-axis DRO. As it happens, one of my scales has the Coarse track mid-point on it and another has the Coarse track recycle point on it. So if the algorithm code treats the input as a signed integer, I see a jump on one axis and if it treats the input as an unsigned integer, I see the position jump on the other axis.

The only two possible solutions I can think of for this issue are:

1. Figure out a way to handle each axis input separately via some manually input variable to dictate if it is to be treated as a signed or unsigned integer.

2. Use multiple controller boards. One coded to use signed integers and the other coded to use unsigned integers along with possibly a third board to combine the output of the other two.

This assumes that no scale was ever cut that contained both of these transition points along its length. If one does exist, neither of these solutions will work for that scale.

Currently trying to figure out if it’s possible to do solution #1, if within the ability of a single Arduino board.

Solution #2 will work, but requires re-writing the code for each of the boards along with the added expense of needing more hardware to make the controller.