Any chance you want to release the shell for what you did?
Yes. My plan right from the start has been to put all the source up on GitHub, which is why I wrote it from scratch rather than basing it on an existing CMS. No license complications this way.
don't you even think about stealing that idea off me!
I think it's already been stolen, but not by me. I saw a spreadsheet on Google Docs or somewhere a couple of years ago that listed a heap of Arduino models (including derivatives) but I don't know where it is now.
Perhaps it makes sense to collaborate on it - I was just saying to someone on the weekend that I'm annoyed now that I picked a shield-specific URL, and it would have been smarter to do something that can cover both shields and boards. -- Jon
Great job with that list of Arduino hardware. You must be rather obsessive to do something like that, I have no idea why you'd go to so much trouble ;-)
Any chance you could add the TwentyTen to the list? To make it easy, here are the details in the same format you've used. As close as I could get in text, anyway:
Freetronics TwentyTen http://www.freetronics.com/twentyten Direct equivalent to the 'standard size' USB Arduino board Shield compatible. Through hole ATmega chip (can be easily replaced). Automatic input power selection. Several changes compared to the Arduino USB: * Prototyping area * LEDs relocated to the right edge for visibility when a shield is fitted. * USB socket shrunk down to mini-USB size.
@PeteAJ: What Graynomad's suggestion does is set the LED output pin level to match the BUTTON input pin level. Very simple and clear.
The "!" you see in my trivially modified version is a logical "NOT" operator, which reverses the logic so that instead of setting the LED output to the same level as the BUTTON input, it sets it to the *opposite* value. Since the button is "low" while pressed that'll give the effect of turning on the LED when the button is pressed, and off when released. -- Jon
Edit: Added in the second closing bracket that was missing from the copied / pasted code
I'm a bit confused about what you're trying to achieve. It *looks* like what you're wanting to do is have the LED change state on a button press, but what you've written won't achieve that. If you just want a simple "on while pressed" behavior, you could simplify your sketch to this (untested):
It may seem like the logic is inverted, but what's happening is that the internal pull-up on the BUTTON pin will hold that input high unless the button is pressed. So a LOW value on the button corresponds to a press, which is then used to set a HIGH value (illuminated) for the LED. -- Jon
Sounds like you've connected it so that the button shorts out the power supply! Could you post details of how you've connected everything together? A sketch or a photo would make it much easier for people to help you. -- Jon Practical Arduino: www.practicalarduino.com
Good observations there. I found the crystal / resonator combo interesting: the USB AVR gets a crystal, while the main MCU only gets a resonator. Sounds like USB timing issues are more critical than keeping the main MCU at an accurate clock rate.
The decision to run the USB AVR at 16MHz just like the main MCU is also interesting. Looking at the schematic it's almost like two Arduinos munged together! -- Jon
Hey @tehjrow, that's a cool project. It looks like you've got it pretty much working but I have a couple of suggestions for the next stages.
It would be a good idea to add a "door closed" sensor so that the controller knows when the door is physically open. You have a 10 second delay on re-locking, but if the door stays open longer than that it'll drive the deadbolt back out and the door won't be able to close. You could add a reed switch in the edge of the door and a magnet embedded in the frame so that the Arduino detects when the door has closed so that it won't try to re-lock prematurely. You'll need a tiny state-machine in your code so that it doesn't read the tag, unlock the door, then immediately discover that the door is closed and think it needs to lock it again right away: set a flag that trips if the door opens after the lock has been fired, and only re-lock the door if it closes again *after* being opened or the time expires without it opening.
Also, you mentioned in the video on your blog that you intend to mount the reader in a small project box on the outside of the door. That's what I've done with a couple of doors (well, actually, I had the reader mounted beside the door near the frame, not on the door itself) but one interesting approach would be to use a router to cut a square hole into the face of the door, mount the reader in it with the face almost flush with the surface, and then fill and paint over it so the reader is concealed. -- Jon Practical Arduino: www.practicalarduino.com
I also see you have an enormous capacitor after the diode on the 12v side of your circuit - why so big?
Ah yes, that's a bit of a trick. It's explained in detail in the book, but the short summary is that it holds the output high for long enough for the Arduino to go through a managed power-down routine such as closing the logfile on the USB memory stick. It has one of the interrupts connected to a voltage-divider (protected by a Zener clamp) on the input side of the diode you mentioned which is there prevent the input-side cap discharging back into the loom when the power goes away, and the ISR forces the main loop to bail on whatever it's doing and clean up after itself. -- Jon
There are also voltage regulators specifically rated for automotive use that are designed to withstand the really nasty spikes that can happen in a load-dump scenario. There's a fairly extensive discussion on designing power supplies for vehicle applications in "Practical Arduino" in the "Vehicle Telemetry Platform" project.
I still haven't got around to putting the schematics up (sorry) but there's a little bit of info about the project here in case you don't have the book:
No, the antenna pin (pin 4) is connected to *only* the antenna, nothing else. You don't need anything connected to pin 2 on the Arduino for the transmitter. The transmitter is a serial device, so the only connections to the Arduino are the common GND, VCC, and the data pin. That's it. -- Jon Practical Arduino: www.practicalarduino.com
As @deSilva said, talking to a USB memory stick isn't something you'd want to do directly from an Arduino. There are host chips you can use though, like the VNC1L from Vinculum. It's available either as a bare chip or in a module that you can use in your own projects, called the VDIP1 and VDIP2:
One thing to keep in mind is that when people are talking about a "touchscreen" in the context of something like a Nintendo DS touchscreen, there's typically no actual screen included with it! The NDS touchscreen mechanism is a clear glass substrate with the layers of the touch mechanism built up on top of it, and that assembly is then fitted over the top of an LCD so that you can see the LCD through it. It's not part of the LCD itself though. You can see an example of a NDS touchscreen being used without an LCD in this video:
In that video you can see I'm just holding the "touchscreen", but there's no "screen". So ...
If the input surface of the touch screen is exposed underwater, is there any methods to counteract the ~9.5 pounds of force?
... you could just mount the touchscreen assembly onto a flat sheet of some suitable material (strong plastic?) on the outside of the submersible and seal around it with silicone. It would end up something like this:
I really suspect you're going down the wrong track here. My suggestion is to use an LCD behind a bit of perspex for visual display, and track down some waterproof push-buttons for menu selection. It'll be much simpler and more reliable than trying to make a submersible touchscreen.