In real-life terms, a faster crystal means things execute faster - including delay() and milliseconds() - as well as serial I/O. If your software doesn't rely on time, you should be OK. (If you're debouncing buttons, you might want to increase the time by 20/16 to compensate.)

You can use a Uno to program and then move it over to your faster crystal board to run if you don't want to bother finding a bootloader that handles 20 MHz.

The second bit of code defines two different variables (both called i) in different scopes. The first bit of code defines only one variable called i in the global scope.

I'd bet the compiler is detecting that nothing is done with the i in the inner scope, so it doesn't bother assigning 5 to it - it just optimizes it out.

In the first case, the global i is equal to 5 after setup runs. In the second case, the global i will probably be 0 (or might just be whatever the last value was in memory there) since you never assign to it.

Alternately, you might use a relay (SPDT or DPDT) to switch the line that's connected to pin 8. You'll need a transistor to drive it:

http://www.arduino.cc/playground/uploads/Main/relays.pdf

This assumes you can read one frequency and then read the other sometime after that - i.e., you don't need to read both at exactly the same time. And that you can wait for the relay to settle (a few hundred ms) before you read.

I haven't seen a dual-inline-pin version of the Leonardo - only the surface mount version. With a Uno, you can pull the 328p from its socket and put it into a circuit after programming it. You won't (as far as I know) have that option with the Leonardo.

Desoldering wick is just braided copper with flux in it. It is really cheap and everyone should have some - but if you're stuck somewhere without it, you can approximate it with stranded copper wire.

Fan out the strands a little, let the solder wick into them, and then repeat until the solder is gone. If you have liquid / gel flux, dip the strands in that first to make life easier.

Just a thought: I have no idea what sonic relays are, but if they're emitting and detecting sound to close a switch (like a ping sensor), maybe they're interfering with each other? That would explain why one works fine, two get a little flaky, and three don't work at all.

I'm surprised: the cable I bought was being sold as an "extension cable", and was labelled that way on the box. I'd expect that a cable intended to be cut into two would have twisted the leads so each distinct pin would have the same colour wire going to it.

Interestingly, if I'm wrong, then others are as well:

http://www.alibaba.com/product-gs/516251450/SAE_2_Pin_Extension.html
http://www.amazon.com/Hopkins-47965-2-Pole-Flat-Extension/dp/B0002Q80RW

I'm learning way more in this thread than I though! :-)

As for caravan vs trailer - I understand these kinds of cables are used more for the type of vehicle that tows boats, rather than rooms in which to camp. I'd call that a boat trailer - not sure what others would :-)

For a quick and dirty solution, multiply it by 10000 before you send it, cast it to an int, send the characters as ASCII, and then divide by 10000 on the PC side to get back your original float. (Watch for overflows though...)

Is EEPROM.h being included, or is it not being found? I've always found it useful in cases like this to put #error at the top of the header file you're including (temporarily, of course):

(EEPROM.h)

Code:

#error "Yes I just included EEPROM.h"

If you don't get the error, something is wrong with your include path or location of the header file. You could put it right before the line that defines EEPROM if you want to narrow things down.

Thanks very much for the useful information. In my case I think the fuse blew before the diode and/or traces on the SMT circuit board acted in the fuse's place... which is as good a reason as any to have a fuse in circuit!

(And nothing beats dumb luck when you're ignorant. I didn't even realize my cable was fused... now I'm checking that every time.)

As a warning to others: if you cut a trailer wiring extension cable in half, the red wire is hot on one end and ground on the other:



Pay attention when connecting!

Recently, I had occasion to plug a radio in backwards. Luckily, the inline fuse in the power cord saved the radio. This got me thinking, though.

The inline fuse was rated at 4a 250v. Since the fuse was inline with a battery (12v), does this mean it opened at a different amperage than specified, or will all 4a fuses blow when 4a goes through them regardless of voltage? If not, is there an easy way to convert?

I think I've got religion when it comes to fuses now - all my power cables in the future are going to have them. Losing 20 cents worth of fuse is nicer than losing $50 worth of radio.

It looks as if your library isn't being imported. Is it in the right place? The error message you're getting is what happens when C++ doesn't know about a class:

http://cplusplus.syntaxerrors.info/index.php?title=%E2%80%98Foo%E2%80%99_does_not_name_a_type

I'm not sure you can digitalRead() an output pin. You might have to keep track of the state manually:

Code:

digitalWrite(10, HIGH);
statepin10 = HIGH;

I don't know of a limitation - especially since you're not actually doing anything with audiofiles. However:

Code:

char audiofiles[NUMTAGS][14] = {"hello   ",

you're creating an array of 5 strings that are 14 characters long. That should be enough to fit 13 characters + \0.

What makes you think there's a limitation on string length? What behaviour are you seeing?

I also looked into genetic algorithms / genetic programming back in the late 90's / early 2000s. It's not hard to come up with a language where every statement is syntactically valid (i.e. it does something, which may or not be what you want) and a fitness function (a way to evaluate a program to determine if it's closer or further away from a desired solution than other instances of a program).

LISP is good because a list can also be a program. Create a million lists at random, execute them all with your dataset, pick the best 50% or so, making sure that the fitness function also has a component that selects smaller programs over larger programs. Then cross-breed the programs (exchange parts of successful lists with parts of other successful lists). That's one iteration. Do a few million iterations and eventually you've got a program that does something like what you want.

The problems: it takes a LONG time to evaluate all the programs, and you might have to have some sort of timeout criterion to prevent endless loops. It takes a LONG time to do all the iterations you need to satisfy your fitness function. Once you've satisfied your fitness function enough, you have something that works for your test dataset - that might not handle all the data you throw at it. The more complicated a thing you want, the longer it will take. Not all problems can be solved with GP: you need a problem that lets you know when you're getting closer to a solution.

See it in action here:

http://alphard.ethz.ch/gerber/approx/default.html

(needs Java)