Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Anyone good with phase angles?
This dead horse has been beaten enough, but I got sucked back into it after a couple of years of (successfully) ignoring it.

The OLD iGaging Absolute scales use a 52 bit data packet transmitted every 0.1 seconds. That's a 10Hz refresh rate, so they are pathetically slow for what we want. But there are people out there that still have them. Anyway, the data packet contains a 25 bit data segment that encodes the actual position. That 25 bit segment has 3 data words in it, the Coarse track, the Medium track, and the Fine track. The bit sizes are 8 bit, 8 bit, and 9 bit, respectively.
Through observation and a little math, it's been found the total length of the Coarse track (or period) is 1310.72mm with a frequency of 1, the Medium track has a frequency of 32, and the Fine track has a frequency of 256. The phase offsets are not yet known, but are being worked on. (If you don't feel like doing the math, those numbers give a resolution of 0.01mm, which is what iGaging claims).
Anyway, I'm not all that good with figuring out how to do the phase angle math for the 3 phase angles, and I'd appreciate any help anyone can offer!

FYI, I know this will never be incorporated into the controller firmware. These scales are WAY too slow in their response time and do not seem to be widespread. Custom firmware can be written (I probably will write it for a friend who has these scales) and it'd great to be able to support as many scales as possible!
Ok, good news, and probably some bad news.

Good news first: I finally figured out the old iGaging Absolute data protocol, what the digits mean, how the error correction is done, and why they are so stable. I still don't have the exact solution yet because it relies on getting the exact phase offsets, but we're getting closer on that.

The Bad news: I haven't done any MCU testing yet, since we still don't have the exact values for phase offset, but I don't think that a little MCU will be able to handle the math load for 3 scales at once. It's not difficult math, it even uses fast logic operators and addition and subtraction only, but it requires several operations and branching instructions to arrive at the output value. That is probably the reason why these particular scales are so SLOW updating. Heck, the display unit may even be using an Atmel processor, it wouldn't surprise me.

If anyone is interested in seeing my solution, I can post the Excel workbook I used to a public drive. You can download the workbook, look through the code I have in VBA (I use VBA macros extensively), and see if you agree with me.
I'd love to see your documentation, Brian. Did you make the Excel workbook available for download somewhere?
>> I'd love to see your documentation, Brian. Did you make the Excel workbook available for download somewhere? 
Can I second Trombetta's motion and request to see your Excel workbook?
I'm struggling with the numbers I'm seeing from my iGaging DRO+, they make no sense.
I bleed VBA/VB/QuickBASIC so I'm looking forward learning from what you did.
Igaging Absloute DRO+ scales use a completely different protocol (that is fully supported by TouchDRO). What is the issue with the numbers you are seeing?
Salut à tous,

Salut Brian....

Forum Jump:

Users browsing this thread: 1 Guest(s)