First off the arduino could control those systems, but not actually facilitate most of them. The camera and intercom would need their own system then maybe you could turn them on and off. The arduino itself will not be able to handle a video or audio feed.

You're gonna want to do this one thing at a time. Figure out how to sound the alarm you want. Figure out how to turn on the camera and monitor, figure out the door lock. Then put it all together once you get all those things figured out. DO NOT worry about the project as a whole until then, there will be way too many things to work out for each part.

The only other advice I have at this point is to look in to an electric door strike rather than electric door lock. This way the door still operates normally but you can let people in if you desire. An electric door lock can either fail and lock you in or fail and let anyone in.

If cost is an issue why not buy a legitimate arduino and a bootloaded atmega328 and the few other things needed to take the project off of the arduino when done programming it so that it can be reused? I've made dozens of arduino projects and have only ever owned the one UNO board I started with.

I read that they purposely make them really stupid because they are targeting the truly gullible.

After you're done programming RX and TX dont need to be connected to anything. Reset is connected to 5v (through a resistor if you want to be able to reset). Keeping it pulled up to 5v keeps it from resetting randomly. The numbers of the chip (1-28) do not correspond to the pin numbers in the programming at all. You have to look at one of those diagrams to see which is which. For instance digital IO's #9-13 are chip pins #15-19.

If you uploaded blink, put it on a breadboard and connected the LED to pin 19, then that is the right idea. Make sure reset is pulled up to 5v. If it still doesn't work check your wiring. Go through the standalone tutorial again and check everything.

Yeah, the trick here is that the frequency matches the frame rate AND the shutter speed it very fast. You'd want to do this in the sun or with lots of light. In person, the water would not look like this. The speaker is only wiggling the hose, the camera gives it the still look.

If you did this with a regular North American camcorder you'd want 30Hz. You can do this with anything, even a ceiling fan would appear to do strange things if you filmed it at a high enough shutter speed.

http://en.wikipedia.org/wiki/Wagon-wheel_effect

I'm working on a bike computer to replace my really terrible Bell computer. I'm only doing simple speed, distance, Calorie stuff but I've managed to getting it running on a 3v coin battery and sleeping it at low enough power to not need to physically switch it off, the wheel rotating can wake it up. Unfortunately I finally wore out my graphic LCD running it at 5v during programming so now I'm waiting for replacement to finish this thing. As soon as I get it it'll be ready to go on an printed board and mounted to my bike, as wonky as it will look.

Running off a 3v coin battery probably wont work for you if need GPS. However if you could settle simply for distance then that would really simplify your project. REALLY simplify it. In fact I'd even suggest that you omit it at first simply until you have more of it worked out.

I'd also suggest using a reed switch instead of a hall effect sensor. That's what bike computers usually use. A hall effect sensor would be to tell you how far away the magnet is. But you only need to know when it is passing by. A reed switch will simply switch on as it passes by.

A bike speedometer that uses a Hall sensor and one magnet is going to be lame. Think how much you change speed in 7 feet.

I disagree, at just 10mph that's two updates per second. You wouldn't want it updating any faster, you wouldn't be able to read it.

Wow I just sat here and watched 32 episodes of that. Thanks for throwing me in that pit of wasted time!

Code:

byte timeEarlier = 250;
byte timeNow = 5;
byte timeDifference;
void setup(){
 Serial.begin(9600);
 timeDifference = timeNow - timeEarlier;
 Serial.println(timeDifference);
}

void loop(){
 
 
}

returns 11

That's the difference, despite the fact that the byte rolled over.

I think the point is, though, that as long as they are all unsigned longs, if millis() were to rollover. Then when you subtract timeEarlier from timeNow, it will rollover backwards and still give you the difference. The only thing that would mess this up is if you tried to subtract more than 49 days, then your actual calculation would "rollover". But like I said, I'm not worried about that. I'm only worried about millis() rolling over.

If your math is all done in the form of

elapsedTime = (timeNow - timeEarlier);  // add elaspedTime to add  rideTime summary
where timeNow is the stopped time, and timeEarlier is the time you started

and all time related variable are unsigned long,
then there will not be a rollover problem.

Ah yes, I get it, that makes perfect sense... I was just over complicating it. Thanks!

I am working on a speedometer and trying to keep track of "ride time". Below is my code for when the speedometer has stopped. Previously when it started, "time2" was set to the value of millis().

I am trying to make sure that the time is still added correctly if millis() rolls over. I know that "time" itself will not keep track of more than 49 days of milliseconds and that this code will not work if the speedometer doesn't stop for 49 days. "time" will likely be reset to 0 fairly frequently anyway. But the arduino will only ever sleep, not restart. So I do need to worry about millis() rolling over.

"time" is the millis() that I have tallied up. "time2" is the value of millis() when I started counting last. Both are unsigned longs.

Code:

 void (stoppedMoving){
    if(millis() >= time2){//if time has NOT rolled over
      time += (millis()-time2);//add the difference between time2 and millis().
    }
    else{////if time has rolled over
      time += (4294967295 - time2) + millis();//if millis() has rolled over, add the number of milliseconds before it rolled over plus the milliseconds since it rolled over.
      }//end if time has rolled over
      moving=false;
  }//end stoppedMoving

Will this work?

Thanks

Well now that we are dissing Arduino, allow me to add my gripes!

Yes, very good, but the design is good enough that they are selling tens of thousands. The good points are that it is aimed at the beginner market, the shields are a useful add-on, and it was an excellent decision to use the open-source g++ compiler.

Compare that to other boards where you have to buy their own (dodgy) compilers, or get a cut-down "beginner" version, and put up with an IDE that is so complex it's almost impossible to get a project up quickly.

Yeah I figure, maybe they weren't the best programmers or engineers but they did create the best, most successful beginner development board and IDE so there's something to be said about that.

I'm thinking that's the best idea unless there is something I'm missing. Which is likely.

It's just that's the way it's done in most examples, even the arduino default ones. So I figured there may be a reason.

Why do we use:

Code:

int led = 13;

instead of

Code:

byte led = 13;

If you would never need to define more than 256 pins, why use the extra space for int? Is there a reason?

Thanks.

I notice that both of these lines work:

Code:

boolean pressed = (digitalRead(3)==HIGH);

boolean pressed = digitalRead(3);

I would assume that the first is more correct unless HIGH and LOW were interchangeable with true and false in which case the second line would be a better way to write it.

Which is correct? or more correct? Can I always trust that second one to work?

Thanks