Glorified data logging
Sgt. Zim
Posts: 3
Wow, my first post here. 
Preliminaries: I hate stupid questions, so I hope that these aren't ... Stupid, that is. Secondly, I'm new to digital electronics and microcontrollers; I'm a software guy, my hardware experience is routers and switches, and pulling cable. That said, I've worked through the What is a Microcontroller book, and I think I have most of what I need to do worked out, but I have some detail questions, and a high-level question. So, the big question first: Is this going to be more complex than I think, or is this a workable project for educating myself in this stuff?
On to my project. Here's a basic requirements doc I've written for myself. (No, this is not a homework assignment).
is a shot timer?" In many competitive shooting disciplines, scores are based on time and accuracy. At its simplest, a shot timer is a stopwatch with a microphone. When the shooter indicates that they're ready, the timer operator pushes the start button on the timer, which then emits a buzz. At the buzzer, the shooter draws and engages the course of fire. Each time the microphone picks up the sound of the gun firing, the display is updated to indicate the time elapsed between the pressing of the start button and the last shot fired. Officially, timing for the stage stops after the last round is fired (in other words, re-holstering at the end is not part of the stage time. Pressing the start button resets the counter and timer, fires the buzzer, and starts the process over again.
For usefulness, it's important to be able to review the string, but long-term storage is not important. As I mention in above, 5 minutes is a reasonable maximum. The average "stage" will be done in 30-90 seconds, depending on discipline and the shooter, but problems, jams, etc, and shooter (lack of)skill can push that up to 2-3 minutes, or more, and some stages in some disciplines can be done as fast as 10-15 seconds at the grandmaster level. The fastest humans on the planet can get splits (interval between shots) in the .12 second range, so .01 second accuracy is important.
Initially, I don't see long-term storage, or the ability to read the data to PC as necessary. I do see the ability to store and retrieve as useful for version 2, because it can be handy as a training aid, but most of the time, variables will be stored in RAM. Because of the number of writes necessary, I don't think EEPROM is appropriate, except in the case of a "store this string for later" function (version 2). I'll shoot 300-500 rounds in a practice session. For a timer used to score a match, 3000 rounds over the course of the match is not unreasonable.
So, there's one of the rubs, and my first detail question. How should I count? The thought that keeps sticking with me is some sort of tick counter, say 1 tick per 5ms, and a 2-byte counter. That would allow for 327.68 seconds. To allow for the "history" function, and splits, I'm considering storing each shot as a delta from the previous shot, rather than time from zero for each shot. The problem comes from the fact that, if all goes well, for the average shooter, the delta will be .5 ≤ Δ ≤ 2 (~1) second, but if any movement is required, or if the shooter suffers a jam, or is just not that skilled, limited mobility, etc ... it may be closer to 20-30 seconds or more. In short, a delta may need to be 13 bits or larger (12 bits = 4096 * 5ms = 20.48 sec before the counter overflows). So, optimum might be 4 bytes for the timer, plus 40 * 2 bytes = 80 for the deltas = 84 bytes... With careful packing, I could get it down to 68 bytes, but I fear the performance hit would be huge, and I'm still 4 bytes over what the BS2e could give me. So, how hard is it to interface with extra RAM? Edit: I just realized that I forgot the nibble needed for the actual shot count.
Wow. This has gotten long.
The next issue would be timing, and I think I know the basics of the answer. Would it be realistic to count on "this loop takes 5ms to execute, so I can increment my tick counter for every pass through the loop" for accurate timing, or should I plan on some external source? (Something 555 based?)
Still have the issues of interfacing the LCD (seems to be well-documented, shouldn't be a problem) and the microphone (same story), so I'll leave those for later. Plus, I'm at work and should be working. However, it's late on the Friday before a long weekend.
So, any thoughts? Too big of a project for a n00b? "Put down the crack pipe, son, and try this instead?"
Thanks
Preliminaries: I hate stupid questions, so I hope that these aren't ... Stupid, that is. Secondly, I'm new to digital electronics and microcontrollers; I'm a software guy, my hardware experience is routers and switches, and pulling cable. That said, I've worked through the What is a Microcontroller book, and I think I have most of what I need to do worked out, but I have some detail questions, and a high-level question. So, the big question first: Is this going to be more complex than I think, or is this a workable project for educating myself in this stuff?
On to my project. Here's a basic requirements doc I've written for myself. (No, this is not a homework assignment).
So, now, you're saying to yourself "what theI said...
Problem: Create a shot timer/counter capable of recording each shot in a string of fire, and its time differential from the start.
The timer should be operated mainly by means of a "start" button; pressing the "start" button should sound the start signal (a buzzer) and begin timing. At each shot, the display should be updated with the shot number and total time of the last shot. Shots should be timed to 10ms (0.01 second). Shots are "counted" by means of an audio input (the sound of the shot).
Additional features with later versions should include, but not be limited to: shot review (including "replaying" a string, splits, 1st shot time), adjustable start signal delay, adjustable microphone gain, echo/bounce adjustability (for confined ranges). Date/Time, battery condition and auto power-off are considered desirable but far from necessary.
Inputs: Start/Reset button, audio pickup (microphone). Additional buttons to be added as necessary with additional features (likely minimum to include up/down scroll buttons). The interface should be kept as simple as possible (not too many buttons, but not too many three-fingered salutes, either).
Outputs: Buzzer, LCD
Additional Specifications: The timer should be able to count up to 300 seconds and 40 shots for the string (at a minimum. The more the merrier, within reason and the limits of memory).
is a shot timer?" In many competitive shooting disciplines, scores are based on time and accuracy. At its simplest, a shot timer is a stopwatch with a microphone. When the shooter indicates that they're ready, the timer operator pushes the start button on the timer, which then emits a buzz. At the buzzer, the shooter draws and engages the course of fire. Each time the microphone picks up the sound of the gun firing, the display is updated to indicate the time elapsed between the pressing of the start button and the last shot fired. Officially, timing for the stage stops after the last round is fired (in other words, re-holstering at the end is not part of the stage time. Pressing the start button resets the counter and timer, fires the buzzer, and starts the process over again.For usefulness, it's important to be able to review the string, but long-term storage is not important. As I mention in above, 5 minutes is a reasonable maximum. The average "stage" will be done in 30-90 seconds, depending on discipline and the shooter, but problems, jams, etc, and shooter (lack of)skill can push that up to 2-3 minutes, or more, and some stages in some disciplines can be done as fast as 10-15 seconds at the grandmaster level. The fastest humans on the planet can get splits (interval between shots) in the .12 second range, so .01 second accuracy is important.
Initially, I don't see long-term storage, or the ability to read the data to PC as necessary. I do see the ability to store and retrieve as useful for version 2, because it can be handy as a training aid, but most of the time, variables will be stored in RAM. Because of the number of writes necessary, I don't think EEPROM is appropriate, except in the case of a "store this string for later" function (version 2). I'll shoot 300-500 rounds in a practice session. For a timer used to score a match, 3000 rounds over the course of the match is not unreasonable.
So, there's one of the rubs, and my first detail question. How should I count? The thought that keeps sticking with me is some sort of tick counter, say 1 tick per 5ms, and a 2-byte counter. That would allow for 327.68 seconds. To allow for the "history" function, and splits, I'm considering storing each shot as a delta from the previous shot, rather than time from zero for each shot. The problem comes from the fact that, if all goes well, for the average shooter, the delta will be .5 ≤ Δ ≤ 2 (~1) second, but if any movement is required, or if the shooter suffers a jam, or is just not that skilled, limited mobility, etc ... it may be closer to 20-30 seconds or more. In short, a delta may need to be 13 bits or larger (12 bits = 4096 * 5ms = 20.48 sec before the counter overflows). So, optimum might be 4 bytes for the timer, plus 40 * 2 bytes = 80 for the deltas = 84 bytes... With careful packing, I could get it down to 68 bytes, but I fear the performance hit would be huge, and I'm still 4 bytes over what the BS2e could give me. So, how hard is it to interface with extra RAM? Edit: I just realized that I forgot the nibble needed for the actual shot count.
Wow. This has gotten long.
The next issue would be timing, and I think I know the basics of the answer. Would it be realistic to count on "this loop takes 5ms to execute, so I can increment my tick counter for every pass through the loop" for accurate timing, or should I plan on some external source? (Something 555 based?)
Still have the issues of interfacing the LCD (seems to be well-documented, shouldn't be a problem) and the microphone (same story), so I'll leave those for later. Plus, I'm at work and should be working. However, it's late on the Friday before a long weekend.
So, any thoughts? Too big of a project for a n00b? "Put down the crack pipe, son, and try this instead?"
Thanks
Comments
The Dallas Semiconductor DS1302 contains 31 bytes of RAM and a calendar/clock counted off in seconds. It's easy to interface to a Stamp and there are plenty of examples of its use with a Stamp.
This would free you up from any concerns about timing since you just have to read the DS1302 when you detect a shot and store the time in a table in EEPROM using the READ/WRITE statements. Storing the shot information in EEPROM avoids the crunch of trying to pack everything in a few bytes of variable data. You're not going to be updating the table often enough to worry about wearing out the EEPROM locations since they're good for more than 100,000 writes, that's every second for 30+ hours at a minimum
In terms of the complexity of the problem ... Tackle sections one at a time.
1) Detecting the shots
2) Managing the DS1302 if that's what you use
3) Handling the display and buttons or keypad (consider a 16 x 16 keypad for control). Some LCD displays also can handle scanning a keypad or consider using a MemKey to handle it for you.
4) Making it easy to use.
- storing the data in RAM seems like a poor use of finite variable space. Writing to EEPROM is easy, and you can get an external EEPROM chip for < $2. This would let you write huge amounts of data, you don't have to worry about burning out Stamp EEPROM with multiple writes, you can remove the EEPROM chip to dump it's contents at home, and more importantly in the case of a Stamp reset (say, low battery power) you won't lose any data
- I'm not quite following why you need .01 sec. resolution if the fastest splits would be .1 sec or so? But it's Friday after a long week, so maybe it's just me
- precise timing on the Stamp is tricky at best. You may want to either generate an external time count, or you might want to consider using an SX. The SX would be much faster, would let you time precisely, etc. The learning curve there might be steeper, however.
- here is a circuit for detecting sound levels -- with some tuning, and given how loud a shot would be compared to ambient noise, this would probably work well for triggering that a shot has occurred -- http://forums.parallax.com/showthread.php?p=572182
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
When the going gets weird, the weird turn pro. -- HST
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
When the going gets weird, the weird turn pro. -- HST
A very fast chip like the SX would work better, since it can accomplish multi-tasking, but the best choice for this would probably be the Propeller. It has 8 fully independent processor cores (called cogs), so you could dedicate individual cogs to the various tasks - 1 for buzzing, 1 for input, 1 for output, etc.
Like Sgt. Zim, I am a shooter. I shoot benchrest pistol. (The sport--benchrest pistol--almost does not exist.) I can easily shoot 500 rounds per session and have many, many sessions per season. For me, this amounts to about 1500 rounds a WEEK from the time the temperature is above 50 degrees until it drops below 50 degrees here in Kansas. More than six months, usually. (It is not that I am a pansy, although some may debate that, it is that the 12" bull barrel on my pistol will not warm up evenly if the temperature is much lower than 50 degrees.)
Although I do not know much about·Sgt. Zim's sport, I think the rules promote pulling the trigger.
My point: I think an interface to a throw-away EEPROM might be better than writing to the microcontroller's EEPROM. Plus, it would be a lot more fun and that's the important part!
--Bill
ps Sgt. Zim, on the shooting forums, I am seal killer.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
You are what you write.
My bias is the Propeller for this kind of thing since it can do the A-D conversion for the microphone, make sounds, do it's own timing, and make coffee at the same time. On the other hand, with a little extra stuff like a 555 timer driven speaker to make the buzz and an external clock like the DS1307 (much better than the DS1302 if you're using a BS2p model with the built-in I2C commands), the Stamps would do fine. You just have to offload the work that the Stamp isn't really made for and let it do the controlling that it works well at.
Good point about using an external EEPROM. Even better would be to use one of the Ramtron FRAMs which look and work like an EEPROM, but write as fast as they can read (rather than taking 5ms) and won't wear out locations like an EEPROM.
Mike
Thanks for the hint on the Ramtron FRAM.
--Bill
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
You are what you write.
Can I get a time signal faster than 1/sec from the 1302?
Suppose Alice and Bob are competing. If Alice does her run in 23.85 seconds, and Bob does his in 23.92 ... Alice wins. I've seen matches determined by hundredths of a second; that kind of resolution is required.
I hadn't considered the single thread problem, but as Mike mentioned later, I should be able to use the stamp to trigger an external circuit for the buzzer. As for listening and polling the buttons, I'm hoping that the stamp runs fast enough to poll each input and still register the shots within .01 sec.
I definitely will look into the FRAM, that may be the way to go.
Bill: Specifically, I'm looking at this for USPSA/IPSC style pistol, Cowboy Action/Western Three-Gun, and other types of "practical" competition. And I hear you on the heavy shooting schedule. When I'm practicing like I should, I hit the range 2-4 days a week, and go through 3-400 rounds per practice session. I know of people that practice 5+ days per week, for 500 rounds at a time.
The basic concept is that each stage (6 to 12 stages in the typical match) presents some sort of "tactical" scenario; targets to be engaged in a specified order, often with movement between targets, reloads, and in 3-gun type matches, transitions between guns and types of guns ("three-gun" is generally defined to mean "rifle, pistol and shotgun"). So, your stage score is (depending on the specific game) some function of targets hit and time taken to negotiate the course.
There are commercially available devices that do most of the things I've mentioned, and they've been around for at least 20 years, so it can't be that complex of a problem. (I'm not really looking to "save money" or create a marketable product, just trying to learn stuff.
Okay, and another question ... Mike mentioned A/D converting the microphone signal, but I'm not sure that I need to do that. (Thanks, too, to Zoot for the link on the microphone article). Basically, all the microphone is "listening" for is the sound of the shot; as long as a sound impulse is above a certain (ideally adjustable) threshold, it should be counted. Basically, I'm picturing something that just pulses a pin high when a sound loud enough hits the microphone. Or am I underestimating the problem?
Thanks for all the great suggestions. Once I get home ("on vacation" this weekend), I'll start laying down some detailed plans, and I'll keep everyone posted on my progress.
Oh, Bill, I'm on many of the shooting forums, usually either as Sgt Zim, or if it's a Cowboy Action oriented board, I'll be Garrett Jax.
The DS1302 does NOT provide an external clock pulse. This is because the DS1302 uses three pins to communicate with it's host (Data, Clock, Enable). So it only gives you real time (date, hours, seconds) when queried. The DS1307 uses I2C for communication (only two pins) and so the the "extra" pin available on that model can be set to output a constant square wave pulse train for other purposes:
Both chips are basically the same functionally. What I was driving at is that you could use the constantly generated pulse train as constant reference for the tighter and faster timings without having to actually query chip for the "real time". Then you only need to query the chip when you need a true time stamp for your data logging, which it sounds like would be *after* you've determined your winner, etc. Does this make sense?
The comparator (first part) portion of the audio circuit I linked to would probably work for your purposes without the ADC -- you would just need a pot in there so you could adjust for an optimal level where it's guaranteed to trigger on a shot, but not for ambient noise, echoes, etc.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
When the going gets weird, the weird turn pro. -- HST