My first 7.62x39 AR

[Lane]

1 hour ago, 98Z5V said:

run it and see what's up

4:01:39.57 is what I recorded for the 160MHz run. That's exactly 1.5 hours longer than the 80MHz battery time with regard to any small fluctuations. I think my 80MHz time was actually closer to 2:27:59 give or take. 

About a 62.5% increase in battery life for doubling the clock speed.

[Lane]

Minor update here. I spent a few hours checking different versions of the core code to see where WiFi breaks. I was really hoping to see my button ISRs fire in the process; but that didn't happen. I'm running newer code though, so I get a few new features and a 10% increase in available RAM as a result of compiler changes (more program space too, though I don't need it). 

I had to write my own ISR code for the buttons which runs in the main loop. At first it was a mess because the button had tons of noise. As I worked on coding a debounce solution the button apparently began to wear in. I've got it down to a reliable two hits per button press which is just fine for now. Easy enough to tune out the one extra, and only execute code off on the second one. One advantage of writing the debounce code is the ability to detect button press length; so it can be pressed for a long time to perform a different function.

Didn't expect the button input to be such an issue; that original ISR code was written long ago. I just didn't bother testing because it was supposed to work. No matter though; it's functional now without much impact on the loop speed.

I've been running more battery tests along with all the code testing. Also, having to test the button code every few minutes made me work in other improvements and upgrades along the way. In particular the program that runs when "Go" is pressed has a lot more information. It now reliably counts shots on a progress bar. The same progress bar would show time countdown if running in that mode. Made me realize that it might need to be an AND/OR situation though. What if I wanted to run that program for 30 rounds OR 30 seconds; whichever came first?

New hardware build is only waiting on wire at this point. I have been using it to test the button code with nothing connected to it. I have a bag of silicone jacketed wire around here that would be perfect for this build; but I haven't located it. I also ran into a case where I drained the lithium battery too far for the circuit to pick back up in terms of charging or powerup. I think it's just going to be a capacitor to help fire up the DC/DC converter; but it remains to be tested. Adding a battery meter is something I've been thinking about; but not yet figured out how to implement. Nearly finalized on the total hardware implementation though. After that, everything is fixable with a firmware upgrade which can be done in the field. 

I've got some new graphics debug code running. I'm going to have to stop clearing/writing the display so often, and split up my memory writes. I'm only 13ms or less on those long loops (0ms when only reading audio input); but I can get that below 0ms with little effort. Not sure what the lower limit will be in terms of fractions of a ms, but I will try to bounce off of that. If the display is entirely off during the shot timing process, I can get some serious speed right now. Might as well make that a new feature; the olympic timing mode. It would almost certainly need a coprocessor to achieve actual ns resolution; but it's not that much more expensive. 

[Lane]

I've gotten most of my small, known bugs worked out. Most were single character changes to the code that I had already figured out by playing around with the unit. I also installed a paper shim in the original battery build to actuate the second button. Tried a half dozen different layouts in the initial build and couldn't make two batteries fit. The header pins I soldered on the bottom of the main board protrude too far for any kind of stacking.

Some of the button code isn't quite right; but that's not my biggest concern anymore. Code nearly fixes itself if I think about it long enough.

Seems like the battery regulator/charger board isn't working properly; or the battery has its own protection. When I run it completely flat I can't get it to charge again in circuit. I have to open it up, remove the battery, and connect it to another charger. Might be almost 0.1v too low in full discharge; fixing that would likely be replacing a tiny resistor on the board. I have tried quite a few batteries already.

I'll assemble the second unit soon and inspect them both carefully side by side. It's not a big deal to order a replacement, or modify the board if it's out of spec. I did get a 10 pack of dumb lithium chargers (no battery protection chip); so that might be a solution if the existing boards won't work at all. If I don't discharge the unit fully; it has been quite reliable. If I move the position of the rotary encoder inside the case, it MIGHT be possible to fit an 18650 2,600mAh battery. I was kind of mad I cracked this particular case when trimming; and I do need to order more boards with the attached display (to replenish my own stock). That beast would allow for roughly 27 hours of non-stop runtime; quite a bit more if it goes to sleep ever.

Many of the new settings were implemented earlier today. Most of the rest of the code changes are roughly like shuffling a deck of cards. I will simply be copying and pasting code that is already running, into different functional blocks to even everything out (so there aren't spikes in timing for no reason). When I know for sure what's up with the charging circuit/regulators; I'll move in one direction or another.

 

[Lane]

Nothing new in terms of the battery charger situation. The battery build is working fine when I don't let it die completely, and I've been testing it regularly. I had a new thought about that particular problem, so I'll check on that next time I open the enclosure. Two batteries fit well in the newer build; so if I'm careful with my wiring it should be an 8 hour unit.

I looked into buying more CPU/display boards, but the seller is away until Feb 14th; chinese new year I assume. I was surprised that I couldn't find anything like it for even twice the price. That's going to have to wait; and means I won't be working towards a 18650 battery build anytime soon. I will need to work with the parts on hand, and figure out some other elegant solution to the dead battery issue. I don't see any mention of brownout detection onboard, but could design a circuit to signal a digital pin on low battery; if I absolutely have to.

While looking for parts here, I did come across a development board which I thought might hit ns timing resolution. Such a thing would simply be used as a co-processor to the existing build. Then I read the specs to make sure it was worth the effort; not even close. Fast CPU, with a slow ADC. I did finally reign in on what would be required just for the fun of it; over at DigiKey the best price I found in single quantities is $65 for a 1GSPS ADC. Read the datasheet for that and found it needs 650-700MHz clock which is out of the question. It was an interesting thought experiment; but not something I will consider for the 50-100x difference in resolution. 

Have not found my stock of wire, but did recover enough to complete the next build. I also can't find any more  BC547 transistors to drive the buzzer, so I had to order another bag. I tried everything else I had in stock but nothing was suitable. These are also the very loudest transistors I've tested; so I didn't put much extra thought into the matter. The hardware, once the battery issue is resolved is basically complete now. I did add a few capacitors to the final BOM; but my total is still something like $14 a unit if you don't include the battery cost. Prices for those parts are $3 for single 4 hour battery, $6 for 8 hour pair; and $7 for 27 hour 18650. If I could buy more boards now, that choice would be obvious; the charger already supports the big battery. These initial prototypes will unfortunately have lesser specs.

I decided to update the CAD drawing one last time. This one has the bumped encoder position to allow for the larger 18650 battery. It also depicts all of the final button locations (for current builds) and the USB port. Finally; grills for the three input devices that will be included in a final version are drawn. These initial test units might only have two of those three audio inputs depending on how things fit in the poorly designed interior layout. Centering the rotary encoder in those initial designs seemed like a good idea at the time; but proved otherwise. I also didn't need any of those extra tact switches I had in the initial build. Red is the power up/wake up button. Blue is the front panel switch, actuated by pressing on the case anywhere in that corner or face; pressing the screen works just fine. Pushing down on the rotary encoder is other user switch. I presume Blue will be the go button; but Go is also a menu option; so I'm not sure exactly how my layout will work in the end. As I spend more time with these builds I'll decide for sure. That's entirely configurable in software of course. 

Assuming I have enough free time; I should be able to release at least one of these into the wild in a week or so.

[Lane]

I pulled an all nighter working on the code because I didn't have any other pressing matters here. Got quite a lot done; and the device is unchained now. I had been doing all of my development in a demo loop for efficiency; and that has been fully disabled. The rotary encoder and buttons navigate the important functions, and allow the user to press "Go" and start recording shot times. One press of the encoder button cancels shot timing, writes the data to file and displays the times on screen. One more push drops back to the main menu with "Go" selected again. The shot timer screen can also timeout by itself or with a program as needed. This is simply the "infinity" mode that isn't going to be available to users outside of running debug mode. The shutdown command puts the unit into deep sleep, which should allow the battery to last for months; red button powers it back up.

Have a bit more work to do processing button presses for every single menu item and mode. It also support holding the button for a long press; but nothing is using that particular feature yet with either input button. I've begun to revisit the shot course programming webpage again. It now streams the file to avoid running out of memory when generating the enormous amount of HTML required. It's still not perfect but I can get 24 shooting stations with some reliability, and occasionally better than 40; my goal here was 127 so I'm making progress. It might simply need to be closer to my WiFi access point for a higher data rate; I am testing at the other end of the house right now.

I ran yet another battery down and nothing I did would make it charge in circuit. The voltage was 2.82v the next day; so it didn't discharge it too far. While I was screwing around with all that; I had an epiphany... Why complicate sht with complicated shiit?!?? Two AA batteries fit inside the case; and would remove the need for the lithium battery charger board. Should get better run time too. The only thing I'm not absolutely sure about, is how efficient the DC/DC converter is in that voltage range. I'll hook it up on the breadboard build and test the idea later on.

Code is currently at version 0.93; should be fully functional by version 1.0, or maybe 0.98 if I'm lucky. Anyway; not too much longer on this project. Still have to wire up a motorized trickler when those new scales show up (should be any day now). Also turn out some solid copper projectiles on the lathe just for the fun of it... Then I can close up this thread.

[98Z5V]

12 hours ago, Lane said:

Why complicate sht with complicated shiit?!??

 

There we go...  

[Lane]

Transistors showed up, so I can finally finish hardware builds with an amplified buzzer. I got the WiFi/webserver to toggle on and off without crashing the microcontroller; and the credentials are stored in the settings file (not hard coded anymore). I'm pretty much down to course programming and populating a few more settings menus with actual values. Both of those items are nearly finished but I had been trying to make everything as efficient as possible. I had been stressing over the course length differences per page; but as I sat here writing this I realized I can simply use separate files for each page. That eliminates the need to preserve the rest of the programming file when editing, since there is no way to reliably insert data in the middle. I can only add to the end, or rewrite the file completely.

I tested out the fast timing mode (no display during shot timing), and got it down to 125us per sample. Looks like the theoretical maximum is closer to 5us per sample, so I might be able to go deeper. Quite frankly I'm just fine with an eighth of a ms for the time being. I haven't retested this with the WiFi off, or reviewed my button polling code to see how far it can go yet. Screwing around with all that I had to change all my timing code to measure microseconds instead of milliseconds; that made my shot file size balloon quickly. I rewrote the format of the file and currently drop the 1/8th microsecond difference. I can fix that easily; but I haven't yet figured out how to insert decimal point in an elegant way. The extra 1/8th to 1/10th microsecond only comes in to play with this fast timing mode anyway; so I may need to simply write a separate format just for that data. 

Finally got around to testing the AA battery runtime (with old code for comparison to the other times). At first I thought all my DC/DC converters were toast because it wouldn't power my breadboard build. Turns out something in that mix draws too much power. The new style module with display runs just fine; but stopped running when I wasn't paying attention. Something less than 15 hours of constant run time on a pair of 2200mAh NiMH AA batteries.

[98Z5V]

You've got WAY MORE tech and functionality built into this little beast, than any other shot timer out there - this is cool watching this all progress!!!  

[Lane]

2 hours ago, 98Z5V said:

functionality built in

That was honestly the easy part of this build. I used to live with a guy who loved shooting shotgun courses when he was younger. I can't tell you how many times he told those stories; but they certainly stuck with me. I crafted the functionality out of the possibilities I could image being important. I also read reviews of other products to see what those users DIDN'T like. Minimizing the input was also a design choice I think will help make it easy to pick up an use without a manual. It works much like an old iPod in terms of control simplicity.

Pretty burned out after finishing most of the programming webpage. The last thing to do is parse the data back into the HTML form from a text file when the page first loads. I'm not sure how much further I can go; but I was able to post 30 stations over a slow WiFi connection. I may be near that limit depending on how much POST data I can send in real life. Some other users complained about 2k being a limit; and I'm getting close to that. I can live with 32 if that turns out to be an issue; you could create (presumably 127) pages of 32 station courses in that case. Here is a screen shot of that config page which is basically finished. The actual post data has very short identifiers to save on transfer size. Hybrid timing of either shots or time is now included, as well as a text course name to display on the screen.

Turns out the fast timing mode can still display things on the screen; they just don't update in real time. It seemed weird if the display went completely dark while the unit was running... In my current build I just drew some rectangles before turning off the display writes for fast timing mode. Should be able to draw the normal display one time just the same; and update once again between each station. I'm not even going to try to write display updates while the shot rings out; that can wait for a future update.

Maybe one or two more brutal coding sessions left. 

[98Z5V]

HOLY SHIIT, LANE!!!  

[unforgiven]

Brother Lane you are a brilliant

[washguy]

45 minutes ago, unforgiven said:

Brother Lane you are a brilliant

AMEN  !     Wash

[Lane]

Ran into a brick wall last night, and hadn't been re-versioning my code much. Found a hard crash when scrolling the menus for no apparent reason. The last version that worked perfectly was 36 hours old. Copied and pasted the functions from old versions, and still couldn't make it work. Even after sleeping; and using the undo command ad nauseum, I had no resolution.

I had been running around with a baseball bat inside my code to clean things up; which is what brought about this problem in the first place. Even broke the button delays I had programmed a while back too because the main loop was running "too fast". Button presses were showing up as long button presses instead of a short because everything is faster now. The menus didn't look as smooth after clocking up to 160MHz; so I wanted to revisit that before finishing out those last bits of the user interface. I thought it would be more fun to test when everything was animating smoothly... The thing that pissed me off the most was; the menu display function is only 70 lines long (first loop setup, string array designations, context updates, scrolling animation; and display writes, all in 70 lines of code). I was all over the place trying to turn things on and off as there aren't many options to begin with. 

I needed a debugger; which took a few hours to download and install. The answer was malloc; I already fing knew it was a malloc from the exception code. I threw a dart at the wall after seeing a pile of 0x00000000 in the memory read operations, and found an array that used to work just fine; but was reading memory out of bounds. These string arrays are used to display any and all menus on the system; and have been working for weeks now.  In hindsight, I have no idea why it ever worked; but I'm actively pushing the limits of the hardware from every direction now on purpose.

This current version; 0.9.71 again works smoothly and is reliably. There are too many fixes and updates to list right now. I need to upload a full set of fonts; since this current install only has a few sizes between 8-16 (for those with poor eyesight). Also need to rework all the x,y positions of string writes to the display to support multiple font sizes. In testing that earlier code, I had some funny glitches where I turned off a font size change in one place, and some other display function looked all wrong. Simple to implement once I start testing; code calculates font height in a number of display functions already. I can upload any font I want; any votes for small pixel readable fonts? I doubt I can fit more than one or two.

I ran in to one glitch when testing broken code where the screen wouldn't update at all. The soft reset button doesn't short out the power source; and wouldn't kill the power to the display. Since I have a "built-in" lithium battery on this unit, I will need to drill and wire a battery interrupt reset button. That was the only way to fix the display without killing the battery; which I still can't recharge inside afterward (complicated poop with complicated poop right there)... The DC/DC converter I'm using is certainly flakey. The AA battery test has issues starting up the first time with the same module; but at least those batteries would be removable to glitch start a unit. Latest 2xAA test is at 9 hours and running; hope I can catch it around the time it shuts off.

I don't think I mentioned. There is actually a newer chip in this family that is "better"; and has bluetooth. I just didn't see a reason to go bleeding edge the first time around (for all I know there are 2 or 3 new ones). Looks like those ultra fast 0.005ms reads won't be possible without the FAST ADC function available through the native SDK; but that's installed now. Should be little more than a copy/paste to compile that way in the end; thanks to that GDB quest of course.

[Lane]

Not much of an update; but the AA battery test came out to 10:49:50; so a hair under 11 hours running non-stop. I would call that good enough; and expensive lithium AAs would likely last even longer. I'm not 100% sure how to mount the batteries in this current type of case. I'm considering cutting access holes and epoxying battery holders to the two bottom edges. I could also drill two holes in the end, but would have to fabricate some kind of door for that to work out. I could just stuff them in the box like my current build; but then I would need to add a different kind of charging circuit to the mix which I don't have on hand. 

I added a highlight to the currently selected menu item. I also added display writes to the loop when a shot is heard since it doesn't impact performance. The rotary encoder now enumerates one click per mechanical detent. It outputs two cycles for every detent so I had to filter one out. The shot timing display screen is still a little sloppy; but I will work on that more now that it writes updates in fast timing mode. I have been considering a vertical display mode; but won't likely approach that right away. That is the kind of that that can be fixed in software alone; but adding an accelerometer in hardware isn't out of the question either. 

[Lane]

I shopped around for chronographs today and was kind of disappointed by the specs on everything but the doppler radar unit. After looking at building my own doppler radar unit I came across someone else who built an optical unit with a 24" separation for accuracy. Cheap commercial optical units are +/- 0.5%-0.25% accuracy; that's not enough to test powder charges at the single kernel level. I figure if I build one on a 10' 2x4 with reasonably accurate measurements I could get close to what I need to measure single FPS in a load. I'm not going to be buying a commercial unit based on the stated accuracy right away. I may need one later to compare my results though; and that is most certianly going to be a doppler unit. 

I'll order up a cheap doppler radar module and see what happens; but I doubt it will work at all. Wouldn't be sad if it worked mounted at the end of my barrel though. Those magnetic chronos look kind of neat; and claim accuracy. But really; that's nothing more than strapping special electric guitar pickup to the end of my barrel (with a dumb microcontroller of course).

[Lane]

I had written some shot peak detection code very early in this project; and it showed up again in my recent debugging. Turns out that it works really well if I use it correctly. I should be able to use that to hone in on the actual shot instead of the audio trigger time. Then I could calculate a few extra variables like distance and tune my results. I also analyzed the audio file from my original .308 recording, and saw about 20ms of loud sound. All of that is going to need some further investigation but I think I can prove out some pretty sick resolution with this unit.

I still need to test things like subsonic .22lrs (they don't cycle my CMMG BCG).  I also have no access to a suppressed firearm; but in that case, you should be able to velcro the unit to the barrel. 

I appreciate all your help and support along the way. All of you around here. Somebody has my .308 headspace gauges by the way... What's up with that?

[Lane]

Had to use what I have on hand for this first build. This nail polish was a reject when I was told to go buy nice colors. Maybe next time I'll choose blueberry...

Turns out there is some nice temperature sensitive paint in the house. I'l be sure to paint this second build buttons with those choices the next time around.

There is also a new "icon" in the bottom right corner to indicate when you can press on the screen.

After the lady in the house tested the unit, it became clear that I needed to bone up on the UI.

Who doesn't think this will make spring shoot?

[98Z5V]

36 minutes ago, Lane said:

Had to use what I have on hand for this first build. This nail polish was a reject when I was told to go buy nice colors. Maybe next time I'll choose blueberry...

 

Never go Blueberry, brother - there's a LONG INSIDE story on that,but you DON'T want Blueberry!...  

[Lane]

4 minutes ago, 98Z5V said:

DON'T

You don't know what I don't know; and I don't know what you don't know either. True or false?

[98Z5V]

3 minutes ago, Lane said:

You don't know what I don't know; and I don't know what you don't know either. True or false?

You just entered the OODA Loop...  

Edited February 8, 2019 by 98Z5V

[Lane]

I don't know what you mean; but I've been looping for decades. 

Does blueberry touch? Or can it touch blueberry? Is that more like an out of battery experience?

[Matt.Cross]

Time for a hard reset, somebody divided by zero.....

[Lane]

 

11 minutes ago, Matt.Cross said:

divided by zero

I don't think it was a div 0. I've never done that in this code. Out of bounds maybe?

[Matt.Cross]

1 hour ago, Lane said:

 

I don't think it was a div 0. I've never done that in this code. Out of bounds maybe?

I was referring to the sudden shift in the thread, my reasoning was that the random erratic output must surely be the result of a computational anomaly.

[unforgiven]

13 hours ago, Matt.Cross said:

I was referring to the sudden shift in the thread, my reasoning was that the random erratic output must surely be the result of a computational anomaly.

Why does it sound nasty when you say it.