Show Posts
Pages: [1] 2 3 ... 8
1  Using Arduino / Project Guidance / Re: Smallest way to play a short sound effect? on: September 05, 2013, 10:03:05 am
The SimpleSdAudio sounds perfect. I don't mind doing a conversion since it's only one sound I'll be doing and I'm not swapping things out on any regular basis.  I'll give it a test this weekend. It must be resource intensive, so I'll see if I can still do the other things (fob and strobe) at the same time. I'll also pop into my local store to see if I can find a cheap/small battery powered speaker by then.

Thanks for the help guys.
2  Using Arduino / Project Guidance / Re: Smallest way to play a short sound effect? on: September 04, 2013, 07:41:03 pm
Those sound like good suggestions, I might try both to see which turns out better. If I need more sound, what would be a good amp/circuit to use considering size a factor? I used the waveshield in a previous costume, but it ended up being way too quiet for what I needed.
3  Using Arduino / Project Guidance / Smallest way to play a short sound effect? on: September 04, 2013, 01:34:27 pm
I'm helping with a TARDIS costume (from Doctor Who) and I want to make the light bulb topper for a headband. These are my goals:

  • As small as possible. It's going on a headband afterall.
  • Play a short sound clip (5-10 seconds or so) when activated.
  • Fade on and off a set of leds when activated.
  • (Optional) Activate via nordic radio. I've used a nRF24L01+ with the nordic fob from Sparkfun before. It's easy enough to add, but I'm willing to go without it (use a button) if it conflicts with something else.

The part that I'm really stuck on is playing the clip. I've used things like Adafruit's wave shield before, but it seems a bit much (and large) for only one little clip. I've considered using the radioshack recording module: http://www.radioshack.com/product/index.jsp?productId=2102855 or tearing part one of those record-your-own greeting cards. Is there a better way? Some easily interfaced chip made with this in mind?
4  Using Arduino / Project Guidance / Re: 5v voltage regulator with lowest quiescent current on: March 01, 2012, 09:02:41 am
Thanks!  I'll give that a shot, see how things run.
5  Using Arduino / Project Guidance / 5v voltage regulator with lowest quiescent current on: March 01, 2012, 12:24:21 am
Does anyone here have a suggestion for a 5v voltage regulator that accepts car voltage (13.9v-14.4v or so) with as little energy wasted as possible?  Linears are out.

I'm trying to power an atmega328 and very little else (a couple of transistors and a couple of small leds) from a car, and I'm trying to find the best regulator to use.  My first board used an Arduino Nano as the base, and thus the linear regulator that it uses (TI UA78M05CDCYRG3).  I found that it consumed 23mA while the chip was on.  My next board (bare chip) used a LMZ14201, and used only 8.4mA while running, and 1.40mA while the chip was in sleep mode.

I'm very happy with the LMZ14201, but it's a bit much for my needs (1A capacity), it's relatively expensive ($13 + 10 more components, ceramic caps and resistors), and its footprint has a pad underneath which is a pain.

The MC34063A is a popular switch mode chip, but it requires electrolytic caps, which I would rather avoid for longevity purposes.  (Feel free to tell me if I am I being silly here.)

Does anyone have a better suggestion, or am I stuck with the dilemma of: Cheap, efficient, long lasting. Pick two.
Cheap, efficient: MC34063A
Cheap, long lasting: any ol' linear
Efficient, long lasting: LMZ14201
Cheap, efficient, AND long lasting: ???
6  Using Arduino / Project Guidance / Re: Using jumpers, good practice or better alternative. on: June 23, 2011, 01:25:37 pm
Alright, thanks.
7  Using Arduino / Project Guidance / Re: Using jumpers, good practice or better alternative. on: June 23, 2011, 01:09:12 pm
Exactly what is your application here?

I'm simulating a door-lock button press on the driver's door of a car.  I'm not directly driving the door locks, just signalling to the car in the same way as the button on the door does.  On my first car, the physical switches in the door closed the same two pins on the wiring connector together with different resistors.  My board tapped into these wires in the door, using the same value resistors located on my board.  I suppose I could look at the max ratings on the lock button, but I doubt they are driving much.  My first board used the above mentioned MOSFET-based SSR flawlessly for about a year before the car got totalled.  (Link: http://www.arduino.cc/cgi-bin/yabb2/YaBB.pl?num=1236735887/15)

I'm not saying that they are the best thing to use, but they seemed like the best to me considering my limited electrical knowledge.  If anyone has a better suggestion, I'll gladly listen and read up on whatever topic I need to to better educate myself/make the board better.  The thing to take away the most is that I don't know how every single car's door controls work, so I want something that will switch any type of signal no matter the direction of current.  Size is important, and no moving parts would be preferrable.  Again, I don't think that any modern (OEM!) door lock controls directly drive any door lock actuators, no I don't expect a lot of current, but I admit that this is an assumption.

Changes I'll be making from my original board linked above:
  • ATmega328, power regulation, and supporting components will be integrated into the board, no third-party boards used.
  • LED backlight will be driven from transistor instead of expensive SSR.
  • Board will be designed to be more universal, though will not be designed to accommodate security systems of any type.
8  Using Arduino / Project Guidance / Re: Using jumpers, good practice or better alternative. on: June 23, 2011, 07:19:28 am
I wanted to be able to switch a potentially unknown signal, most likely dc, but be indifferent of the direction of current.  Would an SSR be bad practice in this situation?  If so, what would be a better choice?

Edit: I think it was an AQW212A that I used on my first board.  Link here: http://www.mouser.com/ProductDetail/Panasonic-Electric-Works/AQW212A/?qs=sGAEpiMZZMtLEhJ5P%2fNsZx%2fVqDTYcQwamYMh1RNGSig%3d
9  Using Arduino / Project Guidance / Re: Using jumpers, good practice or better alternative. on: June 22, 2011, 05:24:06 pm
Oops, brain-malfunction.  I meant SSR, solid state relays, as mentioned in my prior post above.
10  Using Arduino / Project Guidance / Re: Using jumpers, good practice or better alternative. on: June 22, 2011, 07:40:01 am
Ah, I see.  Your method would not rely on a permanent jumper, therefore nothing to wiggle off.  Unfortunately, to have a software-selectable path after the SSD SSR, I can only imagine accomplishing this by having more SSDs SSRs on the board.  This will take up more space and cost more cash.  I believe they are the second most expensive thing on the board (after the power module).  I went with SSD SSR because I won't know exactly what I will be switching, depending on the car.

You're probably right about 'end-users' not actually setting this up.  I forget that most people who have things added on to their cars aftermarket (keyless entry, etc) don't actually know anything about doing it, and just pay a professional.  I'll be going with the solder-bridges then.  I'm not planning on turning this into a business venture, I'll just be doing this for myself and my dad right now (he already has one on his Lincoln, wants it on his Dodge).  But if a friend wants one, I want to be able to provide one without redesigning the board again.  Since I will be involved with each install, soldering will be fine.  The end result will not leave me worrying about it like the others would.  Thanks for all the input guys.

Edit: Typos
11  Using Arduino / Project Guidance / Re: Using jumpers, good practice or better alternative. on: June 21, 2011, 02:49:27 pm
End-user configurable, solder-bridges really hurt that.

My first board was custom made for my car only, all smd, no switches.  I'm trying to cut a compromise between being universal, not requiring end user soldering (except adding resistors when needed, no way around that, I imagine different cars need all kinds of different values) and longevity (no switches failing, jumpers falling out from door slams).

I feel like switches will fail, but jumpers can vibrate off.  What can be said for dip switch longevity?  At least I wouldn't have to worry about them falling off.

I would rather require the end-use of a soldering iron before I use a component that will fail.  I don't know how wet the inside of a car door may get.  Convenience is nice, but reliability is paramount.

I'm flip-flopping back and forth on this alot.

Solder-bridges require less space and less parts($), also most reliable.
Jumpers not very much more space, possibly vibrate off?
Switches more space, more money, but also more convenient for end users.

--- Board explanation below, optional, for those who want some context ---

Basically my board has two solid state relays, one each for lock/unlock.  My last car required me to close the *same* two wires together for lock/unlock, but through different resistances (330 ohm and 1K ohm).  My new car requires me to close one common wire to two different ones for unlock/lock.

I'm sure that there are other types that require something else.

So I want a jumper/switch/whatever to optionally link the inputs if they are shared (so I don't need a jumper wire on the outside), same with the outputs (independent of input setting).  On the output trace, there should be a spot to solder in an appropriate resistor.  I may want a jumper/switch to bypass this with a solid trace, or I could just solder in a jumper wire in place of the resistor.

---
12  Using Arduino / Project Guidance / Using jumpers, good practice or better alternative. on: June 21, 2011, 10:42:15 am
Hey all.  I'm redesigning my car keypad board (car was totalled, new car works differently) and I was wondering about the practice of using jumpers (like a hard drive or cd-rom has, not jumper wires).  I want to make this board more universally usable for different cars, so I need a way to bridge/reroute certain traces on the board after the fact.  This board is going into the door of a car though, so I wondered if anyone here could speak for their longevity with vibration and possible moisture.  If they are a no-go, what alternatives would you suggest?
13  Using Arduino / Project Guidance / Re: Touch interface through a windshield. on: February 04, 2011, 03:14:59 pm
My car already has an rf key fob.  What I am looking for is a way to get into my car without having anything on me, be it a key, card, ring, remote, or whatever.  As I said, I can always cut the hole again and implant the ford keypad into the door, but I was looking into other solutions for aesthetic reasons.  That, and re-doing my last project identically wouldn't be as interesting or as much of a learning experience.

I don't see why the ir method wouldn't work.  I might have to modulate the light in some way to reduce false positives from outside sources, that and the aforementioned frost issue.
14  Using Arduino / Project Guidance / Touch interface through a windshield. on: February 04, 2011, 12:38:04 pm
Hey guys, I'm looking into feasibility/best method of a touch interface that would work through glass, namely a car's windshield.

Background:  I like very much having a keypad on my car.  So much so that I added one to my last one the hard way.  I added a Ford keypad to my Dodge by cutting a hole in the door and handling the in-between with an Arduino. http://www.arduino.cc/cgi-bin/yabb2/YaBB.pl?num=1236735887/0  Unfortunately, I lost that car to a careless driver and now I need to start over on my new car.  My first thought was to just cut another hole, but honestly, I don't think the keypad would look quite right on the new car, too many curves.

So I was thinking about making a touch interface that I could mount on the inside of the windshield.  I would only need to simulate 5 buttons.  The two possibilities for this that came to mind are capacitive and ir sensing.  From what I've read, some of the capacitive touch sensors can sense through a small layer of glass, but I have my doubts about using it with the thickness of a windshield.  Also, I've read that not having a true 'earth' ground causes problems with these also.

My other option is (one or more) ir leds around an ir receiver, so that when you place your finger on the glass, your finger reflects back the ir, picked up by the receiver and interpreted as a button press.  The only downside to this is that whenever the windshield ices over (or just gets dirty) it will look like constant pressing.

A knock sensor would be neat (shave and a haircut, two bits!), but this feels too insecure for me.

Thoughts?
15  Forum 2005-2010 (read only) / Syntax & Programs / Timeout reoccuring due to millis rollover. (MOVED) on: March 08, 2009, 04:56:35 pm
(Moved because I posted in wrong area)

Hey guys.

I have a project that turns on a backlight when you press a button and turns it off after a time out.  Here's a snippet of the code:
Code:
void timeOut () {
if (millis() - lastPress > TimeOutTime) {
  digitalWrite(BackLight, LOW);
}  else {
  digitalWrite(BackLight, HIGH);
}
}

The problem I have with this is that when I first turn on the device, it will light because lastPress and millis() are both zero.  I corrected this by initializing lastPress as such:

Code:
unsigned long lastPress = millis() - (TimeOutTime + 1);

so that it's starts just after the timeout.

But even so, it will light up on it's own every 50 days or so if nothing's been pressed, due to millis() rolling over.  What is a good solution?  I keep thinking of routines that check millis() and move lastPress around, but nothing really elegant.

Edit:  I suppose a backlight lighting up on it's own for four seconds once every 50 days probably won't even get noticed, especially since its unlikely that it will run for 50 days without either having a button pressed or being reset.  But it does bother me so, does that make me crazy?

Edit 2: I got it.

Code:
void timeOut () {
if (millis() - lastPress > TimeOutTime) {
  digitalWrite(BackLight, LOW);
  lastPress = millis() - (TimeOutTime + 1);
}  else {
  digitalWrite(BackLight, HIGH);
}
}

This will make lastPress always follow millis() around just outside of the timeout, as long as it's already timed out.
Pages: [1] 2 3 ... 8