Jump to content
Brian Enos's Forums... Maku mozo!

w0fms

Members
  • Posts

    13
  • Joined

  • Last visited

Profile Information

  • Real Name
    Fred Spinner

w0fms's Achievements

Looks for Range

Looks for Range (1/11)

  1. Interesting and obvious.. I do have a universal laser and a cartridge one for .223.. So yeah.. That is obvious.. I do need to work on the project again.. I won a iPad mini.. And really, compared to Android I hate it... But I should look into writing an app for both. Thanks though.. I have a bunch of good functioning pistol loads that I need to chrono... -10°F tonight. .. It might be several weeks before I go out again.. . Thanks for the suggestion of the laser and bolt removable. I am mainly a pistol reloaded and shooter but yeah, both methods make sense..
  2. I've been monitoring this and not posting for awhile. Again.. I wonder because of the battery issues if Bluetooth is even a good idea.. but in the case of using a phone for a display.. it is one of the easier interfaces. I think when I go to do mine, I am going to run a 25' shielded cord with the Asyncronous Data to a remote box with the Bluetooth interface in it and then control it with Android. It's a big project, and I've had loads of more important things to do. There is a plant shutdown between Christmas and News Years... I have all of the parts, including those "cheap" bluetooth modules in my Arduino parts kit. A box with a 2x16 LCD display and the Bluetooth module would probably be killer and I agree the straight C needed for the Arduino would be trival-- more so than the Android app would be. I'd write my app in native Java, even tho I hate it.. One can release code and still put it in the play store for a little bit of money.. that could be a way to thank the author.. I am a Software Engineer with a BSEE degree and an MBA, by the way so this is trivial in concept.. but it always takes time to implement even easy efforts. When I had time the damn checksum held me up... I've not given it up.. I do want to do it.. it's just not a super high priority for me at the moment. Oh and a suggestion for the 9V to 3ish V for an internal Bluetooth-- build or purchase a step-down (buck) switching convert to do this and the battery will be less killed. Some of these are 85% efficient. Mouser/Digi-Key, etc will have these "DC-DC Converters available built for about $10. E-bay might too.. If you can open the unit and then put this all inside it would be killer. If done right, may CED could sell it built that way... Fred
  3. 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
  4. 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!
  5. 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"); } } }
  6. 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
  7. 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.
  8. 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...
  9. 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..
  10. 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".
  11. OK.. sorta of posting to myself here... but whatever. I dug up a 4 port FTDI 4232H module and figured out by looping two of the ports back on themselves the baud rate is 1200, no parity, 1 stop, 8 bits. The thing that is nice about this 4 port module is that I'll use one port to talk with the unit when I get it and then use two of the other three to monitor comms from the application. I'll figure it out and post the protocol. Seems simple enough. This module is 5V tolerant but is 3.3V only.. we will see if it talks... if it does the port over to the Bluetooth module will be trivial and basically no extra parts. The only additional thought I had is still putting the module in a box with 10-25' of cord to get the Bluetooth radio closer to the tablet/shooter.. 25' away should still work but it's getting to the end of the range of Bluetooth.
  12. I will see what I can do. I should probably order off one of those Mouser adapters to start at a working point. It will be next week before I get the unit. Apparently MidwayUSA isn't quite shipping at their normal lightning fast pace in the last few weeks (I wonder why? Thanks "O"...! But I did find the Bluetooth modules in the junkque pile! They are about $10 on e-bay. JY-MCU HC-06. They did work on my Windows laptop talking to an Arduino but never did try it with my phone. I have some tablets too now in case my phone has serial blocked as some do to stop tethering. In any case it is not a one night project. As for the sending to the unit protocol, the commands listed in this thread are correct but how I think the checksum works is: add the hex numbers (in ASCII format), truncate to 8-bits and subtract from 0x80... So the command maybe 0000003 and the checksum is 7D... But until I get the unit and see it the other way I can not be 100% sure. It would sure be nice if this protocol was documented somewhere... So getting the windows stuff working first will have to happen... I'll keep you all updated... Fred
  13. Sorry to revive a potentially dead thread but I just bought a ProChrono Digital (on it's way from MidwayUSA) and being an Electrical Engineer (by title Software Engineer) and having a literal stocked toy chest of stuff like that FTDI chip adapter I wonder if any of you have the following info (so there is less reverse engineering): Baud Rate that the ProChrono/Software uses. Any info on the returned data protocol. Confirmation that the unit is 5V and not 3.3V (although driving 5V TTL with 3.3V TTL it usually does not matter). One of the "toys" in my collection is a TTL (3.3V/5V) serial Bluetooth module (e-bay item from China). I could use that right off the bat as the interface on the laptop with a Lithium coin cell powering it... but I'd need to know the baud rate as it has to be "flashed" into the firmware of the device first. What would be a cool project is to reverse engineer the protocol and write software for Android. Don't know if I'll have the free time to do it, but it's tempting. I simply can not leave stuff like this alone. Thanks. Fred
×
×
  • Create New...