That's kind of Rube Goldberg. Why not put a meter across the leads on the thermostat and see what kind of V the thing is controlling?

You saw the circuit for the Mark II in the video? No transformer, no zener, every diode takes some toll, the least is best.

Shottkey diodes eat less of your power than the regular kind, .3V instead of .7V.

Jumping up and down gets more V in a pulse, yes, but the thing that flexes the disk 100 times a second at 2V will fill the capacitor quicker than 1 7V hit 2x per second or so.

I put 1 edge of a disk up on a pen and the other on the table so the center was not supported. Taps on the center then did make the led light brighter even though they were no harder than taps made when the disk was flat on the table. It is a matter of flex.

Still the electrons only flow a short time per flex so you want to get 'frequent flexer current' so to speak. That's why wind vibrating a string or cable or other way to get fast constant vibration is how people are doing it. Just be aware that people from MIT and other schools are not only doing these things but also have patents (or patents pending) on some designs or parts of designs. Make your own but do research before selling anything!

Shouldn't the end position for one item in queue be the start position for the next?

Hi all...

I have some simple code that reads in a digit character from 0 to 9 from the serial monitor and then does something based on the value.

Since you will only be sending 1 digit at a time, why not just:
1 - check for serial available.
2 - get the character into a byte variable (say B for buffer)
3 - check if it is a digit ((B >= '0') && (B <= '9'))  and
3a - if it is, act on it.
4 - end of loop(), long live the loop()

And you can set the serial monitor up to include end of line marker(s) but if you don't code for that then you can use Hyperterminal or equivalent to send digits over without hitting Enter to get the data sent. IOW, as soon as you hit the digit key the character is sent.

This is a good example of why not to do big string processing on a small MCU.

This is the message coming in over serial:

Code:

LX:0|LY:0|RX:0|RY:0|LT:255|RT:255|AB:0|BB:0|XB:0|YB:0|RS:0|LS:0|DU:0|DD:0|DL:0|DR:0|ST:0|BK:0|LJ:0|RJ:0|BG:0

If all you did was write a sketch that watched each letter come in, add it to a character array and counted micros until the next one and compare that to the total run time to get the message in that way, you might be amazed at how much idle time you'd be looking at.

Simple fact, the characters come in 1 at a time and 42 of those are delimiters.

You can process each part of the message as it comes in without using more than a 4-byte buffer and no commands that use string.h whatsoever. You can do that -faster- than the message comes in. I have already gotten one member here over that hurdle and his message strings from his IRDA are over 110 bytes long.

As you process each part you can be sending pieces of the return message and put the vibration motors into action. The interval is going to be short enough you shouldn't notice but just to make it shorter, try at least 57600 baud serial or good old 115200 which is over 10x the 9600 you use.

Nick Gammon hinted at the process by telling you State Engine, btw.

as the uno only has hardware for one connection

Not true.
Arduino has only 1 hardware supported ordinary serial connection. It also has 1 hardware supported high speed serial connection. It -also- has the hardware to support several more of either kind through software manipulation.

UNO can't but Mega -can- do full 8-bit parallel and address external RAM directly.

You can add 8k bytes of SPI RAM pretty cheap.

Do start, start and parity bits count?

There's so much about it, I need time to absorb. Not a simulator, an emulator, and there's a difference....

These kind of things might get some people started before they even have a board. Ahhh, the slippery road to geekdom!

You could use a C character array type string and sprintf(). You might even already include string.h.

For sure there is a terminal emulator for Mac that does the same, but I am not an Apple person.
If you run Linux on the Mac then you should have many-many choices.

Do you have a compiler or interpreter you can use that lets you read keys? Sometimes the best is what you write yourself. Then you don't have to have it keep sending to go forward -- you can have it send once and when you release the key, send a stop or other command. By reading the keyboard hardware you should be able to read more than one key at a time. Besides, doesn't the number pad make a better steering controller? Or a joystick?

I don't know about this simulator but maybe it would be good for checking simple things.

I am intrigued about

I think on PC the "Hello" got stored with code but not data segment and my code attempts to write on it.

Surely that doesn't mean you would code to change a value stored in PROGMEM so I'm missing something.

Oh BTW,

http://www.allelectronics.com/make-a-store/category/219/Enclosures/1.html

Thin plastic, you can melt small holes in pretty easily with a crap tip on a soldering iron. 

It seems that they are there to at least recover bricked bios'es.
I also see some articles on Linux SPI drivers but wow, not simple!

Indoors a little plastic tent or lean-to or cone should work. Drops that form on the underside should stick as they run down, away to the side(s) before falling off. It works in solar stills, except there you collect the water into the middle.

http://en.wikipedia.org/wiki/Solar_still