You could use a 16MHz HC49S crystal, and you'll also need a pair of 22pF caps (one to ground from each side of the crystal). Should work just fine, no reason the Arduino wouldn't like it. That's how most Arduino models work anyway.
--
Jon
Freetronics: www.freetronics.com

I've done it with standard blank electrical wall-plates in the past. Looks quite professional for a home-brew system! You can see a photo of one on this page:

http://www.practicalarduino.com/projects/rfid-access-control-system
--
Jon
Freetronics: www.freetronics.com

Since you're wanting to drive many simultaneously, perhaps a better approach would be to use external PWM drivers. That way the Arduino doesn't have to run in tight loops toggling outputs on and off at precise intervals, it can just push the desired values out to the PWM drivers and let them modulate the LEDs until the value needs to change.

Could you perhaps explain a little more what your project is about? It's hard to provide advice when the problem hasn't been fully explained.
--
Jon
Practical Arduino: www.practicalarduino.com

im considering making an intermediate board to stack on the Aduino and give 2 sets of headers meaning you can stack 2 sets of shields side by side

You mean like this?

http://www.liquidware.com/shop/show/DWX/DoubleWide+ExtenderShield
--
Jon
Freetronics: www.freetronics.com

Lack of SRAM. You're building a large (by Arduino standards) buffer to store the NMEA data, and it's all going into SRAM. Since you also have some large strings to print (which by default are also stored in SRAM) you're running out of space.

@Groove's suggestion is to move those strings from SRAM and store them instead inside the ATmega's Flash memory, which you can do with the pgmspace library:

http://www.arduino.cc/en/Reference/PROGMEM

If you have chunks of unchanging data (like output strings that don't change at runtime) using PROGMEM will let you free up some SRAM.

--
Jon
Practical Arduino: www.practicalarduino.com

Arrays really do make it easier to associate disparate objects

Absolutely, I agree, but based on the way the original question was worded it sounded like the OP doesn't even know what a variable is so jumping straight to "use an array" as an answer without much explanation won't get them very far. The OP first needs to learn about what an "int" is.

Perhaps I misread the original question, but that was the impression I got.

I was just trying to add another potpin, but it didn't compile

I think the conceptual piece of the puzzle you're missing is that in this context "potpin" is a variable, which is like a storage box for data with a label stuck on it. Since it was already declared you can't declare it again: that would be like having two storage boxes both with the same label, and you wouldn't be able to refer to them unambiguously.

@Groove's suggestion to change the "potpin" variable from a simple integer to an array of integers is an excellent way to do it, but if you're just getting started that may be too confusing. A conceptually simpler way to do it is to add a second variable (storage box) with a different label and use that to refer to the second pot, like this:

Code:

const int potpin = 0;
const int potpin2 = 1;

You will likewise need to create 2 "Servo" objects:

Code:

Servo myServo potpin;
Servo myServo2 potpin2;

Then you'll need to refer to each of them in the subsequent code.

@Groove's suggestion is technically a better way to do it but if you're just getting started with programming you should start with the basics and work up. If you're curious about arrays then you can think if them as being like an extension to my "storage boxes with labels" analogy above: an array is like a storage box with lots of compartments in it, so to reference a specific piece of data you refer to the name of the array (box) and then the element (compartment) within it.
--
Jon
Freetronics: www.freetronics.com
Practical Arduino: www.practicalarduino.com

surely this is "known territory" for LUFA?

Known and very painful territory:

http://fourwalledcubicle.com/blog/2010/03/obtaining-a-vid-and-pid/
--
Jon

Hi Massimo, thanks for the clarification:

we will not be issuing PID numbers outside of the official Arduino boards

That looks like the most sensible position for the Arduino team to take. Anything else would be an administrative nightmare for you guys.

each usb processor has an internal serial number that is used to recognise which board is which, no problem having multiple boards plugged in.

Ah, neat! That overcomes a problem I've had in the past with a Linux home automation controller that had a bunch of Arduinos plugged into it. Even a lot of futzing around with udev rules wasn't enough to make them reliably come up on consistent ports, so being able to bind based on a serial number is really cool.
--
Jon

It would be nice to see some official "direction" about what the more careful derivative vendors that choose to implement the new hardware are SUPPOSED to do

@westfw, you hit the nail on the head. I think once that happens, worries like those expressed by the OP will go away. Until then there will be people worrying that this is some form of lock-in technique.

I'm sure the Arduino team have been busting themselves getting all this ready technically though, and things like publishing a hypothetical "VID/PID allocation policy" have been way down their priority list if it's even on there at all.

So far people have been saying "it's a problem", but nobody has actually said what they'd like the solution to look like. So here's my take on it.

Ideally, I'd like (as a third-party board manufacturer) to be able to apply to the Arduino team for a PID issued under their Vendor ID. I'd be quite happy to pay some appropriate fee for that privilege. I'd then like a published list of assigned PIDs and the boards they have been assigned to, making it clear which ones are official Arduino products and which are not.

That could end up as an administrative nightmare for the Arduino team though, and I can see why they'd probably prefer to avoid the whole issue and just tell third-party board developers to do it themselves (ie: pay the US$2k fee for their own VID and get on with it). It would also be tricky making it equitable: would it be a flat fee for a PID (which would favor third parties who manufacture in high volume) or would it be a per-board-manufactured fee, which would favor people who want to build only a couple of something for their own use?

It's a more complicated problem than it first appears, and my opinion is that the Arduino team will probably leave it up to other developers to solve their own VID/PID problems rather than do it for them.

A simple official statement along the lines of "we will not be issuing PIDs to unofficial boards, and the Arduino VID is reserved for official use" would clear this up once and for all. It's not the ideal outcome I'd like, but we'd know where we stand.
--
Jon
Freetronics: www.freetronics.com

The FTDI chip is just a microcontroller running a closed source firmware, this one is 1000% more open source but nobody is bitching at FTDI for not releasing their code.

Absolutely right, and speaking as someone who has used the FTDI chip in the design of an Arduino-derivative, I think the new approach is brilliant. It really rubs me up the wrong way when I look at the bill of materials for the TwentyTen and see that the single most expensive part on the board is the FTDI chip - more expensive than even the MCU.

Quite apart from which it's a locked black box, while Massimo mentions that the source for the official Arduino solution will be released shortly. That means we go from a more expensive, closed source, inflexible device on the board to a cheaper, open source, and adaptable device.

From where I'm sitting, it looks to me like the Arduino team just made the FTDI chip obsolete. I think this will have ramifications far beyond just Arduino as other totally unrelated projects start making use of this approach as well.

The niggle in my mind is the issue of the vendor ID and allocation of device IDs. When you buy FTDI chips you don't have to care about a device ID, it's taken care of. With this ATmega/LUFA solution it's up to the developer to manage it, and unless the Arduino team are comfortable issuing device IDs under their vendor ID it will be a barrier to others wanting to build compatible boards. If you're building a small number of devices it's much easier to buy a few FTDI chips off the shelf and have them work immediately than it is to apply for a vendor ID (with the associated cost) and device IDs.

Obviously I have a vested interest here (www.freetronics.com/twentyten, for example) so take my comments under advisement.
--
Jon
Practical Arduino: www.practicalarduino.com

In terms of interfacing they're all pretty similar: just serial comms using NMEA sentences, and there are existing libraries like Mikal Hart's very nice TinyGPS for decoding that easily.

http://arduiniana.org/libraries/tinygps/

For general background on how to select a GPS module, there's a guide at Sparkfun:

http://www.sparkfun.com/commerce/tutorial_info.php?tutorials_id=127
--
Jon
Arduino Shield List: http://shieldlist.org/

Little Dog is brilliant! Is that your project? Great work.

Big Dog is awesome too, of course, but that little tacker is really cool.
--
Jon
Arduino Shield List: http://shieldlist.org

Pizza Stone cut to fit into a toaster oven

I expect that will be a problem because it will introduce a lot of thermal mass, and hence inertia. The problem that cheapie toaster ovens have is heating up and cooling down fast enough to track the recommended reflow profile: the profiles I've seen are (from memory) around 2C / second, and my oven can't do that. Then in the cooldown stage you need the oven to dump heat quickly, and the pizza stone will tend to keep it hot.

Rather than a pizza stone I think you'd have more success with a simple sheet of metal, which would have smaller mass and conduct the heat quickly across its surface.
--
Jon

I did a little write-up of doing reflow in a toaster oven:

http://www.freetronics.com/pages/surface-mount-soldering-with-a-toaster-oven
--
Jon
Practical Arduino: www.practicalarduino.com