# Touch Dro Fix For Igaging Absolute Dro Scales (i Hope)



## JPigg55

Okay, a little info up front.
A friend of mine at work (thank you Brian Quinn) connected one of my iGaging Absolute DRO scale up to his O-scope.
What he found is as follows:
1.  The iGaging Absolute scales are a 52 bit (Mitutoyo protocol) data set (13 digits, 4 bits per digit.).
2.  Delay time for read head is 70 msecs
3.  Verified clock speed is 2KHz (down from the originals at 9KHz)
4.  Duty cycle remains at 20. (used for chip loading function for Tach)
Being a bit of an avid programmer as well, he proceeded to make the necessary changes to the version 3.3 on Yuriy’s Toys Touch DRO site ( http://www.yuriystoys.com/ )
While perusing the site, he noticed Ryszard’s update link. He said that version did a much better job at averaging the data sets for a more stable reading/output.
_(Ryszard Malinowski has made significant upgrades to my original Arduino v3 sketch. His version handles HAL sensors and low RPM much better than the original version. The documentation and the download links can be found on his website (http://www.yuriystoys.com/p/downloads.html)_


I deleted the sketch as it won't work in the current format. Getting closer and will continue to update until it works.


----------



## RJSakowski

Thanks for picking up the ball and running with it!


----------



## Navy Chief

Awesome, please let us know how the testing goes!


----------



## ch2co

JPigg, thanks for keeping at it!  I'm waiting with baited breath. I might dive in and make one of these things sometime this winter.

Chuck the grumpy old guy


----------



## JPigg55

I'm hoping to finish one of my controllers this weekend and test it out.
Brian told me today there may be an issue with the number of digits per event, but would be an easy software/sketch fix if it doesn't work.
BTW:
I forgot to mention, the magnetic strip on the scales is number encoded. This is where the Absolute value comes from.
This means that it should not lose position even with a power loss, therefore, the battery back-up add-on isn't needed.


----------



## JPigg55

Well, didn't finish my controller. Messed up and used the standard build instructions instead of the wireless. There are differences.
I did, however, put together a single axis feed on an electronics learning test board I have from RadioShack.
It powered up and transmitted to mytablet and interfaced with the Touch DRO APP, but the reading jumped all over the place.
Going to take a little more adjusting to the sketch (and possibly the hardware). Will keep updating as the testing progresses.


----------



## JPigg55

Second program fix done. Hopefully get it connected and tested in the next couple days.


----------



## middle.road

Thanks JP  for keeping us informed of your progress.


----------



## JPigg55

One controller build complete.
Tried to re-flash new sketch to Arduino board, but issue with long integers being too long.
Another fix in the works.
Hopefully, third times the charm, will keep you posted.


----------



## JPigg55

Latest rev of Arduino for igaging Absolute scales ready. This one compiles without any errors.
Loaded it up last night and tried testing it, but had issues with the Bluetooth module due to mistakes in my build.
Will attempt to fix hardware issues today and re-test.


----------



## JPigg55

Well, my buddy Brian thinks he has this licked.
I'll be taking my controller and one of my scales to him friday so he can test it all out this weekend.
So, hopefully, will have the complete sketch & instuctions first of next week.
He's also working on a fix for the Launchpad version which I'll also post for those who have/prefer that vversion.


----------



## Navy Chief

Thanks for the effort on this, looking forward to the results of the testing. I am sure that the rest of the TouchDRO community will appreciate the input also.


----------



## dlhoulton

Would also like to thank you for your work on this. I have the Absolute DRO setup on my lathe and would like to have the ability to have a large wired display added for better visibility. I bet once this is solved there will be a large population of "Absolute" users very excited. Thanks again for the work your doing!!


----------



## middle.road

Question JP: does it interface with a device via bluetooth only or can it do hard wire and wireless also?
(I suppose I had better start reading up on this...)


----------



## JPigg55

It can be wired and/or wireless. However, it is designed to work with the Touch DRO App which is usually associated with Tablets and smart phones (not sure about Window 8 or 10. I've heard those computer operating systems interface/run App's, but not sure).
The App only works on Android devices currently (sorry iPhone &  iPab users).
I personally would advise on going the wireless route. Less wire means less chance of EMI from shop motors and lighting. I think it will be more flexible as well, especially for use on multiple machines.
I did find out today there's an issue with the schematic on Yuriy's Touch DRO site (http://www.yuriystoys.com/p/android-dro.html) for the wireless Arduino version.
Arduino sends out a 5V signal on its TX pin, and the HC-06 Bluetooth module can’t have more than 3.3 – 3.6 Volts coming into it on the RX pin, so you need to put a voltage divider on that line to step the data signal voltage down. This isn't shown on the schematic or discussed on the site beyond telling you to refer to your specific Bluetooth module specs.
The schematic also shows the 5V supply going to the Bluetooth module. While it may work, it's better to supply it from the 3.3V pin or it may fry your module.
Right now, the issue seems to be the way the Bluetooth module is sending data to the App that's currently not working for me. May be the voltage issue.
I'll try re-wiring my controller tonight and test again. If not, my buddy Brian is sure he can fix the isse once I get my controller and a scale to him to play with.
Once it's tested SAT, I'll post the sketch and try to post an fixed schematic for the build.


----------



## middle.road

Pheeeew. I'm running HP Touchpads here. I received one as a gift after the fire sale back in '12 and I've become rather 
enamored with them and they are the only tablet I like to dink around with, and I've had quite a number of others
pass through my hands the last few years. I think I've got six or so floating around here currently.
The developers are still pumping out Android on these and they're up to date with Lollipop. 
One slight drawback is that the BT is not functional or at best 'flaky'. 
Since one of these I what I'm planning on using, I was a bit worried there for a minute.

Thank you for the very informative reply, 'tis appreciated.


----------



## JPigg55

From Touch DRO site for minimum requirements:

*System Requirements*

Android OS 4.0 or newer
4" multi-touch screen with 800x480 resolution*
BlueTooth or USB support
 * Altough the application will work on a 4", or even smaller, screen, a tablet with at least 7” 1024x600 screen is highly recommended.


----------



## middle.road

Got that covered. The Touchpads are 10" and resolution is 1024x768. Should make for a decent interface.
I've got several flavors of KitKat (v4.4.4) and Lollipop (v5.1.1) running on them.
I've seen picts of it running on a ~4" smartphone, but I don't believe that I would care for that. - Fat Thumb Syndrome -


----------



## dlhoulton

Is this at a phase where one could start ordering parts for the build? If so, is this just for the "Arduino Basic DRO Controller? Going the Bluetooth route is not a problem and from what info is on Yuriy's site this is the simplest to build.


----------



## JPigg55

I wouldn't order just yet.
Right now not sure if issue lies with controller trying to send a 52 bit number to the App or the App itself.
If it's the controller, should be able to fix it in the next few days, but may require using a different Arduino board. Might take using the Arduino Due instead of the Uno.
If it's the App, we might be at an impass unless we can get Yuriy to modify the App to accept a 52 bit number. Not sure if he'd be willing or able to  or if it's even possible. I'm not up on the whole App building thing by a long shot.
For those like me who have already built controllers, I'm attaching a modified version of the schematic showing the req'd changes. You'll have to excuse the art work. I'm no artist and don't have a good drawing program (used Microsoft Paint).
The changes are:
- 3v power to Bluetooth module instead of 5v.
- Voltage divider pn TX to RX (Arduino to BT). I used 10 ohm and 20 ohm resistors to drop the 5v signal from the Arduino to 3.3v. Any resistors should work as long as one as one is about double the other. Voltage needs to be 3.3v to 3.6v.
- I didn't change the schematic, but the capacitors on the power leads (Vcc) to the scales aren't necessary. Provides some filtering and can be used, but not necessary.


----------



## JPigg55

BTW  Middle.Road,
For USB wired connection, connect USB to the Arduino board RX & TX connections as if using a BT module. I think it would be TX to D- and RX to D+.
Shouldn't have to connect the VCC or Gnd wires and probably good idea not to since your tablet might try drawing power from the Arduino. Result probably would't be good.
Voltage divider on TX connection might not be required either since not using BT module. I'll check on that.


----------



## JPigg55

Well, little bad news, seems the Absolute scales have a clock in the scales unlike other 21 bit scales where clock resides in the display.
As a result, the controller will have to be modified.

Here's part of a couple Emails my friend Brian sent me today:
"I just needed to lift the cover again, just like changing out the cord. It does have a crystal. Feeds back on the clock signal. looks like a way to start the data collection process. I've got a setup breadboarded together that works, I just need to figure out how to sync up data acquisition with the read head clock."
"Yuriy replied to an Email I sent to him, and he had a great suggestion. This version is going to end up being interrupt driven by the read head. I am not going to use a clock signal at all. I will use a timer so I know when it's time to shift bits, but no clock to run the show. The only voltage divider needed is going to be for the BT module (the Arduino has onboard 3.3V to power the scales)."

In short, not resolved yet, but slowly getting closer. Will keep updates coming.


----------



## kingmt01

JPigg55 said:


> I did find out today there's an issue with the schematic on Yuriy's Touch DRO site (http://www.yuriystoys.com/p/android-dro.html) for the wireless Arduino version.
> Arduino sends out a 5V signal on its TX pin, and the HC-06 Bluetooth module can’t have more than 3.3 – 3.6 Volts coming into it on the RX pin, so you need to put a voltage divider on that line to step the data signal voltage down. This isn't shown on the schematic or discussed on the site beyond telling you to refer to your specific Bluetooth module specs.
> The schematic also shows the 5V supply going to the Bluetooth module. While it may work, it's better to supply it from the 3.3V pin or it may fry your module.
> Right now, the issue seems to be the way the Bluetooth module is sending data to the App that's currently not working for me. May be the voltage issue.


HC-06 does use 3.3V but most of the break out boards for it is set up with ability to use 3.3v or 5v. I power mine from the Launchpad with 3.3v.


----------



## ycroosh

JPigg55 said:


> Well, little bad news, seems the Absolute scales have a clock in the scales unlike other 21 bit scales where clock resides in the display.
> As a result, the controller will have to be modified.
> 
> Here's part of a couple Emails my friend Brian sent me today:
> "I just needed to lift the cover again, just like changing out the cord. It does have a crystal. Feeds back on the clock signal. looks like a way to start the data collection process. I've got a setup breadboarded together that works, I just need to figure out how to sync up data acquisition with the read head clock."
> "Yuriy replied to an Email I sent to him, and he had a great suggestion. This version is going to end up being interrupt driven by the read head. I am not going to use a clock signal at all. I will use a timer so I know when it's time to shift bits, but no clock to run the show. The only voltage divider needed is going to be for the BT module (the Arduino has onboard 3.3V to power the scales)."
> 
> In short, not resolved yet, but slowly getting closer. Will keep updates coming.



JPigg55,
I'm pretty sure Arduino can handle these scales, but the implementation will need to be very "slim" (highly optimized). I've spent a lot of time optimizing the code for MSP430, which has a leg-up on ATmega328 with 16 bit architecture. There are a few gotchas: data stream speed is much faster at 250 HZ refresh rate (which can be tempered by pulling the "Req" line high when the controller is not ready), 2 KHz clock speed, the need to deal with 64 bit integers, and the format conversion (BCD to 32 bit integers) that requires 6 multiplications per reading (not a trivial task for Arduino). 
I can give Brian a few pointers as to how I did that for MSP430, and hopefully he will be able to figure out the rest. Let me know if I van help you with the hardware too.

Regards
Yuriy


----------



## JPigg55

kingmt01 said:


> HC-06 does use 3.3V but most of the break out boards for it is set up with ability to use 3.3v or 5v. I power mine from the Launchpad with 3.3v.


You are correct, issue id that the Arduino board TX pin ouputs 5 volts regardless of supply voltage. That's why a voltage divider is necessary on the TX to BT module.


----------



## JPigg55

ycroosh said:


> JPigg55,
> I'm pretty sure Arduino can handle these scales, but the implementation will need to be very "slim" (highly optimized). I've spent a lot of time optimizing the code for MSP430, which has a leg-up on ATmega328 with 16 bit architecture. There are a few gotchas: data stream speed is much faster at 250 HZ refresh rate (which can be tempered by pulling the "Req" line high when the controller is not ready), 2 KHz clock speed, the need to deal with 64 bit integers, and the format conversion (BCD to 32 bit integers) that requires 6 multiplications per reading (not a trivial task for Arduino).
> I can give Brian a few pointers as to how I did that for MSP430, and hopefully he will be able to figure out the rest. Let me know if I van help you with the hardware too.
> Regards
> Yuriy


 
Yuriy, didn't know you were on this forum.
I know Brian has been in contact with you already. I know he's been working on making the Absolute scales work with the Launchpad format in parallel with the Arduino, May be done, but I'll pass on the message and you two can compare notes.
He emailed me today and said he thought he'd have a working mock-up by this evening for the Arduino. He has only the one scale that I lent him and was concerned about being able to sync all the clock speeds for mutiple scales with the clock speed residing on the scales themselves via an oscillator instead of the display providing it.
From his email yesterday:

"I was looking thru the code for the interrupt library I found, and I do think it'll work. I'm working on programming the on board timer now, I want to read a bit every .5ms once it gets triggered. A 2kHz frequency means that the read head will send a new bit every .5 msec (or .0005 sec).
Here's How it's Going to Work:
A change in state from the read head data line means the read head has started sending data. This will fire off a pin interrupt.
The pin interrupt routine will:
A) Disable the pin interrupt - read head is sending data now, stop waiting for it
B) Fire up the timer to generate a timer interrupt every .5 ms 
The timer interrupt will:
A) Read the state of the pin. This is the data bit.
B) Bit shift into a variable. Steps A) and B) will be one line of code.
C) Increment a counter. The counter will run up to 36. This is all the bits the read head sends. Not all 52 bits are being used, and the first 4 that get sent only denote units, so they will be discarded.

After the counter hits 36, the timer is shut down and the pin interrupt is re-enabled. The data will then be sent to the app, the data variable reset to zero, and the cycle is complete.
With the 328P running at 16MHz, it will update every .625usec (or .0000000625 sec). This means the Arduino has time to execute 8000 instructions in the time it takes for the read head to send 1 data bit. We should have plenty of time to spare, and plenty of time for 4 axis and a tach.
All in all, everything should be plenty fast enough. The code is going to be compact, but it will have to be repeated for each axis.

Once I learn a little more about programming the timers I'll get to work writing a sketch to read one axis.
Since I found that interrupt library, I'm convinced the Uno will work just fine, otherwise I think we might have had to go to a Mega or Due.
Thank Goodness for an active Arduino community!!!!! "


----------



## ycroosh

JPigg55 said:


> Yuriy, didn't know you were on this forum.
> I know Brian has been in contact with you already. I know he's been working on making the Absolute scales work with the Launchpad format in parallel with the Arduino, May be done, but I'll pass on the message and you two can compare notes.
> He emailed me today and said he thought he'd have a working mock-up by this evening for the Arduino. He has only the one scale that I lent him and was concerned about being able to sync all the clock speeds for mutiple scales with the clock speed residing on the scales themselves via an oscillator instead of the display providing it.
> From his email yesterday:
> 
> "I was looking thru the code for the interrupt library I found, and I do think it'll work. I'm working on programming the on board timer now, I want to read a bit every .5ms once it gets triggered. A 2kHz frequency means that the read head will send a new bit every .5 msec (or .0005 sec).
> Here's How it's Going to Work:
> A change in state from the read head data line means the read head has started sending data. This will fire off a pin interrupt.
> The pin interrupt routine will:
> A) Disable the pin interrupt - read head is sending data now, stop waiting for it
> B) Fire up the timer to generate a timer interrupt every .5 ms
> The timer interrupt will:
> A) Read the state of the pin. This is the data bit.
> B) Bit shift into a variable. Steps A) and B) will be one line of code.
> C) Increment a counter. The counter will run up to 36. This is all the bits the read head sends. Not all 52 bits are being used, and the first 4 that get sent only denote units, so they will be discarded.
> 
> After the counter hits 36, the timer is shut down and the pin interrupt is re-enabled. The data will then be sent to the app, the data variable reset to zero, and the cycle is complete.
> With the 328P running at 16MHz, it will update every .625usec (or .0000000625 sec). This means the Arduino has time to execute 8000 instructions in the time it takes for the read head to send 1 data bit. We should have plenty of time to spare, and plenty of time for 4 axis and a tach.
> All in all, everything should be plenty fast enough. The code is going to be compact, but it will have to be repeated for each axis.
> 
> Once I learn a little more about programming the timers I'll get to work writing a sketch to read one axis.
> Since I found that interrupt library, I'm convinced the Uno will work just fine, otherwise I think we might have had to go to a Mega or Due.
> Thank Goodness for an active Arduino community!!!!! "



JPigg55,
It looks like Brian is headed in the right direction (just got an email form him with a few questions). It might not be easy to make it work reliably on Uno, but I'm pretty sure it can be done. Worst case scenario, he can punch to the raw AVR code and bypass the bloat of the libraries. I don't see the point of going to Mega or Due, though. The cost of (even off-brand) boards is pretty high, so unless there are issues with Launchpad availability, MSP430 makes more sense at that point.

Regards
Yuriy

P.S. If you didn't see my post yesterday (here: http://www.hobby-machinist.com/thre...ts-igaging-absolute-scales.40734/#post-350043) Launchpad version is already good to go (tested and ready to be released to "into the wild").


----------



## JPigg55

Thanks for the reply and help. I know Brian will figure it out. It's personnal now. LOL
He'd already mirrored what you said about Launchpad and MSP.
I originally went the Arduino route due to a previous interest in learning the system. Had ordered before I knew Absolute scales wouldn't work with your App. I'm a complete novice at electronics and programming.
This ordeal has taught me a lot, but have a long way to go.
I'll probably wait and see how Arduino works when Brian wins his battle (LOL), but may opt for the Lauchpad version depending.
Have other uses for the Arduino boards if I choose not to go that route.
Thanks again for the reply andassistance.

I did see your post about MSP and Absolute scales. Thanks again.


----------



## JPigg55

I've been slow on updates.
By now, most know Yuriy (aka YCROOSH) has gotten Absolute scales to work with the MSP430 controller.
Big stickler now is that he has the newer iGaging Absolute Plus scale which may be different from the original Absolute scales like I have.
Right now, I can't state if the older version will work with the Launchpad controller either. Brian thinks it won't.
He's still working on a fix for the Arduino controller (not sure about Launchpad yet). Apparently Yuriy has volunteered to assist and, if all goes well, we'll be sending one of the scales and display to him also.
That's all for now.
JP


----------



## JPigg55

Been a while since I last posted progress.
Not much to report. Brian Quinn contacted Scott Shumate at Shumatech. He noticed something on the O-scope trace that led Brian to think the Absolute scales have 2 read heads with an offset to cover transitions between strips. This would make the reading very stable eliminating a lot of the lower number jumping.
Problem now is figuring out how the display unit combines/interprets the 2 separate words from the read heads and outputs a single number position.
I shipped a scale and display to Yuriy as well it should be there in a day or so.
Once he has a chance to play with it, hopefully him and Brian can figure this puzzle out.


----------



## RodF

Hi JPigg55
I  have the same scales as you (non Plus version). Have just ordered the MSP430 boards also have plenty of Nano boards. Am hoping this will work out.  BTW I cut the USB plugs off and I have two different colour combinations black red brown white green and black red blue yellow green.
Rod


----------



## ycroosh

JPigg55 said:


> Been a while since I last posted progress.
> Not much to report. Brian Quinn contacted Scott Shumate at Shumatech. He noticed something on the O-scope trace that led Brian to think the Absolute scales have 2 read heads with an offset to cover transitions between strips. This would make the reading very stable eliminating a lot of the lower number jumping.
> Problem now is figuring out how the display unit combines/interprets the 2 separate words from the read heads and outputs a single number position.
> I shipped a scale and display to Yuriy as well it should be there in a day or so.
> Once he has a chance to play with it, hopefully him and Brian can figure this puzzle out.


JPigg55,
I got your scale today. Brian was right, this is a completely different animal. Even the pin functions are different. Unlike the "Plus" version, Vcc, Ground, Data and Clock pins actually make sense. Now I have to figure out what kind of ptorocol it is.
I will post details once I figure something out.
Thank you
Yuriy


----------



## JPigg55

Quick update.
Not a lot of progress yet. Brian is currently setting up to do a full scale mapping run using steppers from an old all-in-one scanner/printer he had running at 5/10,000th steps.
As I understand it, once he has the data from a full mapping run, the next step will be to determine scale segment size.
Once this data is acquired, I think it will be just a matter of matching up the scale output data to the indicated reading on the display unit in an effort to determine the algorithm the display uses to convert the scale data to a digital position indication.
Once determined, it should be just a matter of writing the sketch for the Arduino & Launchpad and coming up with a schematic for the controller build.


----------



## kingmt01

My hats off to Brian & all the other reverse engineering people that take the time to improve upon devices. I have no use for these scales ATM but it still interest me to fallow.


----------



## JPigg55

Hey all following this thread, I think Brian finally has this almost licked. As it turns out, the iGaging Absolute scale use a 3 track magnetic strip encoded for the Absolute position.
Our work schedule has made progress slow going, but appears he may have a working algorithm soon.
We believe the math of the scales has been figured out and it's just a matter of finding the constants for error correction, then writing the sketch, and building the controller.
For anyone with any suggestions, here's the information he sent me:

*With the cyclic counts we've got, I figured out the basic equation:


F: XXXXXXXXX

M: +YYYYYYYY00000

C: +ZZZZZZZZ000000000

 zzzzAAAABBBBXXXXX


Where X is the fine track read, Y is the medium track read, and Z is the coarse track read, B is the sum of X and Y, A is the sum of X, Y, and Z, and z is the carry of all the math.

The trailing zeroes show the shift (that's multiplication by a power of 2) that is needed to account for the number of fine tracks for the medium and coarse tracks.

The final result is the sum of all 3 numbers. Notice how the last 5 bits are all fine track.

Funny thing is, that gives us a 17 bit number, or 2^17, or 131072. I was doing calcs before on the mm scale run and came up with a largest possible value of 1310.72 mm, or 51.6".


That number will be unique and sequential for the entire run.

Pretty much the only thing left now is to find the constants for error correction. Since there are only 16 possible Medium values for every Fine, and 16 possible Coarse values for every Medium, that should make the calc fairly simple.

We could do this without error correction, but any noise on the medium and coarse tracks would be HUGELY amplified, giving a rather large and unacceptable jump every so often in the readings. There does seem to be quite a bit of noise in the coarse track.


Looks like my mission here is finally winding down. May take a while longer to get it all cleaned up, but I see a light at the end of the tunnel.*

This will have the advantage of not needing any type of battery back-up to maintain scale position or lose position on power loss. One issue will be the position update rate. The scales transmit on a 10 Hz frequency making the read-out a bit laggy when moving fast. Once the constants are found for error correction, the code should make the output stable like the OEM display are with no jumping around, but if used with fast feed rates, will require stopping or slowing down to come in to final position without overshoot.

I have a copy of the Excel spreadsheet with all the scale data for anyone wanting a copy, just shoot me a PM.


----------



## RodF

Good news. Waiting patiently.
Rod


----------



## djb25

Any updates on this? I've had a set of "non-plus" absolute DROs on my mill for two years, and I'm waiting patiently to add touchdro.


----------



## RodF

Me too. I have cut the USB connectors off the scale leads in anticipation of connecting them to the board (that I built).  However I think I will have to reattach them and live with the original readouts.


----------



## JPigg55

Sorry, not yet. Brian has been working on a new sketch for another scale data run for better data hopefully without the noise, but work schedule has been crazy as of late being short handed.
We thought we had it nailed down, but the scale track transitions are tossing a wrench in the works with one of the bits seemingly being used for something other than position, possibly a sign bit, but without cleaner data, having trouble nailing down which bit and how it's being used.
When sketch is finished, will do a slower run that will, hopefully, get rid of the skips and much of the noise. This should make it easier to find the offending bit.
The track segments seem to have a 1 mirco resolution and Brians set-up using the stepper from an old printer to run the scales. This time he's going to jumper in the display to get the scale binary number along with the corresponding display decimal output which should give us everything we need we hope.


----------



## JPigg55

Not a lot of progress, but after getting frustrated with the data, I took apart one of the read heads to see if that might give a clue.
Here's the pictures of what's inside for those interested or if anyone is familiar with this type.


----------



## RodF

Did that shed any light on the problem?


----------



## JPigg55

Yes it did.
Don't want to get my hopes up just yet, but opening it up let me verify it was a 3 track scale and ruled out Vee scan type.
Led me back to re-look at a type of system that uses 3 tracks called the Master track, Nonius track, & Incremental track for Absolute scales.
This uses an SSI protocol for a 2's Compliment type binary system. Everything seems to fit just a matter of running the numbers and see if it works.
Might be another unintended plus, if I'm correct. Using the OEM displays, I've noticed the slow (10X/sec) update rate, but also a smooth display with little or no jumping.
Given the noise of the original scale data run, I'm now wondering if the update rate is a function of the diplay and not the scales.
If I'm right, the display averages a few readings before updating the display. If so, might be able to increase the update rate reducing the lag.


----------



## JPigg55

FINALLY !!!
My friend Brian and I finally hacked the old iGaging Absolute Origin scales. It's been a long road, but managed to finally figure it out.
Brian has written a sketch for the Arduino Uno and successfully tested it with a single scale. I'm in the process of building my Touch DRO controller for testing with 3 scales at once to make sure no issues arise.
Once this is done, Brian plans on finishing the coding for the fourth input (W-axis) and also write one up for use with MSP Lauchpad as well.

As you can see from my last post, it's been a 3 year struggle to finally decode these things. So if any of you that had these scales and were following this thread, you might want to dust off those scales and start looking for parts to build your own Touch DRO controller.


----------



## JPigg55

BTW, don't start putting together a controller just yet based on the directions given on Yuriy's Touch DRO site. The coding will require specific pins to be used for each axis port.
I'm also dealing with sub-zero temperatures outside at the moment so this will delay my testing somewhat.
I'll keep everyone updated.


----------



## ycroosh

Nice work, Brian and Jimmy. I know that Brian spent countless hours reverse engineering that protocol and his new sketch is well done. Congrats, gentlemen!


----------



## JPigg55

UPDATE:
Testing will be delayed a bit.
Brian contacted me about a small issue. He works more with the TI MSP Launchpad platform instead of Arduino. The MSP uses 3.3v as the native voltage vs 5v for the Arduino on the boards. Since the scales are 3.3v, he suggested either building a voltage divider circuit or get a couple LM339 Quad Comparators.
Since it would be necessary to build a voltage divider circuit for each scale, I'm opting for the later and will have to wait until they get delivered.
Although his initial test with the single scale I loaned him worked, but we're worried about scale longevity if it's supplied with 5 volts from the Arduino pin pull up resistors.
Brian hasn't completed the code for the Tach function for the sketch yet or wrote the one for MSP platform. It's on his "To-Do" list, but his work schedule will delay both for a bit. If the testing is successful, I'll post the Arduino sketch "As is" since the Tach/"W" axis code can easily be added later.
Just as a reminder, this project requires specific pins to be used on the Arduino board which is spelled out in the sketch which is why I said not to try getting a jump start on putting the board together.


----------



## ycroosh

JImmy,
Arduino is able to detect signal from 3.3V scales without any problems, so you really don't need the comparators.  If you want to pull up the lines, make a simple voltage divider with two resistors. For example 10K from Vcc and 20K from ground. Where they meet will produce safe voltage. You can either have one of these per input pin or just fan out 20K resistors from the junction point to each input pin. Better yet, get a LM 3117-3.3 LDO voltage regulator to provide the necessary Vcc to scales and pull up the pins to that. The circuit needs 3 parts: the regulator and two capacitors.
You would need the comparators if the MCU wasn't detecting the input level. Comparator circuit would look something like this: http://www.yuriystoys.com/2013/10/voltage-shifter-circuit-for-mixed-scale.html and wouldn't do anything useful. 
Regards
Yuriy


----------



## JPigg55

I know, but according to Brian, the Arduino pins that the Clock signals are assigned to pull the signal to 5 volts. His initial test worked, but he had a concern with the electronics in the readhead handling the higher voltage over a long period.
I'm not sure if you remember, but the original  iGaging Absolute Origin scales don't have an external clock, the clock crystal resided in each of readheads and is in a normally high state and pulled low. I believe that's why each scale clock line is assigned its own pin on the Arduino. I think that's why he suggested the comparators, but I'll check into the LM3117's.
Unfortunately, I don't think Brian is on this forum as he could give a much better explanation than I can. You could email him if you'd like. I'm pretty confident with electrical, but much less so with electronics and tend to defer to his expertise.
I also have my own agenda in that it's a good excuse to start playing around with MSP Launchpad. Arduino seems to be easier platform for a beginner like me, but the MSP platform seems to be both cheaper and more flexible a platform. I think I remember Brian telling me you preferred it over Arduino as well.
Yes, I could just build a voltage divider circuit for each of the clock pins, but they do have to be 3 separate circuits in order to detect the clock cycles for each of the scales. Either way, he said the sketch would have to be tweaked depending on which way I decided to go.


----------



## BrianQ

Jimmy finally talked me into joining this forum, figured it would be best if I answered any questions directly.

Like Yuriy said, the Arduino has no problems whatsoever reading the 3.3V signal coming in from the scales. The problem is the clock line. In actuality, it isn't really a clock at all, it's the "doorbell" the read head uses to tell the display unit that a data bit is being sent. The display unit provides a 3V signal to the read head on the clock line. When the read head is sending a data bit, it pulls that voltage to ground. That signals the display unit to read the data line.
Since I wrote the sketch to have the Arduino supply this voltage, 5V is being supplied. The simplest solution is a voltage divider. I'm attaching a quick schematic of the divider. It's 2 resistors and a connection to ground. Easy stuff.
The sketch uses Arduino pins 6, 8, and A0 as the clock lines, so voltage dividers need to be placed on each of those 3 pins.

If you have any questions, ask! I'll get to them as soon as I can, but I can't promise when that will be.


----------



## ycroosh

JPigg55 said:


> I know, but according to Brian, the Arduino pins that the Clock signals are assigned to pull the signal to 5 volts. His initial test worked, but he had a concern with the electronics in the readhead handling the higher voltage over a long period.
> I'm not sure if you remember, but the original  iGaging Absolute Origin scales don't have an external clock, the clock crystal resided in each of readheads and is in a normally high state and pulled low. I believe that's why each scale clock line is assigned its own pin on the Arduino. I think that's why he suggested the comparators, but I'll check into the LM3117's.
> Unfortunately, I don't think Brian is on this forum as he could give a much better explanation than I can. You could email him if you'd like. I'm pretty confident with electrical, but much less so with electronics and tend to defer to his expertise.
> I also have my own agenda in that it's a good excuse to start playing around with MSP Launchpad. Arduino seems to be easier platform for a beginner like me, but the MSP platform seems to be both cheaper and more flexible a platform. I think I remember Brian telling me you preferred it over Arduino as well.
> Yes, I could just build a voltage divider circuit for each of the clock pins, but they do have to be 3 separate circuits in order to detect the clock cycles for each of the scales. Either way, he said the sketch would have to be tweaked depending on which way I decided to go.




I see... I haven't had a chance to look at his sketch yet (have been busy banging by head agains the wall working on the firmware update for the new Shahe scales).
This is more complicated than it needs to be. I would do the following:
1. Disable pull up resistors in the chip. I.e. leave the pins floating; if needed you can hard-wire unused pins to the round to avoid noise.
2. Add a +3V power supply (you will need this to power the scales). My choice would be the LM1117-3.3, but since the scales draw very little current, a voltage divider with 2K/3K resistors should work.
3. Pull up the lines to the scales Vcc using 20K (or even better, 47K) resistors

This will give you cleaner (more square) pulses. I don't have this scale, but the newer Absolute DRO+ you have to read on the raising edge and the data line goes up right before the clock line and raises very sharply. Comparator with built-in pull-up resistor slows down the raise time, possibly to the point where the data line might not go over the threshold fast enough.
If you *really* want to have an IC between the scales and the inputs, use a non-inverting buffer of some sorts. Those are purpose-built for this sort of thing and 3.3V to 5V ICs are very common.

If you go the comparator route you still have to power the scale and provide "virtual grounds" to the comparators, so you won't be saving any parts. Basically you will be building the circuit I linked in my previous post, except in your case you don't really need it.

As far as MSP430 vs. Arduino, I prefer MSP430 over Arduino because of the tooling. I use Code Composer studio with a proper FET, so I can do debug the code, halt the chip and inspect the registers, look at the memory, etc. MSP430 has more modern perhiperals as well, but the tradeoff is a HUGE learning curve. Unless you really want to invest a LOT of time into learning embedded programming in pretty low-level C, Arduino isn't such a bad option.

Hope this helps
Yuriy


BrianQ said:


> Jimmy finally talked me into joining this forum, figured it would be best if I answered any questions directly.
> 
> Like Yuriy said, the Arduino has no problems whatsoever reading the 3.3V signal coming in from the scales. The problem is the clock line. In actuality, it isn't really a clock at all, it's the "doorbell" the read head uses to tell the display unit that a data bit is being sent. The display unit provides a 3V signal to the read head on the clock line. When the read head is sending a data bit, it pulls that voltage to ground. That signals the display unit to read the data line.
> Since I wrote the sketch to have the Arduino supply this voltage, 5V is being supplied. The simplest solution is a voltage divider. I'm attaching a quick schematic of the divider. It's 2 resistors and a connection to ground. Easy stuff.
> The sketch uses Arduino pins 6, 8, and A0 as the clock lines, so voltage dividers need to be placed on each of those 3 pins.
> 
> If you have any questions, ask! I'll get to them as soon as I can, but I can't promise when that will be.
> 
> 
> 
> 
> 
> 
> 
> 
> 
> View attachment 286226


Hey Brian,
Good to see you here.
this makes sense. The "doorbell" line seems similar to the "Req" line use by Mitutoyo SPC scales, which is used by the host to request reading from the scale. On the newer absolute scales this line can be just pulled to the ground and the scale will send the position at about 50Hz. 
Regards
Yuriy


----------



## BrianQ

ycroosh said:


> I see... I haven't had a chance to look at his sketch yet (have been busy banging by head agains the wall working on the firmware update for the new Shahe scales).
> This is more complicated than it needs to be. I would do the following:
> 1. Disable pull up resistors in the chip. I.e. leave the pins floating; if needed you can hard-wire unused pins to the round to avoid noise.
> 2. Add a +3V power supply (you will need this to power the scales). My choice would be the LM1117-3.3, but since the scales draw very little current, a voltage divider with 2K/3K resistors should work.
> 3. Pull up the lines to the scales Vcc using 20K (or even better, 47K) resistors
> 
> This will give you cleaner (more square) pulses. I don't have this scale, but the newer Absolute DRO+ you have to read on the raising edge and the data line goes up right before the clock line and raises very sharply. Comparator with built-in pull-up resistor slows down the raise time, possibly to the point where the data line might not go over the threshold fast enough.
> If you *really* want to have an IC between the scales and the inputs, use a non-inverting buffer of some sorts. Those are purpose-built for this sort of thing and 3.3V to 5V ICs are very common.
> 
> If you go the comparator route you still have to power the scale and provide "virtual grounds" to the comparators, so you won't be saving any parts. Basically you will be building the circuit I linked in my previous post, except in your case you don't really need it.
> 
> As far as MSP430 vs. Arduino, I prefer MSP430 over Arduino because of the tooling. I use Code Composer studio with a proper FET, so I can do debug the code, halt the chip and inspect the registers, look at the memory, etc. MSP430 has more modern perhiperals as well, but the tradeoff is a HUGE learning curve. Unless you really want to invest a LOT of time into learning embedded programming in pretty low-level C, Arduino isn't such a bad option.
> 
> Hope this helps
> Yuriy
> 
> Hey Brian,
> Good to see you here.
> this makes sense. The "doorbell" line seems similar to the "Req" line use by Mitutoyo SPC scales, which is used by the host to request reading from the scale. On the newer absolute scales this line can be just pulled to the ground and the scale will send the position at about 50Hz.
> Regards
> Yuriy



Hi Yuriy, good to see you're active here!
That line really is a Request line, only in reverse. I guess a more apt name would be Request-To-Read. On these particular scales, the read head is not exactly slaved to the display unit, more of a peer-to-peer type of arrangement. The read head has it's own on-board oscillator, so I have to assume the read head processor is not assumed to be synchronized with the display unit processor.

Anyway, I think Jimmy is building a proto-shield using the voltage dividers, so we should be able to find out in fairly short order if there are any issues with 3 scales connected at the same time.


----------



## BrianQ

Oh, for those of you that use the MSP430 platform (my personal preference).
No external voltage dividers will be required.
The code is easily converted over to the MSP platform, just takes a few tweaks. Once we get any issues ironed out, I'll port it over to that platform, but I can't say when. Best guess would be April or May (soonest).

As for these scales in general, I am not a fan. They only update about every .1 secs. You can travel a long way, even manually, in .1 secs.

I hope that everyone that has these scales and wants an actual DRO finds this useful!


----------



## JPigg55

Quick test update.
First attempt at the 3 scale test was a bust. I couldn't keep the Bluetooth module connected.
A little Googling later and it seems that this is a prevalent issue with the newer BT modules, not sure why.
Let me know if anyone has any insight to this issue.
Anyway, I'm starting a new design to try to alleviate this problem. I'm also planning for a USB corded option between the controller and tablet if problem persists.


----------



## BrianQ

We're not getting carried away just yet.
The algorithm to decode the absolute position has been solved, so this is now in Alpha testing phase.

We are working on the external circuitry required to make this all work, and we'll keep you updated as things progress.


----------



## ycroosh

JPigg55 said:


> Quick test update.
> First attempt at the 3 scale test was a bust. I couldn't keep the Bluetooth module connected.
> A little Googling later and it seems that this is a prevalent issue with the newer BT modules, not sure why.
> Let me know if anyone has any insight to this issue.
> Anyway, I'm starting a new design to try to alleviate this problem. I'm also planning for a USB corded option between the controller and tablet if problem persists.



Jimmy,
Are you sure this is a problem with a BT module? TouchDRO has a "feature" that will drop the connection if the parser doesn't get a valid data stream for more than 5 seconds. This is not a bug or a problem with the BT module. In my experience the HC-0x BT modules are pretty close to pullet proof. I've sold hundreds of boards and literally one person had a dud module, and I had probably 6 or 7 fail the initial test. The protocol itself is very resilient to noise, collisions, etc.
I will remove USB option from the app in a couple of releases. USB us actually exactly opposite - nothing but trouble. Android USB drivers for Arduino are implemented at a lower level than BT, so when USB craps out cant freeze the whole OS, requiring a restart. 
I can't find a set of these scales, so can't test Brian's sketch directly, but my guess would be that with three scales something goes cross-wired and the chip isn't sending proper position data. Try using a basic BT terminal to see the data stream. You might be able to see something to point you in the right direction.

Also, to give Brian the credit he deserves: firmware development is insanely difficult precisely because you have to deal with all sorts of non-obvious issues. Arduino makes writing code easy by providing some abstraction, but reading three asyncronous scales, processing their data, sending it over UARD and doing that with bytes of ram and 16MHz ALU is still very non-trivial. For instance, I spent 4 weeks worth of nights and weekends on the update to my existing firmware to add support for the new Shahe scales. Two weeks of that went into finding a glitch caused by the MCU running out of memory and corrupting the configuration flags, and the tooling I have is miles ahead of what Arduino offers.

Hope this makes sense.
Yuriy


----------



## BrianQ

Thanks Yuriy!

Makes it even harder when I only have one scale to work with


----------



## JPigg55

Yuriy, I can't rule it out. It paired just fine with my tablet, but wouldn't stay connected to the App.  A few times it would connect to the App for a few seconds and then disconnect. Most of the time it would connect and then immediately disconnect (<1 second). 
I realized all too late that I'd used way to small of  resistors in the voltage dividers. I also did a poor job of power management. I should have used the 3.3v Arduino pin to supply the scale Vcc lines instead of an additional 3 voltage dividers putting even more load on it. I plan to do that with Rev 1 of my Proto-shield.
The reason I'm thinking it may be the BT module power issue was during my initial troubleshooting of the problem, I ran into a bunch of posted issues with the newer HC-05's having disconnect issues that were mostly blamed on power supply problems. I can't confirm that it was indeed a power issue or not.
My USB statement wasn't intended as a solution. As I was going through all the settings during troubleshooting on my tablet and the App, it was then I first noticed the selectable USB option that had been added. I wasn't aware of all the potential problems with using it at the time and figured I try it as a last resort if I couldn't get the BT to stay connected. I reasoned if it worked with the USB corded option, it had to be something to do with the BT module.
I'm not sure if Brian mentioned it here or not, be he did have a successful run of his sketch using a single scale I loaned him and got good data to the serial monitor. My part now is to test it with 3 scales and see if it will mesh with the Touch DRO App.


----------



## ycroosh

BrianQ said:


> Thanks Yuriy!
> 
> Makes it even harder when I only have one scale to work with


I'm surprised how rare these are. I even asked iGaiging directly if they had any for sale...


JPigg55 said:


> Yuriy, I can't rule it out. It paired just fine with my tablet, but wouldn't stay connected to the App.  A few times it would connect to the App for a few seconds and then disconnect. Most of the time it would connect and then immediately disconnect (<1 second).
> I realized all too late that I'd used way to small of  resistors in the voltage dividers. I also did a poor job of power management. I should have used the 3.3v Arduino pin to supply the scale Vcc lines instead of an additional 3 voltage dividers putting even more load on it. I plan to do that with Rev 1 of my Proto-shield.
> The reason I'm thinking it may be the BT module power issue was during my initial troubleshooting of the problem, I ran into a bunch of posted issues with the newer HC-05's having disconnect issues that were mostly blamed on power supply problems. I can't confirm that it was indeed a power issue or not.
> My USB statement wasn't intended as a solution. As I was going through all the settings during troubleshooting on my tablet and the App, it was then I first noticed the selectable USB option that had been added. I wasn't aware of all the potential problems with using it at the time and figured I try it as a last resort if I couldn't get the BT to stay connected. I reasoned if it worked with the USB corded option, it had to be something to do with the BT module.
> I'm not sure if Brian mentioned it here or not, be he did have a successful run of his sketch using a single scale I loaned him and got good data to the serial monitor. My part now is to test it with 3 scales and see if it will mesh with the Touch DRO App.



You might be running into a BlueTooth stack bug on the tablet side. There is a slight difference in BT implementation in different Android versions. What happens is that when the app detaches from the RFCOMM socket, the underlying driver should drop the connection. On some tablets this doesn't happen, and I didn't handle it in TouchDRO correctly. This happens only if TouchDRO drops the connection due to "no data" condition; when you click Disconnect button the app does the right thing. The symptom is that after "no data" disconnect happens, the app will connect briefly and disconnect right away. In this case you might need to do two things: force-stop TouchDRO app (from the Apps settings page). This works in 99% of the cases. On Android 4.2.x you might need to disable/enable BlueTooth. I fixed this in the new version, but it's still too buggy, so I can't give it to you yet.
Please let me know if this helps. If not, this page might be helpful:  Troubleshooting Common DRO Connection Problems. 
Regards
Yuriy


----------



## JPigg55

Thanks, I will.
Not sure if it would be worth the money for you, but the iGaging Store (Anytime Tools) still lists them. They still have listings on Amazon for them as well. All other listings I found were all over-seas.
https://www.igagingstore.com/category-s/1831.htm

https://www.amazon.com/iGaging-Abso...46552&sr=8-7&keywords=igaging+absolute+origin

https://www.amazon.com/iGaging-Abso...6664&sr=8-32&keywords=igaging+absolute+origin


----------



## ycroosh

These are the Plus version. I contacted Anytime Tools several times and they confirmed that the photo is old, but the scales are new.


----------



## BrianQ

Yuriy, what is the time delay before the "no data" condition is set? I may need to use one of the timers to send data. I only send data now when one of the positions is updated, and that may be way to slow for the app. These scales only update at a 10Hz rate.


----------



## ycroosh

Brian,
The app will disconnect if it doesn't _parse_ a valid data stream for 5 seconds, so 10Hz is more than enough.
I looked over your sketch (finally). Sorry it took so long - I was neck deep in fixing my own firmware problems for almost a month.
Now, I have a wild idea: what is the chance that Jimmy's UART-to-BT transceiver is set up to work at 115200 BAUD. If it's not and Arduino tries to send the data at that rate, the app will be getting garbage.
I'll send you some feedback in the email too. There are a few things that can be optimized.
Regards
Yuriy


----------



## BrianQ

Oh we went thru that exercise already. I ended up writing him an Arduino sketch to program it. I'll have him check it again, but that should be good.

And thanks in advance for the feedback!

Edit: Jimmy just finished soldering up a new proto-shield, so testing should continue in the morning. The first order of business will be to open a serial monitor on the tablet and ensure it's getting a good data stream.


----------



## JPigg55

Test #2 went well today with the exception that I couldn't get the Z-axis to work. I believe this to be a connection issue on my soldering job.
I figured out my previous issue, I'd manager to cross the Clock & Data lines on my USB boards.
I made a short video of the test. I tried uploading it here, but it didn't work. You can view it here:
Original iGaging Absolute Origin scales with Touch DRO


----------



## JPigg55

It Lives, Success !!!
I finally sorted out my electrical and soldering issues and now a 3 axes work. Here's the link to the "Test 2" video:
https://drive.google.com/file/d/1c0pbp6ImWBNh6n_-qEJ-gxZcSaTQTdey/view?usp=sharing

I still have to remount the scales, perform the calibration procedure, and hook up the O-scope for some testing which will take a day or two.
I also need to put together a supplies list of components and see about drawing up a schematic.
More to come.
JP


----------



## JPigg55

While doing some more testing, I shot a short video of my O-scope run and thought I'd post it for anyone interested.
Google is still processing it at this time, but it can be downloaded and viewed until then.
https://drive.google.com/file/d/1ZnQalwrrVqgctQe9nvLZcSM7xEuFMiDc/view?usp=sharing


----------



## JPigg55

I got the first scale re-mounted and calibrated to the App today. I decided to redo my scale mounts and make them a bit better this time around.
The resolution turned out quite a bit better than I thought it was going to be, ended up being 7735 CPI.


----------



## JPigg55

Just a quick update, I got all 3 scales remounted and performed the Touch DRO calibration procedure.
The Y & Z axes are working perfectly with a CPI value around 7742.
Having an issue with the X axis, it's coming in at a value of 1/3 that.
More to come.


----------



## JPigg55

Okay, possible kick in the teeth today.


Everything was going great until I got to the calibration procedure for Touch DRO. Two of the scales calibrated just fine, but the other was coming in at about a third of the CPI of the other two.


What I discovered was a difference in the manufacture between the scales. I need to do a new run with my O-scope and data logger to try and figure out if it's a difference in the readhead or the scale tape.


I you have multiple these scales, an easy test to see if they're all the same is plug each scale in to the same OEM display unit and run the readhead down the scale. Look for any big jumps in position and/or a change in position that isn't correct, i.e move it 3 inches and display only shows a change of 1 inch or move 3" and changes by 8" or 9".


This won't tell you which version you have, just if they are all the same type.


Pictures are of the boards inside the different scale versions.


----------



## BrianQ

As you can see from Jimmy's pictures, there are at least two versions of the old iGaging Absolute scales. The only way to tell the difference is by taking the cover off of the read head and looking at the version number silk screened onto the board. In the top picture is version 4.3, in the 3rd picture is version 3.1. Version 3.1 is the version that has been decoded.

We are currently deciding how to proceed. More to come.


----------



## JPigg55

Been awhile so I wanted to post a quick update.
Turns out the version 4.3 scales use the same data format as the 3.1 version scales just with a lower CPI count, around 2560 for v4.3 scales vs around 7640 for v3.1 scales.
The last hic-up is a jump in position at the Coarse track transition point where the binary output goes from a max value to a min value. Brian thinks it's just a matter of finding the correct Coarse & Mid track phase shift values to correct this issue.
Unfortunately, this requires a tedious trial and error method of changing the phase shift numbers and re-running the scales in order to find the correct numbers and due to tax season and other commitments, it has been slow going for me.
More to come.


----------



## BrianQ

We finally got the noise correction algorithm figured out. From the data we have managed to get, we have a decent idea of what the sign change values are for the 2 versions, v3.1 and v4.3. Basically, if you have a scale that was bought at longer than 18", it's a v4.3. If it was 18" or less when purchased, it's version 3.1. This makes a huge difference when telling the sketch how to tell if the position is positive or negative, and that's what TouchDRO needs to have.

We are currently trying to finalize the interface shield design in order to make it neat, and that also requires pin re-assignments on the Arduino. We should be able to have this done in a month or so (I'm ballparking. I really don't know how long this will take). After all these years, I'm happy to say we can finally stick a fork in this thing!


----------



## BrianQ

We finally have the real time working version that has been tested. It works with both versions of the scales, v3.1 and v4.3. This is the Arduino only version, the conversion over to the MSP (my personal favorite) hasn't happened yet. We are currently working out distribution details. If anyone has an idea for how to distribute this without using a proprietary forum vendor, please chime in!!


----------



## llamatrails

github.com ?


----------



## BrianQ

Terry offered to host a couple of pages on a site he already has up and running. I think we are going to go that route for distribution.
Still need to get build instructions and build pictures done, that's what we're trying to do now.
Pin assignments and the Arduino code have been finalized and tested, though. It's just a matter of getting the instructions made for how to build the circuit now. It's very simple, that was the main thing we were shooting for. There are some tight spaces, though. We're just trying to keep this as simple and easy as possible.


----------



## JPigg55

Now that the code for the sketch has been figured out and written and the shield construction has designed and tested, we are looking for the amount of people interested in using it. This will help us decide on the best platform for the release.

If anyone is interested, send me an email to jpigg55@gmail.com and put “iGaging Absolute” in the subject line. This will allow me to add you to the group g-mail list I’ve created for further updates and component list for constructing the shield.


----------



## JPigg55

It’s finally ready. We now have a sketch to take the data from the original iGaging AbsoluteDRO scales that will transmit it in a usable fashion to TouchDRO.

Our little team then developed controller build instructions along with the sketch code for use with Arduino and Arduino type MCU’s and constructed both a website detailing this information and a Google Groups support page.

The website is here: http://www.terrywerm.com/tdro_main.htm
Links to the Google Groups support page are on the website.
It’s been a long road, but there is now a way to use the original iGaging AbsoluteDRO scales with TouchDRO.


----------



## ycroosh

Jimmy,
I've been lurking in your group, and I'm really impressed with the quality of effort you (plural, as in "y'all") put into it. I will post a link to Terry's site when I get a breather (have been insanely busy last few weeks).
Regards
Yuriy


----------



## llamatrails

Ditto on the great write up you all have done.  Thanks for the effort !!!


----------



## BrianQ

Thanks Yuriy! I suspected you kept an eye on our progress from the extremely timely and helpful hints you gave us from time to time!

I plan on porting the code over to the MSP in the near future, but work is getting insanely busy for me right now, too, so that probably won't happen until late spring/early summer. It should be a fairly straight forward job, and actually connecting the scales is a piece of cake.

Keep lurking in our little group, I'll put info in there as I get a chance to work on the MSP version!


----------



## middle.road

Sweet effort!


JPigg55 said:


> It’s finally ready. We now have a sketch to take the data from the original iGaging AbsoluteDRO scales that will transmit it in a usable fashion to TouchDRO.
> 
> Our little team then developed controller build instructions along with the sketch code for use with Arduino and Arduino type MCU’s and constructed both a website detailing this information and a Google Groups support page.
> 
> The website is here: http://www.terrywerm.com/tdro_main.htm
> Links to the Google Groups support page are on the website.
> It’s been a long road, but there is now a way to use the original iGaging AbsoluteDRO scales with TouchDRO.


----------

