Jump to content
Brian Enos's Forums... Maku mozo!
Sign in to follow this  
M852

DIY Bluetooth Interface for ProChrono Digital

Recommended Posts

This thread is a carry-over from the one covering the DIY cable for the ProChrono Digital USB interface. I figured a new thread would be appropriate to keep the wired vs. wireless discussions organized.

The detailed instructions in the attached PDF file cover building a Bluetooth interface for the ProChrono Digital chronograph. In short, it describes how to build a Bluetooth receiver and use it to make a wireless connection between the ProChrono Digital and the PCRemote software on a PC.

Two warnings, though:

  • First, If you attempt this build there is a chance you could break any and all of the parts, including your chronograph. Do not attempt this if you are not comfortable installing Windows drivers & software, using a soldering iron, and guarding against electrostatic discharge (ESD). You alone are responsible for what happens to your equipment.
  • Second, getting serial devices working over Bluetooth in Windows is straight-up voodoo. Seriously. There's about a 50/50 chance the Bluetooth receiver will work on the first pass through the instructions, and it's entirely possible to do everything right and still end up with a receiver that doesn't work. YMMV, but just know this up front.

Having said that, here's a list of the components you'll need:

  1. Bluetooth-to-Serial Module ($7-18)
  2. CP2102 USB-to-Serial UART/TTL Module ($5-10)
  3. Switching Voltage Regulator ($5-6)
  4. Battery(ies) ($2-5)
  5. Battery Holder ($2-3)
  6. ⅛” (3.5mm) stereo cord and/or jack ($3-7)
  7. Power Switch (optional) ($1-2)
  8. 10kΩ Resistor ($1)
  9. Small Project Box/Enclosure ($3-7)

So, depending on what components you select and how particular you are, you can build the Bluetooth receiver for +/- $45.

I had a lot of fun working on this build. The majority of my electronics projects up to this point usually involved either a PC power supply or a 12V car battery. What you see in the instructions is a culmination of the lessons learned and the do-overs I worked through over the course of building the prototype. If you have any suggestions to add, please post them here or PM me. (I'm still looking for a 3.5mm stereo jack with an isolated SPDT switch that closes when the plug is inserted.)

On my wish list of future projects:

  1. Get the Bluetooth receiver integrated inside the ProChrono Digital housing.
  2. Find some enterprising coder(s) to write an Android equivalent of the PCRemote software now that we have a Bluetooth option.

Edit 6/9/13: I'll try to post some pics of the build once I clear the minimum post limit.

DIY Bluetooth Interface for ProChrono Digital v1.0.pdf

Edited by M852

Share this post


Link to post
Share on other sites

It actually wasn't too hard after figuring out which batteries & regulator to use. Getting the Bluetooth serial port to work in Windows was just an exercise in patience & persistence. It was a lot easier than the slingshot/hold-open mod on my Ruger MKIII.

Share this post


Link to post
Share on other sites

Here's some pics I took working on the prototype:

Testing the parts using a breadboard. Very helpful since it beat the fool out of soldering/desoldering components trying to figure out what works:

post-47370-0-63176600-1371971577_thumb.j

The back of the PCB holding the components. I used what I found at Radio Shack. It's not pretty, but it worked.

post-47370-0-62094900-1371971665_thumb.j

View of everything stuffed in the enclosure:

post-47370-0-67981500-1371971682_thumb.j

Pic of the enclosure with all the wireless goodness. Notice the jack is the only thing on the outside of the enclosure. The jack has an isolated switch that turns the receiver on when a jack is inserted, ergo no external on/off switch necessary. Very simple, clean.

post-47370-0-30199100-1371971697_thumb.j

I think I'm going to do a second prototype using Hammond 1593PBK enclosure instead of the Frankenstein I cobbled together for the first one. The Hammond has a separate battery compartment with a removable cover and a PCB sized specifically for the enclosure. They also sell battery holders made specifically for the enclosure (e.g., Mouser # 546-BH3AAAW). It's a cleaner, less hobby-shop solution.

Share this post


Link to post
Share on other sites

Here's a pic of the generic schematic I used for the prototype:

post-47370-0-38082100-1371973624_thumb.j

Here's a pic of the prototype in use.

post-47370-0-12736500-1371972425_thumb.j

(For the curious, the muzzle velocity of a dart fired from a Nerf N-Strike Recon CS-6 is 42ft/sec.) :D

Edited by M852

Share this post


Link to post
Share on other sites

Thanks for the heads up on this. I should finish this project. I tried a quad FTDI USB to serial for a PC interface and it sorta worked. I got a lot of errors. I then built a TTL buffer of my own design and interfaced to that and then to the quad FTDI module and it worked ok. I wonder if my (specific) chrono has problems with the serial output?.. it seems to have very little drive capability. With two high impedance 2N3904 buffers (one to invert it back to the correct polarity) it's stable.

I haven't actually used it yet (I'm still quite aftraid I'll shoot it) but I do plan on getting it out by the end of the summer. The only catch I see with the Bluetooth is the battery power... after I thought that through .. I'm not convinced it's any better than running 20' of cable. What would make it better is reverse engineering the protocol, but it's proven to be more difficuly than I expected. If I did, I'd write an Android app and THAT would make it worthwhile.

Someday.. probably in the fall and winter "when I have time again".

Share this post


Link to post
Share on other sites

I haven't actually used it yet (I'm still quite aftraid I'll shoot it) but I do plan on getting it out by the end of the summer. The only catch I see with the Bluetooth is the battery power... after I thought that through .. I'm not convinced it's any better than running 20' of cable. What would make it better is reverse engineering the protocol, but it's proven to be more difficuly than I expected. If I did, I'd write an Android app and THAT would make it worthwhile.

I used the DIY thread to save a few bucks by building my own cable. Quick and easy project. I then started reading the Bluetooth thread and considered it for a minute, but then realized a cable is all I really need. I initially took my computer and new cable to the range and it worked great, but then I realized it was overkill as I was only testing a few new loads. In fact, I probably won't bring my cable or computer to the range anymore, but instead just use it to download the data when I get home.

If your worried about shooting your chrono, put small pieces of high visibility tape hallway up on the uprights and in the middle of the sun shade. This gives you an aiming point. Knock on wood, I've never shot my chrono before.

More shooting, less engineering.

Share this post


Link to post
Share on other sites

I initially took my computer and new cable to the range and it worked great, but then I realized it was overkill as I was only testing a few new loads.

I use the chrono with factory ammo to calculate an interquartile range (one method to narrow down which factory loads are more - or less - accurate in your particular hardware.

More shooting, less engineering.

Shooting is engineering. :D

Share this post


Link to post
Share on other sites

I use the chrono with factory ammo to calculate an interquartile range (one method to narrow down which factory loads are more - or less - accurate in your particular hardware.

Shooting is engineering. :D

I must admit that I do like being able to change strings without having to walk over to the chrono. This is definitely one reason to drag out the computer and cable. How about a design for a remote (send only to change strings).

Other than that if you're testing factory ammo, you can test up to 10 different brands/loads of ammo (10 shots per brand/load), turn off the chrono and go home to download and analyze the data in the comfort of your home/office.

I suppose shooting may be engineering, but the more I shoot, the better I get. I generally learn a little something every time I shoot... of course some days I feel like I'm going backwards. I'll never be as good as the guns I shoot or the ammo I produce no matter how much I know about shooting or how much I practice. I'm doomed either way, but I do enjoy it.

Share this post


Link to post
Share on other sites

Interesting article. Now you make me wonder how my handloads are.. They seem more accurate than normal ammo to me. Maybe I don't want to really know? ;)

I suppose you will convince me to get this going again. I still am worried that my unit needed those extra buffers to work with the FT4232 quad module I had lying around. I would have not guessed it would have been much different than the single FTDI mentioned here...

But Bluetooth with an android app could still be quite useful at the range.

And I «am» an engineer so this sorta project is fun to me..

Share this post


Link to post
Share on other sites

I've also considered filling a five gallon bucket with sand and putting it in front of the chrono as well (with the screens above the bucket) as an "oops" trap.. if I did that having remote readout would be better as I'd be blocking the screen of the chrono and I'd definitely not see it then and it would be harder to change strings. Hopefully I'll sort this all out as I really should chrono my loads...so many toys.. so little time...

Share this post


Link to post
Share on other sites

But Bluetooth with an android app could still be quite useful at the range.

Now we're talking! Better yet, make an app to work with the Bluetooth on an iPad/iPhone.

Share this post


Link to post
Share on other sites

For all that are interested, I’ve managed to create an android app and via Bluetooth control the Chrono via a smart phone. Transmitting to the Chrono works fine, that is, remote control, still having a few issues with receiving some data, I think it’s a timing issues with receiving the larger commands. I’m still working on it. If anyone wants any info let me know and I’ll try and organise something.

post-42386-0-54334800-1373629143_thumb.p

Edited by BenOz

Share this post


Link to post
Share on other sites

Very nice. Beat me to it, darn it! I am obviously interested but it will be several weeks before I can pick up this project again. This time of year kinda sucks.. everything else is more important.

Did you write this in Java or another language in the Andoid OS? I've only written silly little programs so far in Java for Android..

The big question for me is that my provider has so much stuff locked out of my phone that I'm wondering if I'll need to do this on a tablet. Maybe so. I suppose the price of a ProChrono, the interface stuff and a cheap Android tablet isn't that much... considering. I could hork my wife's or son's for testing...

I just saw a new "magnetic" chrono that looks interesting. It can ignore the muzzle blast. It's about 3x the price of the ProChrono though. Again why a "new" product would come out w/o features like Bluetooth serial is beyond me.

Again.. good job on this. I suspect you will work out the timing. Are you sure it's timing and not data corruption? Verify that the returned strings are not corrupt and have the proper checksum. The interfaces that this site listed worked.. but "glitched" a lot with my unit.

I noticed that for the most part on receive the CE software ignored the checksums and even would crash occasionally on bad data. But often it covered up small bit glitches that were occuring with the original interface I tried. Having the four port FTDI module allowed me to monitor on one of the other ports the data going to/from the ProChrono. I could see the program barf occasionally this way.

I ended up putting two 2N3904 open collector transistor inverters together (to make a higher impedance-- 10K-- input to the Serial->USB converter, and non-inverting buffer) and that seemed to clear it completely up on the traditional PC setup. I used a FTDI 4232 module though-- because I had one-- for an interface and maybe it's more sensitive than the bluetooth module and/or the single chip FTDI. Or maybe I have a bad unit... Really can't claim that to CE because I don't have their interface, though...

I drew up a schematic. I really should get my act together and post it as a JPEG .. someone might find it useful...

Mentioned it because I noticed it when I was trying to reverse engineer the protocol with my unit. The inverters really were quite a simple fix, though.

Share this post


Link to post
Share on other sites

I used two programs for writing the code, App inventor and again in a program called Basic4Android (B4A). App inventor is a web based software package that Google designed and has since handballed it over to MIT to look after.

B4A is very easy to use, but the biggest let down is the GUI interface setup, needs a bit of work from MIT's end. There is no 'code' as such, more like blocks that you interlink together to form a routine.

Basic4Android is another program with a lot more power and flexibility, very similar too Visual Basic, in fact if you know VB you'll have no issues with B4A, but like VB you need to physically write the code in B4A. B4A also has a neat debugging feature that you can use to verify data to and fro, when talking to the BT module.

So far I've tried with a few android phones and all seem to work well, but you must make sure the drivers are installed for you particular phone or you'll end up putting the phone through your monitor trying to get it to work with the software!!

At the moment I haven't got a routine to check the checksum and I think that's 90% of my problem, like everything else this projected has taken a back seat, when I get motivated ill try and suss out the issues.

post-42386-0-03624700-1373685511_thumb.j post-42386-0-45297300-1373685526_thumb.j post-42386-0-29119600-1373685538_thumb.j

Edited by BenOz

Share this post


Link to post
Share on other sites

I don't have a chronograph yet. It was while researching that inevitable purchase that I came across these "app discussions".

I use an Android phone (Motoroal Droid RAZR MAXX ...Android Ver. 4.`1.2) AND have a Ver 2 wireless-only iPad so am interested in just about any and all digital "connections" between a chronograph and a device that is back with me BEHIND the firing line.

What is the current state of development?

For the record: I'd be willing to pay $35.00 - $50.00 for a hardware/software combination that linked phone or tablet with a chronograph.

Share this post


Link to post
Share on other sites

As I'm not an electrical engineer I don't have a lot to add to this thread except "Awesome job guys!" but I do a little coding on the side and have dabbed with serial communication and the Prochrono. I haven't written anything except a "test" program to get and extract data so far, as well as issue a few commands. The project took a back seat to some of my other hobbies lately. Anyway, the following code is what I use to verify the checksum of data received from the ProChrono. It's pascal/Delphi code and isn't written in the most compact or efficient manner, but it's easy to read and makes sense. For those of you who understand bit manipulation you can do it quicker and with less code, for me this was the easiest way. For those writing apps to deal with the ProChrono data, it might help explain how the checksum is calculated.

{
 To calculate checksum, add up the ascii codes of all the individual characters
 in the string EXCEPT for the : and the last 2 characters in the string (the checksum)
Convert the decimal total of the ascii values into a hex string.  (ie 1566 would become $61E)
Take just the last 2 digits of that hex number as a one byte hex value and sutract it from $100  (ie $100-$1E)
The result (in hex) should match the last two characters in the string.
There's a lot of converting from string to numeric and back going on in this function.

Here's a real world example.  The string we received from the ProChrono is :1403030A7F30002E002D0000002F3F
First we add up the ascii value of '1' (which is 49) plus the ascii value of '4' (which is 52) etc.  We do this
for all characters EXCEPT the colon at the beginning and the last 2 checksum characters in the string ('3F').
The total of all the ascii values is 1473, which equals $5C1.  Take the least 2 significant digits of the HEX
number, which is $C1.  Subtract that from $100 to get $3F.  The '3F' matches the last two characters in the
string we received from the ProChrono, so the string is valid.
}

// Note -- this function will ignore a colon but will include ALL bytes in the checksum calc so the 2 checksum bytes should be removed first!
//
function CalcChecksum(sdata:string):string;
var x,asciitotal,hexvalue:integer;
    hexstring:string;
begin
  asciitotal := 0;
  for x := 1 to length(sdata) do // for every ascii character in the string...
   begin
     if sdata[x] <> ':' then  // except the colon
       asciitotal := asciitotal + ord(sdata[x]);
   end;
  // showmessage(inttostr(asciitotal));
   hexstring:= IntToHex(asciitotal,1); // convert the ascii value total to a hexidecimal string

   // get the 2 least significant hex digits of the hex string
   // ($50D becomes $0D, $2EC becomes $EC, etc)
   hexstring := rightstr(hexstring,2);

   // convert the hex digits to a numeric hex value so we can subtract it from $100
   hexvalue := StrToInt('$' + hexstring);

   // subtract from $100 and convert the result to a hex string value once again.
   result :=IntToHex($100-hexvalue,1);
end;

Share this post


Link to post
Share on other sites

Dude, you are awesome. I've been trying to take the hex byte values represented in the string as BCD (like) and calc the checksum all along. No WONDER it never worked. I suppose read literally that is what the specification says, but in any "normal" situation a hex string (especially one that looks like a INTEL format .HEX file) would be done by the hex values represented in the string and not the actual string bytes! Either way, of course is valid...

So.. yeah. I'll take some time soon and post a C# equivalent to this. I suppose for Android, I'll end up doing Java as well. I have to apologize. In my current situation summers are very, very busy for me, especially late summers. Our FY at work ends 9/30 and becuase of that from Middle of July to about Halloween is hell. I did what I could over Christmas (we have a plant shutdown at work) and got it as far as I stated then.

The sad thing is I've not been to the range since late May.. so actually getting some trigger time is much higher on the priority list than this project. I will work on it though eventually. I am an avid caster and reloader for pistol (and not so much rifle reloader) and an improvement in the stastical analysis of the data from the chrono should help me out.

Thank you for cracking the code on this one. I spent hours flipping bits, complementing stuff.. trying different combinations of calculated bytes, etc. But duh, read *literally* that is what the specs said.

BTW, I am a EE by degree and a SW Engineer by title. So anyone working on this, please feel free to ask me questions. ;) Or not since I missed one obvious case to try! ;)

Fred

Share this post


Link to post
Share on other sites

C# version...

Drop in a button and a label in the designer and then this. ;)

using System;
using System.Collections.Generic;
using System.ComponentModel;
using System.Data;
using System.Drawing;
using System.Linq;
using System.Text;
using System.Windows.Forms;

namespace ProChrono_Checksum
{
    public partial class ChecksumCalc : Form
    {
        public ChecksumCalc()
        {
            InitializeComponent();
        }

/*
 To calculate checksum, add up the ascii codes of all the individual characters
 in the string EXCEPT for the : and the last 2 characters in the string (the checksum)
Convert the decimal total of the ascii values into a hex string.  (ie 1566 would become $61E)
Take just the last 2 digits of that hex number as a one byte hex value and sutract it from $100  (ie $100-$1E)
The result (in hex) should match the last two characters in the string.
There's a lot of converting from string to numeric and back going on in this function.

Here's a real world example.  The string we received from the ProChrono is :1403030A7F30002E002D0000002F3F
First we add up the ascii value of '1' (which is 49) plus the ascii value of '4' (which is 52) etc.  We do this
for all characters EXCEPT the colon at the beginning and the last 2 checksum characters in the string ('3F').
The total of all the ascii values is 1473, which equals $5C1.  Take the least 2 significant digits of the HEX
number, which is $C1.  Subtract that from $100 to get $3F.  The '3F' matches the last two characters in the
string we received from the ProChrono, so the string is valid.
*/

// Note -- this function will ignore a colon but will include ALL bytes in the checksum calc so the 2 checksum bytes should be removed first!
//

        public string CalcChecksum(string sdata)
        {
            return ("$" + CalcChecksumByte(sdata).ToString("X2"));  // return format the same as ProChrono
        }
 

        public byte CalcChecksumByte(string sdata)
        {
            int asciitotal = 0;
            byte hexbyte;

            for (int x = 1; x < (sdata.Length-2); x++) // for every ascii character in the string...
            {
                if (sdata[x] != ':') // except the colon
                    asciitotal = asciitotal + (int)sdata[x];
            }

            hexbyte = (byte)(0x100-(byte)asciitotal);  // Strip off all but last byte, then complement
            return (hexbyte);
       }

        private void buttonTest_Click(object sender, EventArgs e)
        {
            labelChecksum.Text = "Checksum: " + CalcChecksum(":1403030A7F30002E002D0000002F3F");
        }

    }
}

Share this post


Link to post
Share on other sites

Dude, you are awesome. I've been trying to take the hex byte values represented in the string as BCD (like) and calc the checksum all along. No WONDER it never worked. I suppose read literally that is what the specification says, but in any "normal" situation a hex string (especially one that looks like a INTEL format .HEX file) would be done by the hex values represented in the string and not the actual string bytes! Either way, of course is valid...

Believe me, I pounded my head against the wall trying to figure the checksum out as well, thinking the same way you did. I did what was written (or so I thought) but it didn't work... so I just kept plugging away until I came up with the answer. It took a while, but was a major win when the numbers finally worked out. Glad to see it wasn't just me!

Share this post


Link to post
Share on other sites

Honestly if I had figured out that checksum thing sooner, I would have probably already hooked up a Bluetooth module and written software by now. It was so frustrating and the final solution was so simple. Maybe I should port my C# example to VB.NET for the B4A author (BenOz)? I'd have to probably do all of that "ORD" and "ASC" stuff, though wouldn't I?

Actually B4A's syntax looks exactly like VB.NET. Maybe I will port it and post...

I'm very happy that you let me in on the secret of the checksum, Doug. I can now move forward with this effort again!

Share this post


Link to post
Share on other sites

You guys don't realize the degree to which you are re-affirming my choice to focus on hardware vs. software. :D

Share this post


Link to post
Share on other sites

Both the hardware and software tips are awesome. Can't wait to start writing my own interface for my chronograph.

Thanks and keep any tips/roadblocks you encountered posted here please.

:D

Share this post


Link to post
Share on other sites

Oh Why not? I *used* to be a big VB guy in the Version 6.0 days but haven't done much with .NET.

But again, drop in a button and a label and give this a Whirl in VB.NET: (And no I will NOT port it to F#!)

Public Class FormProChronoChecksum

    Private Sub ButtonTest_Click(sender As System.Object, e As System.EventArgs) Handles ButtonTest.Click
        LabelChecksum.Text = "Checksum: " + CalcChecksum(":1403030A7F30002E002D0000002F3F")
    End Sub

    Public Function CalcChecksum(sdata As String) As String
        Dim hexbyte As Byte = CalcChecksumByte(sdata)
        Return "$" + hexbyte.ToString("X2")  ' return format the same as ProChrono '
    End Function


    Public Function CalcChecksumByte(sdata As String) As Byte
        Dim asciitotal As Integer = 0
        Dim x As Integer

        For x = 0 To sdata.Length - 3 ' for every ascii character in the string... '
            If sdata.Substring(x, 1) <> ":" Then ' except the colon '
                asciitotal = asciitotal + Asc(sdata.Substring(x, 1))
            End If
        Next x

        Return (256 - Convert.ToByte(asciitotal And 255)) 
                 ' Strip off all but last byte, then complement '

    End Function

End Class

Edited by w0fms

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Sign in to follow this  

×
×
  • Create New...