Arduino Wireless Digital Readout (DRO)

Sunday, September 23, 2012
Digital Readout (DRO) Screenshot
Application screenshot taken from Nexus 7

Recently I started working on a new version of my DIY digital readout project to that uses an Arduino DRO controller and an Android tablet. The DRO I'm building for my milling machine uses three inexpensive iGaging scales. (The whole set for my Hardbor Freight Mini Mill set me back less than $100 on amazon, in fact.) Since the bulk of the functionality is handled in the digital readout application, the controller design becomes much simpler, requiring only a few extra components. The parts list

In reality I've been toying with the software-based design for some time, and even wrote a basic desktop application on my computer. I scraped the idea of Windows application because without a touch screen the unit would be too cumbersome. When my Nexus 7 arrived in late July, it only made sense to use it for the DRO display unit. I've done some Android programming before, so it didn't take too long to get a basic app up and running. The app in the screenshot is a crude proof of concept, but I should be able to post a working version in a week or two.
As I mentioned before, my unit uses three iGaging scales and a controller based on Arduino UNO board to read them, as shown in the schematic below.

As you can see from the schematic, the design is very simple and doesn't require too much assembly. If you are using the original cables that came with the iGaging scales, the connections are:
  • Arduino's 3V3 pin connected to the red wire  (X-Z1 on the schematic)
  • Arduino's GND pin connceted to the black wire  (X-Z4 on the schematic)
  • Arduino's digital pin 2 connected to the white wire through the voltage divider (X-Z2 on the schematic)
  • Arduino digital pins 3,4,5 connected to green wire on scales respectively (Z-X3 on the schematic)

The four wires on the left of the schematic need to be connected to the BlueTooth module. The actual modules vary, so you will need to refer to your board's documentation to identify the right pints.

Please note: if you are using BlueSMiRF board, please make sure that RTS and CTS pins are connected to each other.

Bill of Materials

Arduino Uno 1
Bluetooth module 1
R1-R3 Resistor, 10K 3
R4 Resistor, 330 Ohm 1
R5 Resistor, 220 Ohm 1
C1-C3 Capacitor, ceramic, 0.1uF 3

Arduino

Arduino, obviously, provides the “brains” for the controller. I used Uno, but in practice any Arduino board will work here. To keep the cost low, you can even build one from scratch for less than $10 as described in my “Arduino on a Breadboard” post. (I recommend that you actually solder the board together, though, as opposed to using it on a breadboard). The only thing you need to keep in mind that the scales require 3V supply. If the board you choose doesn't come with 3.3V regulator, you will need to find a way to provide 3V to the scales.

Bluetooth Module

HC-05 Bluetooth Module for Arduino Digital Readout DRO
HC-06 (left) and BlueSMiRF (right)
Bluetooth Modules

Creating wired connections to Android tablets is fairly complicated. Fortunately, many tablets come with built-in Bluetooth controller, so all we need to do is connect the serial output from Arduino's UART controller to a serial Bluetooth modem. There are two readily available choices: Sparkfun's BlueSMiRF board or a so-called “Linvor” modem sold on eBay under various names. BlueSMiRF is an excellent board with a lot of advanced features and ridiculously long range. The downside is the $65 price tag. “Linvor” boards can be had on eBay for around $10 shipped. While they aren't comparable to BlueSMiRF when it comes to range or features, they are plenty good for our application. Simply search eBay for “Arduino Bluetooth Module”.

Please note: The HC-05 "Linvor" modules come in several flavors, but for the purposes of our project they are interchangeable, as long as the module is mounted on a breakout PCB.

Other Parts

The exact resistor values are not critical, and can be substituted as follows:

  • R1-R3 can be any resistor between roughly 10K and 47K.
  • R4 and R5 can be replaced with other 100 Ohm to 1K resitors, as long as the ratio is close to 2/3.
  • C1-C3 are bypass capacitors. They are optional but I found that they reduce the line noise

Firmware (Sketch)

The firmware (Arduino sketch) is almost identical to the one described in the earlier post "Reading Gtizzly iGaging Digital Scales with Arduino". The only two notable changes are a much slower clocl rate and a different message structure. In short, the microcontroller decodes the output from the iGaging scales and stores the positions for each of the tree scales into a signed 32 bit integer. When the last bit is read, the positions are converted to strings in the following format:

  • Single letter axis name
  • Optional minus sign
  • One to eight digits
  • Terminator (semicolon)

Once the strings are constructed, they are simply written to the UART port (using printf() function) and the process is repeated again.
The readout could look like this (without the quotes): "x-232;y4435;z124434;x-234;" and so on. Each block can be expressed using regular expression [xyz]-?\d{1,8};.

The latest Arduino sketch is posted on the DRO Project Downloads page and can be uploaded to the board using the Arduino software.

Conclusion

As you can see, this is a simple and inexpensive design that can be built in less than an hour. Most parts are available from Radio Shack (with the exception of the Bluetooth module). With some careful shopping the total cost can be as low as $25. Alternatively, by using an Arduino Bluetooth shield the amount of assembly can be reduced to soldering five resistors, three capacitors and a handful of wires. In the next part we will take a look the communication protocol and message format.

74 comments :

  1. Might want to check your schematic. Looks like your X and Z axis labels are switched.

    ReplyDelete
  2. Thank you for all your work on this. I am very much looking forward to the part where you being to talk about how you communicated with the Android, that is the most interesting part to me!

    ReplyDelete
  3. Yuriy,

    Great work. This is very interesting stuff. I use iGaging scales on my mill and they've added greatly to it's functionality. However, the auto-turn off is annoying and also when I turn the mill motor off they often lose position.
    I've got an old Galaxy S phone that I'd be trying to use when you realise the app.

    With the bluetooth module from ebay: Does it matter if they are Master or Slave?
    Is an arduino nano the minimum needed for the project?
    I'm not great at electronics, when you publish some more info can you please specify whether the resistors need be above a certain wattage (I'm guessing 0.125W would be plenty?)

    Thanks.

    ReplyDelete
    Replies
    1. Pippin,
      You need a "slave" unit. There is a model that can be used as either, but to be safe I'd go with "slave".
      Any Arduino will do. You might even make one (look at my post "Arduino on a breadboard"). 1/8th watt resistors should be more than enough.

      Regards
      Yuriy

      Delete
    2. pippin,

      I also have the iGaging scales and had the same issue with losing the position upon turning the motor off. I discovered that the back EMF from the coils in the motor were causing spikes in the unshielded wires from the DRO to the displays. I mounted the readouts in front of the motor and I had the DRO wires wrapped around the cable conduit between the controller and motor. Once I moved the wires away fronm the motor wires, the problem went away and I never lose position any more.

      Regards,
      Steve

      Delete
    3. Grizly has the AccuRemote that is almost identical to the iGaging. It is aliitle more expencive, but, does not auto-turn off.

      Delete
    4. I have a question. I have a tablet with Android 4 OS, with bluetooth. When I try to download your app from Google Play, it will not allow a download. I have an older Android phone, which causes a message saying "my device is not compatible".
      Is there a work around for this?
      Thanks,

      Johnny

      Delete
    5. Johnny,
      Yes,there are a few workarounds:
      The tablet should be new enough, so you might be able to grab the "APK" file from the "Dowlonads" section and install it that way. (Google "manually install apk" if you need instruction how. There is plenty of info...)
      The phone might be running OS version older than 3.0. There is a good chance there is a Cyanogenmod ROM that will work on it, but that is a bit more involved process.
      With that said, can you provide more info on your tablet and where you are located (country)? I don't have any restrictions set on the market, so it's a bit strange that the app won't download...

      Thank you
      Yuriy

      Delete
    6. Were can I purchase the dro controller box allready put together? Sincerely, Mike in Lincoln, Nebraska

      Delete
    7. Mike,
      I don't sell a ready-made box, but I have a few boards left (that don't require any soldering). It's the board seen in this video: https://www.youtube.com/watch?v=Z0597EkTjZU (minus the box and the scales). If you're interested, please let me know (the board will probably be gone before the end of the week and the next batch will be ready in a month or so)

      Delete
  4. Beautiful LED display!. You can share Android source code?

    ReplyDelete
  5. Hello Yuriy. You say "The readout could look like this (without the quotes): "x-232;y4435;z124434;x-234;" and so on. Each block can be expressed using regular expression [xyz]-?\d{1,8};.". First i want you to know that i use arduino's "official" programm. Then i open the ArduinoDRO.ino file and i press verify and upload to arduino. So, when i go to tools->serial monitor, I want to ask you why i take a readout only from o to 32768 an i also take negative numbers. Is these numbers the real length or i have to decode them? And when number reaches it's limit (-32768 or 32768) the next number is 32768 (for -32768) or -32768 (for 32768).

    ReplyDelete
    Replies
    1. Dimitris,
      Well, there is a bug in my sketch in this line xCoord |= (0x7ff << 21). Because the result of this expression is a 16 bit integer, the compiler threats the xCoord variable as a 16 bit signed integer as well. (Likewise for the other two axes).
      It's an easy fix, and I will post an updated sketch later today.

      Thank you
      Yuriy

      Delete
    2. Hello again Yuriy,
      Did you upload the updated sketch? If yes where can i find it?

      Thank You,
      Dimitris

      Delete
    3. Dimitris,
      I added a "Downloads" page that has a link to the fixed file.
      Thank you
      Yuriy

      Delete
    4. Yuriy,
      I download the new file but i think there is still a problem. When it comes to zerow and it is time to start counting negative numbers it doesn't start from -1 but from around -1048600. Why this?

      Thanks You,
      Dimitris

      Delete
    5. Dimitris,
      I will need to play with it a bit (probably over the weekend). I use MSP430 (cheaper and easier to deal with) in my DRO with different cables, so it will take some time to make an adapter and test Arduino's code with an actual scale. I will let you know what I find.

      Thank you
      Yuriy

      Delete
    6. I should be grateful, Yuriy, if you can find a solution to this because unfortunately I have to do this only with the help of Arduino...

      Regards,
      Dimitris

      Delete
  6. This comment has been removed by the author.

    ReplyDelete
  7. Nice Job, Could you please post details of MSp430 based DRO ?

    Thanks

    ReplyDelete
  8. This is fantastic! Would very much appreciate the details on the MSP430 based DRO too.

    Thanks

    Scot

    ReplyDelete
  9. Thank you for the feedback. I'm working on a write-up for MSP430 and will post it tonight or tomorrow.

    Thank you
    Yuriy

    ReplyDelete
  10. Hello,
    I have my setup put together with both the Arduino and a livnor bluetooth board. But at current I can connect to the livnor at the OS but in the DRO app when I chose connect it connects for a brief second or 2 and then the app shows connection lost, but the pair at the OS level is still present between the livnor(light stays solid) and the tablet. I am wondering if this is because at present I have this setup in test with only one axis available (one spare iGauging unit) and connected with the controller. Any thoughts? Thanks

    ReplyDelete
    Replies
    1. Thomas,
      "Connection Lost" message appears when the state machine in the application fails to parse a position for more than a second. It's meant to handle the case when the Bluetooth transceiver is connected but Arduino is not sending the data, etc. I would also occur when there is a discrepancy between Arduino's and Linvor's Baud rate, in which case the app receives junk characters...
      When the scales are not connected the controller still sends the position to the host ("x0;y0;z0;", etc.) and the app can happily handle that.
      I've heard from three of four people having this exact issue with the Leonardo, but I can't recreate it on my end.
      If you don't mind, can you email me with your hardware details (ycroosh at gmail.com)

      Thank you

      Delete
  11. Oh and I do see this in the sketch window upon upload with my previously posted issue, avrdude: stk500_getsync(): not in sync: resp=0x86
    Now I have not seen that error before, so I might have something wrong with only one axis setup at the hardware level.

    ReplyDelete
    Replies
    1. Thomas, have seen the error a couple times. 1st time, got in a hurry and let the blue ginnie out of the chip, the last time was a communication error cause I hadn't cleaned out all of the unused com ports.. Was up to 23. Hope this helps and good luck.

      Frank

      Delete
  12. I, too, was having the "connection lost" issue which cleared up when I reloaded the sketch with the bluetooth module unplugged. The DRO now functions, but I am having the problem of the x-axis (24 inch) scale. It reads normally for about the first 12.5 inches, then switches to negaative values and counts back down. It does this no matter which axis it is plugged into.

    Bill S.
    billabx@earthlink.net

    ReplyDelete
  13. Bill,
    I think I know what the problem is with the 12.5 inch overflow. I'll try to post a fixed sketch ASAP.
    "Connection Lost" problem is VERY often caused by the Arduino being plugged into the USB port while. BT module is plugged into the same pins as the USB-to-serial chip that communicates with the PC, so there are "collisions"...

    Thank you
    Yuriy

    ReplyDelete
  14. Yuriy,
    I must apologize for not thanking you in my original post for making this project available. I just bought my first mill/drill (Taiwanese) recently and this will make an excellent addition to its functionality.

    Bill
    billabx@earthlink.net

    ReplyDelete
    Replies
    1. Bill,
      No apology is needed. Thanking me is completely optional :)

      Thank you
      Yuriy

      Delete
  15. Hi Yuriy, Just checking if you are done with MSP430 coding.

    Thanks
    Harish

    ReplyDelete
    Replies
    1. Harish,
      The "simple" version is done and I'm working on the second part of the "how-to". A version that can read a mix of scales (iGaging and cheap calipers) still needs to work and won't be ready for at least a week.

      Thank you
      Yuriy

      Delete
  16. Yuriy,

    Many thanks for he updated sketch. The 24 inch scale seems to be working normally now Next step is to get it installed on the mill.

    Bill
    billabx@earthlinknet

    ReplyDelete
  17. Yuriy,
    Thank-you for posting the troubleshooting guild. Was about to give up, but, finally up and running. Had to set the baud rate to 112500. Strange, but works. Going to check with Samsung to see about turning that down abit. Looking forward to the MSP430 build

    Frank
    adamsfl@gmail.com

    ReplyDelete
    Replies
    1. Well, after doing more of what I should have done in the first place. It never was a problem. Blue Smurf Silver comes default to 115200. My Bad

      Delete
  18. Yuriy,

    I got the scales mounted on my mill and soldered up the circuit board. Now there is an odd problem with all three scales where they will read normally for a few inches then jump suddenly to a value around 395,000. There doesn't appear to be any pattern to where this happens, but once the jump is made the change occurs at the same value. Any suggestions? I've reinstalled both the Android app and the firmware with no change.

    Bill
    Billabx@earthlink.net

    ReplyDelete
    Replies
    1. Bill,
      Are you using an Arduino for the controller? Does this happen when the motor is running? Is this the "absolute" value? (if not, what is the absolute number?)

      Thank you
      Yuriy

      Delete
    2. Yuriy, I am having the same problem as Bill, both with the 1st DRO/Uno and on the new build that you just posted with UNO and MEGA. Picked up 2 new AccuRite Scales while in Springfield (Grizley) yesterday. Tried again in my lab at work, no machines running, only DRO/Uno- 3 scales and android. Still getting the jump in numbers. Building the TI Launchpad version this weekend. Will let you know the outcome. Thank you, this is a Great project.

      Frank Adams
      adamsfl@gmail.com

      Delete
    3. Bill/Frank,
      Have you tried disconnecting two of the three scales? Does it make any difference?

      Delete
    4. Yuriy,

      Yes, I'm using an Arduino Uno and it happens on the machine and on the bench. Any number of scales plugged in and in either absolute or incremental mode. It always jumps to something around 395.xxx either positive or negative depending on which way the sensor is traveling. Thanks again for both the project and the assistance.

      Bill
      Billabx@earthlink.net

      Delete
    5. Yuriy, the new sketch has everything up and running. Both Uno and mega from all builds with I-gaging and Acu-right scales on 3 different Android devices. This has been a fun project and already building the TI 430 version. Thank you for all the help.

      Delete
    6. Yuriy, Like Frank, the new sketch did the trick for me. Thanks very much for all your help and for designing this project in the first place.

      Bill
      Billabx@earthlink.net

      Delete
  19. Hi Yuriy,
    I have some old encoders that have TTL output that I'd like to adapt to your project. Any idea what it would take to interface to these? They out put the raw A and B position channels as a series of pulses. The ones I have produce an edge every micron, with the A channel leading the B when moving to the right.

    ReplyDelete
  20. John,
    I just got a set of glass scales to play with (that use the same quadrature output) but haven't had a chance to play with them yet. If things go well the "mixed scale" version of the controller will support them (TTL will need a basic level shifting circuit to interface to 3.3V MCU, but the code should be the same).
    Thank you
    Yuriy

    P.S. I will be posting quick updates using the Twitter feed on the right...

    ReplyDelete
  21. Hi Yuriy,

    Just wondering if you'd made any progress on interfacing those glass scales? Any major issues? I'm getting ready to start accumulating some hardware and want o make sure I'm getting the right stuff.

    John

    ReplyDelete
    Replies
    1. John,
      I'm working on it currently. No major issues but the hardware is going to be a bit more complicated than the iGaging controller. Furthermore, it will *definitely* not use and Arduino. I'm trying to squeeze the "mixed scale" controller into a MSP430 Launchpad but even that is not 100% certain (might need to go to an ARM-based board).
      I'll try posting some more information closer to the end of the month...

      Thank you
      Yuriy

      Delete
  22. Hey Yuriy,

    Just wondering if you had an interim update. What sort of technical issues are you dealing with? Is bandwidth a problem reading these encoders, or are using some kind of decoder chip to interface? I've been looking into using something like an Avago HCTL-2022 to do the decoding. Then it's just a matter of reading the position, which isn't so time sensitive.

    John

    ReplyDelete
    Replies
    1. John,
      That would work (I played with a similar chip). I think this is probably the safest approach: even in the MCU is busy, you don't loose the position due to the missed ticks.

      Thank you
      Yuriy

      Delete
  23. Hi Yuriy,

    Thanks for sharing this excellent information. I've been on the lookout for a good DRO system for my mill and this really appeals to me. Very interested in the results with the glass scales or other high end scales. Keep up the good work!

    ReplyDelete
  24. Yes we are -> ALL <+ waiting with baited breath on the great glass scale crusade. I think this whole project has more potential promise for more prople than you can currently realize

    ReplyDelete
  25. Take a wild guess what I'm working on right now?
    Hint: I have two glass scales sitting on my kitchen isle right now... :)

    ReplyDelete
  26. Cant wait.. this is all to cool to be true.. a lot of people can use this... weekly update... ?anything we can do to help...? just say so...!!! Finally something REAL for android instead of -surfin the web -checkin emails -listining to music. looking at pretty pictures. Thank You Yuriy.

    ReplyDelete
  27. Yuriy.. any progress you would consider commenting on...?

    I used to put such things on my kitchen isle too...
    till my wife told me to choose between 'that stuff' or her

    8-)

    ReplyDelete
    Replies
    1. The new controller works well enough, so I'm working on assembly instructions, schematics, etc; hoping to have everything ready and posted in a few days.

      Delete
  28. Very very cool. Could you elaborate a bit... what decoder / processor... any other optional i/o beyond bluetooth (hint hint RS485 would be cool 8-)

    Yeah I have an idea I'm workin on [grin]

    ReplyDelete
  29. how did you make the tachometer?
    thanks,
    matt

    ReplyDelete
  30. Hi, Great stuff here. I have a question. I want to use some cheap digital calipers and am puzzled. Other sites I have looked at show the clock native to the caliper as an output and the schematic here shows it as an input. Am I not understanding something and it is bi-directional?

    ReplyDelete
    Replies
    1. This schematic is for iGaging scales (which need external clock source). Take a look at the main project page. There is more info there.

      Delete
  31. Hi Yuriy,
    First I want to say how thankful I am for your wonderful work. I have now set up igaging scales on my mill, rigged up the Arduino on a breadboard and all is working well. But I have found a couple of bugs with the DRO Touch App.
    1. I work in metric and if I want to create a simple hole pattern such as 2 x 2 with 10mm pitch on 0 degree angle, then the answers it gives me are, 1 - 0.00, 0.00 2 - 9.99, 0.00 3 - 0.00, 9.99 4 - 9.99, 9.99 so there seems to be a rounding error with the calculation. I have tried this with numerous other dimensions and it gets tripped up nearly every time. The only time I see a perfect result is when using some solid inch multiple like 12.7mm or 25.4mm. I assume this is also happening in the circle patterns as well but it is more difficult to prove. Is it because the dimensions are being converted through inches rather than simply being calculated in their native units?

    2. I have found that under certain conditions, a data value gets "stuck" in the INCR value of an axis, and you cannot clear it by setting zero. Here is one way to do make it happen;
    i) Set up a hole pattern and select one of the points containing a non-zero value on one of the axes. The target value will appear in the axis.
    ii) Go back to the points list and clear them.
    iii) Go back to the readout and try to reset to zero by long pressing "zero set", the axis values switch to ABS and seem to show zero values
    iv) All appears to be correct, but if you tap ABS/INCR for the axis that previously held the value, you will find it stuck in the INCR side and resetting will not clear it. Even quitting the app and restarting, the value will remain there.
    v) The only way I could clear it was to add a point while in the ABS side with 0.00 set and then select that point from the list.

    Just a couple of minor points, I hope you are able to eradicate them because as far as I can see this is such a perfect solution.

    I am now waiting for rechargeable power boost supply from Adafruit so I can maintain data even if the power goes off to the Arduino.

    Thanks again for sharing all your work, really appreciate it and I will certainly be making a donation if you can possibly clear those two tiny bugs.

    Paul Atkin, Japan

    ReplyDelete
    Replies
    1. Paul,
      Thank you for the detailed report. I've seen both bugs in the past and the new version will have them fixed. The first issue happens because the DRO uses tend-thousandths of an inch as the native units and indeed there is a rounding error. In the new version I switched to microns, which should work better.
      Second problem happens because the different offsets interfere with each other. I'm revamping that whole things as well, so that problem will be fixed too.
      Thank you
      Yuriy

      Delete
    2. Thanks for such a quick reply, so pleased to know this is still being developed so actively,

      Paul

      Delete
  32. Hello Yuri,

    I’ve developed a 3 axis digital display for my mill. (pure Hardware-Solution using an Arduino MEGA2560 and TFT-Display)
    Therefore I use 3 digital scale from the manufacturer of the mill (they are not complicated or of high-end quality but the do their job ;-)
    The serial protocol and the interface is the same, like that of the cheap Chinese caliper (21bit protocol, serial interface: clock / data).
    Anyway … I wrote a readout sketch for 3 axis and one rpm sensor (using a (one) hall sensor) for the Arduino MEGA2560.
    It works, but due to the bad performance of the TFT-library I decided to check out your brilliant DRO-app. You did a really good job – be sure I’ll send you a donation !!!

    Because my readout part of my sketch for the serial signal of the three caliper works very well, I tried to re-use that(my) code and just print (serial) the caliper-values via Blue-Tooth to the tablet (Samsung Galaxy Tab 4 7”)
    My analysis of your Arduino code come to the result, that I just need to implement the print via serial/Bluetooth in the correct format.
    I stored the results of the caliper-values in long variables – like you. The caliper is set in metric mode. A value on the display of the caliper of 2.34 mm will result in a value of the long variable of: 234. A caliper value of -12.34 (mm) will result in -1234 … a display value of 123.45 will result in 12345 .. and so on.
    If I just print that value with the following code:

    Serial.print(F("X"));
    Serial.print((long)finalValue_M1); // finalValue_M1 is the long variable
    Serial.print(F(";"));

    But the TouchDRO-App just shows the corresponding value in the last two digits, and only, if the app-setting (inch/mm) is set to inch.
    E.g.: a caliper display value of: 2.34 will cause in: 234 in the long variable and will shown as: 0,023 in the DRO-App (inch-setting). Switching to mm, will cause in absolutely confused value(s). Switching the unit on the caliper from mm to inch, will cause confusing values as well.
    I made some further testing, and I recognized, that I need to multiply my value by 100 first, to display the value in the correct way/position of digits.
    Another test showed, that a caliper display value of 1.00mm (finalValue_M1 variable = 100 or 10000) will cause in an display of 0.025 or 2,540.
    If I set the unit in TouchDRO to mm, the display value is 12,40. I guess the that the values of the long variable are not compatible with the expected ones of your DRO-App.
    Could you please describe more in detail, what the value of the long variable (on Arduino side) have to be, that the App will display the values correctly (metric units) ?
    Another question is related to the variable holding the rpm-value and the format of that value you expect in the TouchDRO-App.
    I use a simple hall-sensor on an interrupt pin of the Arduino. I’m just counting the milliseconds between the interrupts, calculate an rpm-value and store the value in a long variable. (rpm_final = 60000000/rpm_w2 ; // rpm = 60[sec] / t [sec] (t in milliseconds) A value of 1000rpm will be stored as 1000 in the long variable

    If you need my sketch – just let me know.

    Thank you very much in advance,
    Ulf

    ReplyDelete
    Replies
    1. Ulf,
      You need to "calibrate" the app. In the "Settings" screen you can set the expected "counts per inch/rev" to whatever they need to be. Look at this post for more details: http://www.yuriystoys.com/2014/02/dro-scale-calibration.html
      Thank you

      Delete
  33. Hello Yuri,

    thank you for your fast reply - I'll check that out and give you a feedback. Very good description!

    I assume the difference to my solution (using always the absolute values from the caliper and just display them) is, that you work with the delta-information and calculate everything inside of the TouchDRo-App. isn't it?

    Kind regards,
    Ulf

    ReplyDelete
    Replies
    1. Ulf,
      That's correct. The app is deigned to work with incremental scales (glass scales, etc.) that don't have any logic. Calipers have their own logic circuitry, so you will need to chose which one you decide to use. (probably the App).
      Thank you
      Yuriy

      Delete
  34. Hello Yuri,
    Thanks for your efforts on this very useful system. A contribution is on the way.
    I am using iGaging scales on a standard round column Chinese mill with ball screws.
    I had a PCB made that would accept a programmed 328, Bluetooth, and the other needed components and all was working fine with one exception. Occasionally, the reading would jump while the mill was running. I put an EMI filter on the power and a good sized clamp-on ferrite on the lines from the scale readers close to the control. This cleared up that problem. But, then sometimes when I power up or especially when I turned off the mill, the reading would jump to some other number. That was cured by plugging the 328 board into a different 110AC circuit. Now everything is rock solid. Thanks again!

    ReplyDelete
  35. Hello Yuriy,

    IT WORKS PERFECTLY !! :-)

    I just changed the CPI value to 2540 (because I have metric calipers with a range of 100 value changes per 1mm ... or in other words an accuracy of 1/100mm) That will be 2540 value changes per inch. All values and value changes will displayed correctly now :-)
    Also the value for the rpm - I just print out the numeric value of my script (where 100rpm = 100 ...100rpm = 1000) and the value will be displayed correctly as well.

    Brilliant App ! A donation is for shure!!!

    Just some minor change/feature requests for a future release oft he app ;-)
    1.) could you please make the font color for the axis (or at leat for the rpm value) configurable?
    On my device, just the rpm value is displayed in red and could be better distinguished from the axis values

    2.) Is it possible to display a separate "set zero" button for each axis on the main/readout-screen?
    There is still enough space for such a button - I often set just one axis to zero and currently I always have to press the corresponding axis value and then in the pop-up window reset the axis and go back. This is a little bit complicated. Maybe this feature can be designed as a configurable item for user who don't need such a butten for each axis on the main screen.

    Thank you very much and kind regards,
    Ulf

    ReplyDelete
    Replies
    1. Ulf,
      Glad you got it to work.
      In response to your requests:
      1 - I can't make it completely configurable (without a good amount of work), but I can provide a way to select from a few colors. I'll add that to the long "to-do" list
      2 - you can long-press the abs/incr button to set axis zero. In the next version the tools and points list will be collapsible and (when collapsed), the axis will include zero and inch/mm buttons.
      Don't know when those changes will be "in production". At this point I have almost no time to work on the project, and that won't change till next summer, but I'm hoping to start pushing the updates to the beta testing group in a few months.
      Thank you
      Yuriy

      Delete
  36. I'm interested in doing this to my mill. I see the Bluetooth modules for sale on eBay, but I can't seem to find the just the scales. All the ones I see come with a display. Is there a place I can buy just the scale with no display, or do I buy the set and throw the display in my toolbox?

    ReplyDelete
  37. Dear Yuriy!
    Great design! I love the way you approached to DRO problem. Very clever:) i'm trying to play with it butal i have are linear scales and some basib A;
    B signals encoders and arduino mega 2560. Arduino has 6 external interrupts so it should be possilbe to support 3 glass scales. Would you be so kind and share the code for msp430 to see how you've implemented encoder routines? Then i'll try to implement similar solution in arduino. So far i wrote some sketch based on arduino's official page about encoders and it work very nice. Thanks! I'm looking forward to hearing from you. Cheers:)

    ReplyDelete
  38. Hello,
    In your schematic for connections to the Arduino, the USB connections are shown as 1234. The USB breakout boards I have are labeled VCC, D-, D+, ID and Gnd. Which of these are the Clock and Data pins.
    Thank you.

    Barry

    ReplyDelete
  39. Am I right in understanding that TouchDRO handles the conversion of the data from the caliper to inches or MM?
    I have a working Arduino sketch that displays the output of the cheap cheap Harbor Freight scales when a level shifter is used on the data and clock outputs.

    ReplyDelete
  40. For additional scales, have you considered using an entire Arduino port access and writing to a 21 element char array and then parsing them after? Port access is extremely fast, and would handle up to 8 scales?
    Also, perhaps when using many scales, a level shifter from 5V to 3V3 would be more robust? Using an Arduino Due, with it's 3V3 inputs and better processing power (84mhz) would be a good option as well
    Nice project!

    ReplyDelete