So what's the idea? Hard-wire all the input pins on the decoder to make sure all outputs are high, then PWM the blanking input to make the outputs do the same thing?
Hmm.... it might work. Try it Seems like the transistors will be manly enough to cope.
EDIT: I apologise for the video quality :p I have a much better phone these days.
I did a few "fake IED" prop things for airsoft and paintball games, but went over to 7-segment based displays as they're just easier and make for an ever-so-slightly more realistic counter-terrorist sim game. They're so cheap and simple you could stash loads of them all over the site and make it a real challenge to track down and defuse them all within the game time limit!
Have some code - I don't make them like this any more so feel free to do what you want with it (except make an ACTUAL bomb, of course). It's not the best bit of programming in the world but as you can see, it does work.
Code:
// Countdown Timer Version 1 // By BulletMagnet83 // For ATmega328 & Arduino
I use the LM2940 regulator on pretty much everything, but then all my stuff is 5V, 16MHz, so it makes sense for me to do that. If you had a 3.3V 8MHz setup then a single lipo/no reg solution would probably be ok just like Crossroads said.
I like using them because it also gives me inbuilt reverse battery cockup and short-circuit protection, and given I have been known, on occasion, to do some monumentally stupid things it's nice to have a bit of a safety-net
And if it was me, I'd use the CAT4016 chip to drive common anode ones. If you want to drive them directly from the arduino there's no reason you can't (as long as you follow a few simple rules so you don't burn out your I/O pins). Try googling for "7 segment common anode arduino" and see what it throws up.
Given their low cost I'd really REALLY consider using an LDO regulator when running from batteries. I wouldn't feel comfortable feeding any microcontroller-based project from an unregulated supply, even from batteries. It doesn't really add much complexity to the circuit
Another possibility would be to use a piezo element in some sort of padded pouch so it doesn't get punched to death Have one in the target area, and sample the signal from it with an op-amp circuit and the ADC of an arduino or whatever mcu board you happen to be using.
Then, have something in your program that will map that data to one of several discrete options, from featherweight to Hulk Smash, and output THAT data over your serial port to the computer. That's how I'd approach the problem anyway, it may not necessarily be the best but it makes sense in my head.
The LM386N is a good choice here. I messed about with them a bit, some years ago... easy to use, difficult to fry (as long as you don't deliberately abuse them). Google image search threw up about a million schematics to try, none of them are hard to build.
If I remember right there's a bit of wiggle-room in what devices consider a logic high/low. I don't think it HAS to be bang-on 5.0V, just above a certain threshold. I power my stuff using LDO 5V regulators and usually, unless it wants a lot of current, a PP3 battery (because I have hundreds of the bloody things), and it always ends up pretty close to the 5V mark
Yes, but not directly. You'll either need to use a PWM output and run that through a low-pass filter to get your voltage, or use something like a SPI/I2C interfaced DAC to do the job. Depending how much precision you want, I might be tempted to start with the first option as you only need a resistor and a capacitor
Even though the value stored in millis() rolls over after a certain length of time, you're only checking to see if it's increased by 1000... so it doesn't matter! It's not as if your code will drop dead as soon as it rolls over, it'll just start ticking over from 0 again and your other variables will stay how they were.
To print more than one number, just repeat that statement! The 7219 will latch it's digits so they won't change until you write something else to that location. I did have some example code somewhere, but I can't find it Sorry.
Ahh slight trail-of-thought fail in my original post The outputs from that circuit are supposed to feed into the CV input of one of the various voltage-controlled amplifier circuits I have coaxed out of Google - I haven't decided which one to build yet but the simplest one seems like a good place to start!
The one thing I can't figure out just by looking at the envelope generator schematic is whether or not the attack level will ALWAYS eventually go up to the maximum, or does it's max level depend on the peak voltage of the trigger pulse? Might be one of those "build it and see" things... if the output level is proportional to the input (e.g. for a very basic sort of velocity sensing on a trigger pad), then I'm in business. If not, then I'm stuffed and need something else.
What I want to achieve is individual Attack/Release controls for several channels of a drum synth (which, for many reasons including the fact I'm still a shitty coder, is leaning more towards being analog in nature), and also to provide a pitch EG where required. In my mind's eye I pictured having a board built up to host all the EG circuits, with the various gate outputs collected together on a header to go off to all the VCA/VCO control inputs.
This looks reasonably simple and buildable, and although I don't have any TLO74s I do have plenty of TLO81s which look like they might be a suitable substitute. Should I be looking at something else or is this circuit worth building and experimenting with?
Sorry for not actually posting a reply offering help, but would you mind telling me which LRF you have? I wouldn't mind getting one myself and having a play-around.
I've been doing a bit of research/work on the drum machine project idea I had a while back, and I'm trying to wrap my head around how best to process a wav file in order to dump it either into flash memory or, as is more likely, onto an old-style parallel E(E)PROM. I don't have a programmer yet for said ROMs but I can go shopping for one next payday - in the interim I want to test the files from the flash memory of one of the ATmega328's I have knocking around. A single sample is about 18.7kb, so one will fit
The general idea for a rough-as-guts test bed is to simply shove all the data out in parallel on PORTD or something, through a DAC and see what I get (if anything) on the other end. I'd rather have some idea if it's going to work before going equipment shopping!
So far, I have:
Wave files processed in Audacity and exported as RAW(header-less), unsigned 8-bit, 32khz mono. A HEX editor, specifically Frhed, which I have so far used for comparing the "normal" wav with the header-less one just for a look, and exporting the data as a hexdump text file.
What's the best way to get the compiler to take this data and shove it in flash memory as a great big array so I can read through it from my main program? I'm googling in another tab as I write this, but it's a bit hit-or-miss not knowing exactly the technical programming terms for some things.