body:
Anyone with kids knows they never help with the toilet paper. Anyone know how to track when it's low or out and sound an audible alarm? I just don't know what sensor to use that may help.

Some that came to mind are: by weight, by reflection (the color of the paper) or some laser tripwire - all right on the spool. I don't mind building it, it's just I don't know which sensor. Anyone know which to use?

title: How to trigger an alarm when toilet paper is low?

Answers: 17

body:
One idea that comes to mind would be something like that:

- stick a small magnet inside the paper roll, i.e. inside the cardboard part (this has to be done every time you change it; though)
- use a reed contact (electro-magnetic switch) at the tip of a stick mounted with a spring to be always in contact with the paper roll
- one pin of the reed contact can be directly connected to an input logical pin (set it up as a pullup resistor input)
- the other pin of the reed contact is to be connected to the ground

Thus, as soon as the distance between the magnet and the reed contact is under some limit, the switch will close the circuit. That distance will decrease while the paper roll gets drawn.

Note that, instead of a reed contact, you may also use a Hall Effect sensor, the principles remain the same, only technology and characteristics change.

The difficulty here will be to find the right sensitivity of the reed contact (or the force of the magnet) so that the reed contact gets closed when the distance between it and the magnet is small enough to avoid an alarm that would be activated too soon).

body:
## You have a few options:

Note: The links given are just the first ones that come up. Most of them are pricey compared to other sites. eBay buy it nows can be fairly cheap for most of these items. Check other places, too, including [Sparkfun](http://www.sparkfun.com).

 - [Ultrasonic Ping Sensor](http://www.robotmesh.com/parallax-ping-ultrasound-sensor?gclid=CJvLqNvY9LwCFewRMwod0SQAzw). This isn't ideal by any means, but they're easy to use. Just add one with an enclosure. It isn't ideal because it won't be accurate enough to tell when exactly it's empty. It might be a little over/under sensitive. Weight would be harder, though if it shifts at all.
 - [Color sensor  (preferable, but costs more)](https://www.sparkfun.com/products/10904). You mentioned this and this is probably the best idea. It'll give you analogue values (to read with Arduino) for red, green, and blue. [Assuming that the higher the content of that color, the higher the voltage,] white should be pretty much all of those at 100% and brown I would image that most of them would be about 30-40%. (More later, if you don't understand this, skip this part)

***
**I'm going to go into more detail on the color sensor:**

Colors are read with three values here: red, green, and blue. There are three sensors on the board. One filters out everything except red, another blue, and the other green. The sensors on the board detect the amount of incoming light and then convert that to a voltage: between 5V ("100% red/green/blue") or 0V ("0% red/green/blue"). This then can be converted into a number by the Arduino (0-1024 on an analogue pin).

**A problem with lighting:**
This sensor, from what I can tell, has a LED that's always on. You'll want to either desolder that or cover it up, unless you want an illuminated toilet paper holder. Now wait... your sensor will think that when it's dark, it's brown. No problem... here's something for you mind to think about.

[Use a color picker like I'm using and select a brown](http://www.w3schools.com/tags/ref_colorpicker.asp). On the left of this one, you can control the "simulated brightness." Besides that is the hexadecimal form of RGB. You'll want to convert that to standard [values with this calcuator](http://www.javascripter.net/faq/hextorgb.htm).

In brown, the color blue is almost nonexistent. We should ignore that color, unless you want a way to double check that it's brown. I'd say it should always be under 40% for pretty much any shade of brown.

From what I can tell with a sample shade of brown, the red is pretty much 2x the green. That ratio may vary, but you should verify that it is *somewhat* existent. For white/grey/black, all the colors are proportional 1:1:1. You can use this to detect if it's dark, or if it's brown.

    int rPin = A0;      //Red Pin
    int gPin = A1;      //Green Pin
    int bPin = A2;      //Blue Pin
    int ledPin = 13;    //I made this code with a LED, not a speaker
    boolean testTwice = false;

    void setup() {
      pinMode(ledPin, OUTPUT);
    }

    void loop() {
      int rValue = analogRead(rPin);
      int gValue = analogRead(gPin);
      int bValue = analogRead(bPin);

      if (bPin < 256) { //If this is false, either something is in the way or it's white. Going to verify that something's not in the way...
        int minRed = rPin * 0.4; //A little under a half for padding... this values may need to be adjusted. Adjust this one and the one below farther apart for less sensitive.
        int maxRed = rPin * 0.6; //A little over a half for padding... this values may need to be adjusted.
        if (gPin < maxRed && gPin > minRed) { //Verifys that red between minRed and maxRed
          digitalWrite(ledPin, HIGH);
          delay(5000);
          digitalWrite(ledPin, LOW);
        }
      }
      delay(5000); // No need to waste power... you might want to add an actutal sleep function if on battery power
    }

First, it verifies that the blue is less than 25%. Then, it verifies that the red and green are equal... give or take 20%. (i.e. red = 100 green = 80, red = 110 green = 90, etc.). If that is true, you can pretty much establish that it's brown. Then, a LED turn on for five seconds.

You can modify the LED to be a buzzer if you want. You might have to adjust the if statement with verifying that the blue is less than 256/1024 (1024 = resolution of analog pin) if it isn't working in a lot of light or is working in dark light. Since the code later verifies that the red is about 2x the green, any shade of white shouldn't pass that if statement. You may also have to adjust the `minRed` and `maxRed` to be farther (if not detecting brown) or closer (if detecting brown when it's white). I can't really test this code with no color sensor.
***
Note: these can be a little fidgety. **I would recommend a LED instead** so the whole house isn't woken up in the middle of the night just because of low toilet paper. Also, if you obstruct the sensor at all... If it wasn't in the bathroom, I would recommend a camera and have it take a shot every time it gets very low with a reed switch like @jfpolipret's answer... but... (no pun intended) :)

body:
An short-range ultrasound distance sensor might be an effective (and fairly cheap) option. You can get an emitter+sensor combination mounted on a chip. Different sensors may work in different ways (always check the datasheet). A common output though uses the length of a pulse to indicate the distance sensed. You could process that in Arduino using the [`pulseIn()`][1] function.

In terms of installation, you'd probably fit it directly behind the toilet paper, pointing at the centre of the spool. The readings are often quite erratic, so you want to take several measurements and average them (or use a simple moving average). With a bit of calibration, you could determine what distance represents an empty spool.

When you detect that distance repeatedly for a significant period (e.g. a minute or more), you'd sound the alarm.

A reflectance-based sensor might be another possibility, although I wonder if you might struggle to find one which will work properly on toilet paper (depending on how soft your preferred brand is!).

  [1]: http://arduino.cc/en/Reference/PulseIn

body:
Bring up several rolls at a time and hang one for use. Put the other two on a short vertical pole within reach of the sitter. Sitter can take another roll when needed.

Mechanically sense lack of weight on the shelf at the bottom of the pole. Alarm triggers when the last roll is removed. No one has to get caught short.

To sense the weight use a force sensitive resistor such as the [FSR 400][1] (see [datasheet][2]). Alternatively, you could use a lightweight coil spring to rest the toilet paper on with a micro switch that is released when both rolls are removed. Another option would be an IR beam break detector where the circuit is completed when the last roll is removed.

  [1]: https://www.sparkfun.com/products/9673
  [2]: http://dlnmh9ip6v2uc.cloudfront.net/datasheets/Sensors/ForceFlex/2010-10-26-DataSheet-FSR400-Layout2.pdf

body:
Sounds like a cool project, here are my 2 ct:

Point a camera to take photos of the roll from sideways, that is probably the only way to really find out how much paper is left. (edit: You could use a raspberry pi with the csi camera and create an output signal corresponding to the number of sheets and feed that signal to the arduino?!)

For an estimate it might also be enough to count rotations of the roll, but you need to fiix the roll better so it doesn't slip. Or you can use magnets like you do on bicycles, but they need to be attached to the roll directly then.

(edit: one more idea, mesure the thickness of the roll by measuring the angle of the lid)

body:
Use a radiation detector to detect the amount of paper left on the roll. Place some amount of radioactive material in the middle of the spool rod, and place the radiation detector somewhere else (you could mount it on the other side of the surface the roll holder is mounted to, if you want; radiation sensors are extremely flexible), and measure the radiation amounts to determine how much paper is left on the roll.

Alternately, you could have an electronically controlled toilet paper dispenser (push button to dispense a preprogrammed length of toilet paper) and have the arduino just keep track of how much has been dispensed.

Or, attach a rotary encoder to the side of the spool rod (make sure it fits without slipping inside the roll), and count the rotations of the roll to determine how much has been used.

Of course, with any of these methods, you will have to do tests and collect data  depending on the exact type/brand/material/etc of toilet paper.

Especially for the second and third ideas, I would recommend taking data from the system regularly, to keep track of the typical length of a roll so you can adjust the program for any significant variation. Even within one type of toilet paper, I would imagine that there would be some variation in roll length.

For even more fun, you could instrument the detector to collect time series data, so later you can upload it to a computer and make a "toilet paper usage over time" graph or something.

body:
The simplest, yet best solution afaict, would be to use an optocoupler made of one IR LED and an opto-transistor. You make the LED lighten towards the roll, the LED being within the roll tied to the "handle". Once you remove the cardboard roll, the opto-transistor gets the IR light from the LED and triggers a pin change interruption on the Arduino, which can then alert you through many ways (light, SMS, twitter, alarm…).

That design is really cheap, easy and fast to build. Though there's still one thing you need to do: when there's no more toilet paper, you need to actually have the cardboard roll *removed* ;-)

Otherwise, the same kind of solution for the spare rolls is even a better idea :-)

body:
I think I saw this in series 1 episode 2 of James May's Manlab.

Similar to jfpoilpret, use a wide piece of material on a spring that makes contact with the roll at all times. I say 'wide' so that when the roll is empty the reed touches with a contact on one of the roll holders on the side. When it touches it completes a circuit to your alarm.

Here's a crude image describing what I mean.

In Arluin's response it was mentioned that this method would not show that the the roll was empty. Thats pretty much true. If the top contact is as thick as the TP cardboard roll and the bottom contact is positioned inside the inner part of the cardboard roll it should get close enough for practical purposes. One foot of TP roll is not enough after taco night.

![Behold the image of my imagination][1]

  [1]: https://i.stack.imgur.com/uSWHr.jpg

body: Your best option is attaching a rotary encoder to the side of the roll, and count the rotations of the roll to determine how much has been used. Once you know the number of rotations per roll,you can set where you want your notification to fire. Attach it to a logging system of sorts and you'll have historical data of paper use as well as toilet use.

body:
I believe the reed sensor concept put forth by jfpoilpret and jmathew is the easiest to accomplish. I have drawn a diagram of how I think it would look.

You could adjust sensitivity by adjusting the height of the lower contact.

This really only gets you to a "low" condition and not necessarily out. Unless you want to change rolls while there are still a few sheets left this doesn't seem to me to be a satisfactory solution. I'd rather have an "out" indicator and have an audible buzzer to prompt/shame the user into replacing the roll.

This design could be accomplished using standalone electronics (no arduino needed). However it you wanted to gamify the changing of the roll you could use an arduino for that.

Note also for color based optics sensors, while the vast majority of cardboard tubes used for this purpose are brown, I have seen white ones in use as well.

![Reed Sensor Diagram](https://i.stack.imgur.com/CY76e.png)

body:
I built a reflectance tachometer for an Arduino that'd probably solve your problem.
The basic circuit is quite simple:

![tachometer circuit][1]

I had a photoransistor laying around that responded well to red light, and [another from Radio Shack][2] that was quite sensitive to the IR output of old TV remote LED's.
For your purposes, green wire would be hooked up to Analog Pin 0 of Arduino, and you just have to sample periodically, not set up an interupt driven sketch.
The trick to getting a reflected signal difference between white paper and grey roll is knowing that light sensitivity of a photransistor increases w increasing resistance to GND, but the dark voltage also goes up. I came by the 5 and 3 megohm values empically, by checking the AtoD values off dark and light objects at a distance of a few inches from the detector. Same procedure should work for your detection of grey vs white. Although some things that look quite different visibly have the same reflectance in IR. Here's a pic of the finished red light tachometer:
![enter image description here][3]

It should be simple to make the sensor board small enough to fit into the back of your paper dispenser. IR version is even smaller, but buried too deeply in a home-built centrifuge to get a pic of it today.

  [1]: https://i.stack.imgur.com/IOohy.png
  [2]: http://www.radioshack.com/product/index.jsp?productId=2049724
  [3]: https://i.stack.imgur.com/TlJjj.png

body:
I think another decent and cheap option to use is a proximity sensor like the ones on the phone or a fixed field infrared sensor. These sensor are pretty accurate and can easily be used to "look" at the back of the toilet roll by mounting the sensor to the holder or the wall where the toilet roll is placed.
All the other ideas I saw on the post were either fairly inaccurate or felt intrusive towards the toilet roll which in the long run I feel may provide contamination.
A proximity sensor is not only fairly cheap and easy to use, if calibrated well, they can allow a very good amount of accuracy and reliability. This model is already in wide usage in men urinals to auto-flush.
For example on your phone: Your phone will accurately provide a distance of 2.0 inches or infinity when your hand or your face is near the screen.

body:
A lot of the options here seem overcomplicated and intrusive.

Color Sensor

Another option, slightly complicated (but fun) to implement, but unintrusive and easy-to-install, is to build a cheap [color sensor][1] and mount it on the wall behind the roll. When you detect the color of the roll (or the absence of the color of TP), it's low.

You can also just [buy one for $8][2].

You can adjust the threshold by taking advantage of the thinness of TP and the fact that it starts to look a little darker when there's only a few sheets left.

If necessary, calibration can be done by pressing a button after a new roll is installed with the bathroom lights on.

You would have to make a few adjustments depending on the specifics of your bathroom. If you added some extra complexity and powered it off an AC outlet that was tied to the bathroom light switch, you could only have it powered on when the bathroom lights were on, which would filter out a lot of unreliable data.

This is very easy to install and doesn't involve modification to the roll itself. You could stick the sensor to the wall with double-sided tape, or put it on a tiny shelf under the roll facing up (or on top facing down).

IR beam break

Mount a small IR LED on one side of the dispenser, just above the spool. Mount an IR photo sensor on the other side of the dispenser. When the sensor sees the LED, the roll is low. Could be done with a cheap laser too (e.g. an off the shelf laser pointer on one side and a photosensor on the other; but don't hurt your eyes!)

This is also easy to install (e.g. hot glue to dispenser) and doesn't involve modification to the roll, although the location of the sensors might make them easy to damage when you're replacing rolls.

I also really like the reed sensor and range sensor (BTW: [$10 gets you a great short range distance sensor][3]) options here.

  [1]: http://www.instructables.com/id/Introduction-29/
  [2]: http://www.dfrobot.com/index.php?route=product/product&product_id=540#.UxctDPldWSo
  [3]: http://www.adafruit.com/products/466

body:
Another way to do it, in case you just want to for the fun of it would be to put a metal rod inside the roll, and a metal plate on the outside, and measure the capacitance which should change with the TP remaining due to the dielectric constant of the paper.

But that would be taking the "scenic route" for sure. Still, the Arduino can measure capacitance pretty easily and it might even be sensitive enough, and it would stay out of the way because it would just be a metal plate behind the roll and a metal rod in the roll. You might even be able to retrofit an existing holder without it being noticed.

An easier way would be a stick attached to the shaft of a potentiometer held up by the top of the roll. Less TP, shaft goes lower and turns the pot. Might need a long shaft for leverage because you can't press too hard without impeding the function of pulling toilet paper.

As AJMansfield suggested, Radioactivity actually is used to measure the thickness of things in industrial settings. If you really wanted to go crazy maybe you could use an extremely low energy radioactive source like a can of that weird tasting salt substitute which is a tiny bit above background levels and average over extremely long times(toilet paper shouldn't change much from hour to hour), so this could actually be a reasonable if expensive way to do things.

Infrared beam break sensors are also good, and if you position it right you could get it to block more light the fuller the roll was instead of just giving you and on or off signal.

EDIT:
Working Proof of concept of the capacitative approach. Only needs an arduino and 2 stiff wires. Precise to about an 8th of an inch, with a lot of noise. Pretty sure you could reliably get at least 1inch accuracy. Measurement time is about a minute. It's really sensitive to it's surroundings. You'd have to make sure anything metal within a foot stayed where it was or use shielding.

    float difference;
    unsigned long i;
    unsigned long j;
    unsigned int temp;
    volatile unsigned char blah;

    void setup()
    {
      pinMode(5,OUTPUT);
      Serial.begin(9600);
    }

    void loop()
    {
     difference =0;
     Serial.print("Measuring: ");

     for(i=0;i<100;i++)
       {
         for(j=0;j<5000;j++)
         {
           digitalWrite(5,LOW);

           temp=analogRead(A0);

           digitalWrite(5,HIGH);

           temp = analogRead(A0)-temp;
           if(temp<1024)
           {
             difference += temp;
           }

         }
         //Random delay every 5000 samples helps avoid problems with interference by staggering the samples to cancel aliasing.
         delay(random(1,50));
         Serial.print("|");

       }
       Serial.print("\n");
       Serial.print("Value: ");
       Serial.print(difference/500000);
       Serial.print("\nMeasurement Complete. Press Enter to begin another test.\n");

       while(!Serial.available())
       {
         blah = 20;
       }
       Serial.read();

    }

http://pastebin.com/2W5y81AB

body:
I think 'Arluin' and 'jmathew' have the right idea.
Use a lever resting on the top of the roll.

I would do it slightly different however.
Rather than rely on contacts shutting you can use a potentiometer.
With this system you can measure the amount left instead of simply being notified when it gets low.

With a contact such as those suggested already, you might get paper stuck in the contact as it closes and then low paper would not be detected.

(You may need a weight, shown in blue on the diagram, to push the lever down as the roll is used)

You would need to try and get the pot as close to the roll as possible for maximum swing of the pot and therefore maximum resolution of amount remaining.

Another thing you might want is some kind of roller on the end of the lever so that the paper roll can move easily with little drag where the lever contacts the paper.

![Proposed setup][1]

  [1]: https://i.stack.imgur.com/3RoTx.png

body:
You could just crack open one of those playing birthday cards and adapt the switch to the holder arm. Once you hear 'Happy Birthday" chiming from the toilet you know you're in trouble! (and because they are very low-power these things chime on forever ;-) ) I've shown a LED setup here but you get the idea...

![happy birthday][1]

  [1]: https://i.stack.imgur.com/oQBrx.jpg

body: I say get a weight sensor, and program it for the roll's weight. When it drops below a certain weight, start flashing an LED or make a beep.


body: I am using the A0 port on my Arduino Uno to read the voltage output from an LM35 temperature sensor.  I observed that the reading fluctuates a lot if I leave the remaining analog input ports A1 to A5 floating. Would floating analog inputs affect the accuracy of readings on input ports connected to some signals.

title: Should all unused analog input ports be tied to ground for accurate A2D measurements?

Answers: 2

body:
Any floating pin will act as an antenna, and may interfere with values around it, this is one of the major disadvantages of using analog.

To get the most accurate readings with minimal amount of interference, you can pull all unused inputs to ground.

The accuracy will not change, as the accuracy is determined by the sensor itself. However it will reduce the amount of noise / interference, which will give you more accurate readings.

These pull to grounds can be accomplished by configuring the unused analog pins as digital outputs, and setting them low.

    pinMode(A1, OUTPUT);
    digitalWrite(A1, LOW);

body:
Even if setting the unused pins to OUTPUT/LOW consumes a little bit less power than INPUT with PULLUP enabled, i guess the second option is more save.

To quote somebody else:
> If you accidentally touch a hot wire to an output set low you short-circuit your processor and frie it. If you accidentally touch a ground wire to an output set high you short-circuit your processor and frie it. If you accidentally touch either wire to an input with pull-up you won't even notice.


body:
I am currently using a ST7565 graphic LCD for display in a heat pump system.

This LCD has the following characteristics:

 - 128x64 pixels
 - 2.5"x1.5"
 - monochrome, no greyscale
 - backlit
 - good viewing angles
 - serially connected (i.e. only uses a small number of pins)
 - high enough refresh rate to show animated icons
 - low cost (£20)
 - has a high-quality, maintained library
 - available from multiple sources for several years

I am finding the resolution of the screen limiting for my application. Ideally I would like a display that is exactly the same but with a higher resolution. Something between

I do not want:

 - colour (largely as the display is less visible, but also increased cost and code complexity), but red/green/blue on black would be OK.
 - a physically smaller display (all of the OLED displays are small - 2" and below) as it needs to be visible from a distance

Are there any displays that meet these requirements?

I hope that the specific requirements here mean that this is not a simple "[shopping question][1]".

  [1]: https://arduino.meta.stackexchange.com/questions/16/when-should-questions-be-considered-shopping-recommendations

title: Are there any commonly available and supported backlit, monochrome graphic LCDs with more than 128x64 pixels?

Answers: 1

body:
Here you can find a bunch of displays at [new haven display](http://www.newhavendisplay.com/oled-graphic-oled-c-119_577.html?zenid=jpvgfaffukfrnbam6l9mnkbqg1), which are big and OLED and not too expensive:

 * [2.7" 128x64 OLED](http://www.newhavendisplay.com/images/NHD-2.7-12864UCY3-front-NOBL.jpg)
 * [3.12" 256x64 OLED](http://www.newhavendisplay.com/nhd31225664umy3-p-6092.html)

Those OLED Displays have a really excellent viewing angle and can be read from far (given you accept those sizes, which are >2").

Otherwise, the biggest I know about are [LCD ones from NHD](http://www.newhavendisplay.com/lcd-graphic-c-21.html) over there:

 * [320x240 LCD with backlight](http://www.newhavendisplay.com/lcd-graphic-320-x-240-c-21_107.html)

What's good with them, it's that they can cope with production in case this is needed, their prices are decent and their product just work(cTMr). You can find the [u8g library](https://code.google.com/p/u8glib/) to run them.


body:
## Ignore the stalker-like title.
I am thinking about creating a project with Arduino that can sense you sleep habits, when you're asleep, and how much you sleep. It would be convenient to not have to turn it on/off at night; it should know how to do this.

Some ideas that I have:

 - Motion sensor
 - Breathing patterns (if an Arduino microphone could even pick that out... I would be surprised if it could)
 - A RTC clock could assist in deciding *It's midnight. Usual, Steve isn't asleep at this time on Fridays. He's probably not sleeping now.* It won't always be there to help you, but you might be able to try to get more accurate results this way

**How can I accomplish this?** (Extra points for some sort of algorithm that can tell dozing off from a deep sleep.)

title: How can I sense when someone is sleeping with my Arduino?

Answers: 1

body:
I actually did something like this, using a [PIR Motion sensor][1].

The motion sensor is good enough to detect a person turning in their sleep, and my simple algorithm just counts movements per minute and when its over a threshold (found by trial and error), it sounds the alarm to wake you up.

![enter image description here][2]

The image above represents my body movements during a night. The spikes represent a high movements/minute.

> Here we see after about 30 minutes body motion was minimal. This suggests I was in a deeper stage of sleep during that time.
>
> The spike at 250 minutes (around 4:30AM) is when I woke up only to
> realize I could sleep for couple of hours longer. I recall the time
> being 4:38 when I looked at my clock and I was already facing it. This
> means I turned around to face the clock but actually "woke up" 8
> minutes later to see the time, and then turned back around (indicated
> by the shorter spike at 265).
>
> The data suggests I was not able to sleep very well (compared to the
> time period between 30 and 240 minutes) after waking up once and
> finally got up at 400 minutes (7:00AM), when I shut everything down.

Here are a couple of posts from my blog that have a lot more information.

* [Body Movement During Sleep][3]
* [Intelligent Alarm Clock Hardware][4]

  [1]: https://www.sparkfun.com/products/8630
  [2]: https://i.stack.imgur.com/pYBe3.png
  [3]: http://blog.sachleen.com/posts/1353217318/body-movement-during-sleep/
  [4]: http://blog.sachleen.com/posts/1353217790/alarm-clock-hardware/


body:
I wish to build a remote for my Camera i.e Sony NEX 5R. It has a built in IR receiver and has several Sony as well as aftermarket remotes provided for it. Due to my interest in Micro controller design I wish to build one myself rather than use an aftermarket one.

A friend who did the same for his NEX 5 series camera posted a video of the same on Facebook, which inspired me to build my own. I plan to use an Arduino Uno R3 with the following additional components:

 - IR LED

 - NPN Transistor(for amplification)
 - Schmidt Triggers(for rectification)
 - 9 Volt Battery

Ultimately I would like to swap out the Arduino for a standalone ATmega328 or ATtiny2313 but currently I have some issues as of now:

 1. I currently do not have a schematic or a sample code which I can use. I have been trying to search the internet for the same but to no avail.
 2. I am unsure of the protocol used by my camera. I have found it difficult to find documentation on the same.
 3. How can I replace the 9-Volt battery for something smaller?
 4. I would like to use a smaller micro controller but what differences will I encounter when trying to change my code for the smaller micro controller?
 5. For such a project, will I need additional hardware?

title: Build Infrared Camera Remote

Answers: 3

body:
1. Using the Arduino shouldn't be any different than any other microcontroller.
2. The [IRremote library][1] is my go-to library for any IR related stuff.
3. Power shouldn't be an issue, look at the [Moteino from LowPowerLab][2] and check out his [coin cell battery tests][3]. It's definitely possible. Not with a full blown Uno, but with a bare chip, yes.
4. You want to burn the bootloader on the IC first, before you can start writing Arduino code. Check out this tutorial: [From Arduino to a Microcontroller on a Breadboard][4]. It's the same process for an ATTiny, you just have to look at the datasheet to see where to plug things into. Specifically, MOSI, MISO, SCK, and Reset pins. The [Tiny AVR Programmer][5] is also a good choice. It's meant for the 8 pin micros but it has an ISP header so you can use it for almost any chip.

This may be useful for more information about decoding IR signals:

* [EEVblog #505 - IR Learning Remote Control Hack][6]
* [EEVblog #506 - IR Remote Control Arduino Protocol Tutorial][7]

  [1]: https://github.com/shirriff/Arduino-IRremote
  [2]: http://lowpowerlab.com/moteino/
  [3]: http://lowpowerlab.com/blog/2012/12/24/moteino-coin-cell-battery-tests/
  [4]: http://arduino.cc/en/Tutorial/ArduinoToBreadboard
  [5]: https://www.sparkfun.com/products/11801
  [6]: https://www.youtube.com/watch?v=vOzaDQmAW0g
  [7]: https://www.youtube.com/watch?v=BUvFGTxZBG8&feature=youtu.be

body:
1.) I'm not exactly sure what you mean by this. What I'd recommend is a [ATMega328](https://www.sparkfun.com/products/9061) for the heart of the chip. It's what is in the Uno, so with a exception of uploading code, for this project this will cut down on the size of your project. However, an Uno will work pretty much identical. If you do want to use a chip like this, [this design](http://fritzing.org/projects/barebones-arduino) looks pretty complete. You'll probably want to move to a PCB for your final product, but since you have a little electronic experience, I assume you can solder and know about this. [Here is another tutorial for barebones](http://playground.arduino.cc/Learning/AtmegaStandalone).

 2.) Again, what do you mean by "standard?" Like protocol? If so, there's no real protocol to use. [This may be easy for a begginer](http://www.robotmesh.com/ir-kit-for-arduino?gclid=CM650djc97wCFexcMgodK0kAjQ). It's the remote and the receiver. If you want to go all geek you can also [hack an existing TV remote to do the same task](http://www.righto.com/2009/08/multi-protocol-infrared-remote-library.html). That library should take care of everything you need (see code later).

****
**A bit of code/wiring:**

The circuit will depend on what receiver you choose. Most IR receivers have one pin for 5v, one for GND, and the last one is connected to a digital pin. Again, look at the information on the specific receiver you choose.

Some sample code with the library I listed:

    #include <IRremote.h>

    int RECV_PIN = 11;        //Using pin 11 for the signal pin
    IRrecv irrecv(RECV_PIN);  //Creates a variable that will be used later to inference between library and code
    decode_results results;   //Use it to store the value of the keycode

    void setup()
    {
      Serial.begin(9600);
      irrecv.enableIRIn(); // Start the receiver
    }

    void loop() {
      if (irrecv.decode(&results)) {
        Serial.println(results.value, HEX);
        irrecv.resume(); // Receive the next value
      }
    }

You'll have to run this sketch to determine the value of the button you'll use on the remote. It should print on the serial window some sort of hexadecimal value IIRC that you'll have to convert into decimal if you want to use it inside the code to compare that to the button you want to use on the remote. The post I mentioned is a great resource: go and look at it.
****
 3.) I don't recommend building a remote. Like I said, you can use existing TV remotes or buy one for this purpose. Start small, figure out how IR remotes work, and then build one later if you desire. A v2 is often required on Arduino.

 4.) Don't bother for the receiver. It *can* be bigger. If you don't know how to to program it, [this guide is a good reference](http://highlowtech.org/?p=1695). It has some files that you download to add it in the IDE to trick the IDE to think the chip is a board. Note: You'll have to program it with an Uno or similar to upload and to burn the firmware. (I would explain it more in case the site goes down, but you need the files there so it'll be pointless anyway.)

Also a quick tip: don't be afraid to ask your friend for some help. You don't need to rely on him, but if you get stuck ask him.

I don't know how to connect the Arduino to the camera, but you seem to know how to do that.

body:
Well, for your project you can simply buy/rebuild a TV-B-Gone [made by Mitch](https://cornfieldelectronics.com/tvbgone/buy.tvbgkit.php?PHPSESSID=3phhip32unp1ku0di8qe9e6od0), which he uses as a basic project to teach soldering all over the world.

You can "hack" the TV-B-Gone by adding a [TSOP4838](http://www.vishay.com/docs/82459/tsop48.pdf) that can work as an IR receiver (or use another device as a code recorder).

![TV-B-Gone](https://i.stack.imgur.com/LezO4.png)

And as you can see here the TV B Gone features an ATTiny85. A really small and nice beast.

Here you'll find the [source code](https://github.com/adafruit/TV-B-Gone-kit/tree/master/firmware) for the TV B Gone. I'm not sure what format they use for their code database though.


body:
Stepper motors are often pricey for a large motor. However, with a powerful, standard DC motor and a rotary encoder, you can "simulate" a stepper motor. **How accurate are rotary encoders with Arduino just with a basic loop and not much other code?** Is it going to "miss a pulse" and not record enough rotation often? How can I handle this with much more code? Is there a better way to do this? Would interrupts help? Is there some sort of circuit that would help with this problem?

Note: It will probably not exceed 4 rotations a second... *(That may be a lot but if you're doing a lead screw type mechanism that would only be 24 inches a minute if there is 10 rotations per inch of linear motion.)*

title: How precise can I get Arduino using rotary encoders?

Answers: 2

body:
Interrupts are what you would use in this situation.

The rates that you have mentioned are slow enough where you *probably* would be able to count it inside of a loop, however this is not recommended, as a typical loop will take many clock cycles to complete, and depending on the number of instuctiuons per loop, you may miss some counts.

Interrupts are made for this purpose, as they can be triggered at any time, regardless of the state of the loop.

There is a function named `attachInterrupt()` which will take three arguments.

 1. Interrupt Pin
 2. Interrupt Service Routine
 3. Mode

Below is an example for counting an interrupt

    volatile int myCounter = 0;

    void setup(){
        attachInterrupt(0, count, RISING);
    }

    void count(){
        myCounter++;
    }

The Modes are as follows:

>LOW, CHANGE, RISING, FALLING

More information about using interrupts can be found [here][1].

Depending on the encoder you use, you will need to tailor the code your needs, and do some more calculations to determine your position, but this should be a good starting point.

**Edit**
[Here][2] is some example code from Arduino Sandbox for using a rotary encoder.

  [1]: http://arduino.cc/en/Reference/attachInterrupt#.UxVGrvldXvM
  [2]: http://playground.arduino.cc/Main/RotaryEncoders#.UxVIwvldU4J

body:
Adding some references to already-written libraries and examples, to enable comparison between different approaches, and experiences with speed versus susceptibility to missing steps.

Reading rotary encoders:
http://playground.arduino.cc/Main/RotaryEncoders

Quadrature Encoder too Fast for Arduino (with Solution): http://www.hessmer.org/blog/2011/01/30/quadrature-encoder-too-fast-for-arduino/

Teensy Encoder library: https://www.pjrc.com/teensy/td_libs_Encoder.html

Reading rotary encoder on Arduino:
http://www.circuitsathome.com/mcu/reading-rotary-encoder-on-arduino/


body:
There exists a large variety of sensors in the [Grove System][1]. Usually these are accessed via a special shield (Grove base shield).

Can I access these sensor directly without a shield. In particular I am interested in using them with an Arduino Pro Mini. My guess is that one definitely needs the 5V version of the Mini, but other than this? How fiddly is it to use these sensors directly?

I am interested in using the [Grove dust sensor][2], but I am also would like to operate a [Grove 4 digit display][3].

  [1]: http://www.seeedstudio.com/wiki/GROVE_System
  [2]: http://www.seeedstudio.com/wiki/Grove_-_Dust_Sensor
  [3]: http://www.seeedstudio.com/wiki/Grove_-_4-Digit_Display

title: Grove sensors without a Grove shield

Answers: 3

body:
Grove sensors use a special socket, a 4 pin JST with two power lines and two data. you would have to make your own board/terminal to get them to connect to a mini.

What you could do is use a [Grove proto board](http://www.seeedstudio.com/wiki/Grove_-_Protoshield), which converts the JST terminals onto .1" pins suitable for connecting to the Mini. There is also a litle proto area if you want it.

You could also use an [adapter cable](http://www.seeedstudio.com/depot/grove-to-4-pin-254-female-jumper-wire5-pcs-pack-p-1020.html?cPath=178_179), which would not have a bulky protoboard along with it. The terminals could be soldered directly to the Mini.

body:
![Groove Schematic][1]
*[From the wiki](http://www.seeedstudio.com/wiki/File:Stem-diagram-sign.jpg)*.

Above is a schematic of a Groove shield. You can see that each of the connectors has two digital pins connected to it and then V (5V) and G (GND). The last two you can connect normally to an Arduino. The first two you connect to the pins that are used in your sketch.

Say it says to connect the connector to the top left DIGITAL pin on the board (D6/D7). You'll 7want to connect the pins as followed: Black → GND, Red → 5V, White → D7, and Yellow → D6.
****
Notes:

 - The shield overlaps the pins (i.e. 3-4, 4-5), so that might make things confusing. I think that is a design flaw. If it needs two pins, *it should have two connectors*. In the current state, you can connect two things together. **I don't really know how to figure out if it uses all of the ports attached or not. If you don't have to, I would try not to overlap any two grooves.** You would do this by using two digital ports for every groove "module."
 - **You'll also need to have a [adapter cable](http://www.seeedstudio.com/depot/grove-to-4-pin-254-female-jumper-wire5-pcs-pack-p-1020.html?cPath=178_179) (Link from *TheDoctor's* Answer.)**
 - For analog connections, it applies the same way as digital. G is ground, V is 5v, and A# is an analog pin.

****
## Inferencing it:
There's no real cookie cutter way to connect to them. However, the [wiki](http://www.seeedstudio.com/wiki/GROVE_System) seems to be a decent resource once you figure out how to navigate it. The [dust sensor you mentioned](http://www.seeedstudio.com/wiki/Grove_-_Dust_Sensor) seems to ONLY use digital pin 8. It was connected to the D7/D8 connector on the Groove shield, so the yellow wire could be ignored since it was never used in the sketch.

It's hard to do much with this system: it's poorly documented and not uniform at all. Plus, some boards could cause problems that could even lead to damaging components. I would say look at something else.

 - [This dust sensor](https://www.sparkfun.com/products/9689) seems pretty good, minus the documentation. On [this blog](https://www.sparkfun.com/products/9689), they say to do this:

> Sharp pin 1 (V-LED)   => 5V (connected to 150ohm resister) Sharp pin 2
>
> (LED-GND) => Arduino GND pin Sharp pin 3 (LED)     => Arduino pin 2
>
> Sharp pin 4 (S-GND)   => Arduino GND pin Sharp pin 5 (Vo)      =>
>
> Arduino A0 pin Sharp pin 6 (Vcc)     => 5V

I can't seem to find the cord for it, but I'm sure there are many others like this online. (It lists the cable needed: a 6-pin, 1.5mm pitch connector. That doesn't seem too hard to find).

 - Here is a [4x7 segment display](https://www.sparkfun.com/products/9483) for much cheaper. It does use a lot of pins and need resistors, but multiplexing and resistors aren't that hard to figure out. That's outside of the scope of this question. There might be some other board with a built in IC for controlling a display like that, but I can't seem to find one now.

  [1]: https://i.stack.imgur.com/vxc2g.jpg

body: I'm pretty sure you could just take the signal cable from the dust sensor and plug it directly into your mcu digital pin of choice and then wire the Vcc and Gnd as well.  I'm working with a CO2 sensor and don't really want the shield overhead.


body:
I have a problem with my Arduino. I can't upload any sketches to it (it gives me the error `avrdude: verification error; content mismatch`), but the LEDs are still blinking. Do you think that the whole Arduino is dead or is it just the chip ?

EDIT : I tried an other USB cable but it changed nothing.

EDIT : Here is the output of verbose mode while uploading :

    Taille binaire du croquis : 1 084 octets (d'un max de 32 256 octets)
    /Applications/Arduino.app/Contents/Resources/Java/hardware/tools/avr/bin/avrdude -C/Applications/Arduino.app/Contents/Resources/Java/hardware/tools/avr/etc/avrdude.conf -v -v -v -v -patmega328p -carduino -P/dev/cu.usbmodem641 -b115200 -D -Uflash:w:/var/folders/56/7b6d3xm14n31kjrw8609ywjw0000gn/T/build1168987322216849272.tmp/Blink.cpp.hex:i

    avrdude: Version 5.11, compiled on Sep  2 2011 at 18:52:52
             Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/
             Copyright (c) 2007-2009 Joerg Wunsch

             System wide configuration file is "/Applications/Arduino.app/Contents/Resources/Java/hardware/tools/avr/etc/avrdude.conf"
             User configuration file is "/Users/trevorannedenise/.avrduderc"
             User configuration file does not exist or is not a regular file, skipping

             Using Port                    : /dev/cu.usbmodem641
             Using Programmer              : arduino
             Overriding Baud Rate          : 115200
    avrdude: Send: 0 [30]   [20]
    avrdude: Send: 0 [30]   [20]
    avrdude: Send: 0 [30]   [20]
    avrdude: Recv: . [14]
    avrdude: Recv: . [10]
             AVR Part                      : ATMEGA328P
             Chip Erase delay              : 9000 us
             PAGEL                         : PD7
             BS2                           : PC2
             RESET disposition             : dedicated
             RETRY pulse                   : SCK
             serial program mode           : yes
             parallel program mode         : yes
             Timeout                       : 200
             StabDelay                     : 100
             CmdexeDelay                   : 25
             SyncLoops                     : 32
             ByteDelay                     : 0
             PollIndex                     : 3
             PollValue                     : 0x53
             Memory Detail                 :

                                      Block Poll               Page                       Polled
               Memory Type Mode Delay Size  Indx Paged  Size   Size #Pages MinW  MaxW   ReadBack
               ----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
               eeprom        65    20     4    0 no       1024    4      0  3600  3600 0xff 0xff
                                      Block Poll               Page                       Polled
               Memory Type Mode Delay Size  Indx Paged  Size   Size #Pages MinW  MaxW   ReadBack
               ----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
               flash         65     6   128    0 yes     32768  128    256  4500  4500 0xff 0xff
                                      Block Poll               Page                       Polled
               Memory Type Mode Delay Size  Indx Paged  Size   Size #Pages MinW  MaxW   ReadBack
               ----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
               lfuse          0     0     0    0 no          1    0      0  4500  4500 0x00 0x00
                                      Block Poll               Page                       Polled
               Memory Type Mode Delay Size  Indx Paged  Size   Size #Pages MinW  MaxW   ReadBack
               ----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
               hfuse          0     0     0    0 no          1    0      0  4500  4500 0x00 0x00
                                      Block Poll               Page                       Polled
               Memory Type Mode Delay Size  Indx Paged  Size   Size #Pages MinW  MaxW   ReadBack
               ----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
               efuse          0     0     0    0 no          1    0      0  4500  4500 0x00 0x00
                                      Block Poll               Page                       Polled
               Memory Type Mode Delay Size  Indx Paged  Size   Size #Pages MinW  MaxW   ReadBack
               ----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
               lock           0     0     0    0 no          1    0      0  4500  4500 0x00 0x00
                                      Block Poll               Page                       Polled
               Memory Type Mode Delay Size  Indx Paged  Size   Size #Pages MinW  MaxW   ReadBack
               ----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
               calibration    0     0     0    0 no          1    0      0     0     0 0x00 0x00
                                      Block Poll               Page                       Polled
               Memory Type Mode Delay Size  Indx Paged  Size   Size #Pages MinW  MaxW   ReadBack
               ----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
               signature      0     0     0    0 no          3    0      0     0     0 0x00 0x00

             Programmer Type : Arduino
             Description     : Arduino
    avrdude: Send: A [41] . [80]   [20]
    avrdude: Recv: . [14]
    avrdude: Recv: . [03]
    avrdude: Recv: . [10]
    avrdude: Send: A [41] . [81]   [20]
    avrdude: Recv: . [14]
    avrdude: Recv: . [04]
    avrdude: Recv: . [10]
    avrdude: Send: A [41] . [82]   [20]
    avrdude: Recv: . [14]
    avrdude: Recv: . [04]
    avrdude: Recv: . [10]
    avrdude: Send: A [41] . [98]   [20]
    avrdude: Recv: . [14]
    avrdude: Recv: . [03]
    avrdude: Recv: . [10]
             Hardware Version: 3
             Firmware Version: 4.4
    avrdude: Send: A [41] . [84]   [20]
    avrdude: Recv: . [14]
    avrdude: Recv: . [03]
    avrdude: Recv: . [10]
    avrdude: Send: A [41] . [85]   [20]
    avrdude: Recv: . [14]
    avrdude: Recv: . [03]
    avrdude: Recv: . [10]
    avrdude: Send: A [41] . [86]   [20]
    avrdude: Recv: . [14]
    avrdude: Recv: . [03]
    avrdude: Recv: . [10]
    avrdude: Send: A [41] . [87]   [20]
    avrdude: Recv: . [14]
    avrdude: Recv: . [03]
    avrdude: Recv: . [10]
    avrdude: Send: A [41] . [89]   [20]
    avrdude: Recv: . [14]
    avrdude: Recv: . [03]
    avrdude: Recv: . [10]
             Vtarget         : 0.3 V
             Varef           : 0.3 V
             Oscillator      : 28.800 kHz
             SCK period      : 3.3 us

    avrdude: Send: A [41] . [81]   [20]
    avrdude: Recv: . [14]
    avrdude: Recv: . [04]
    avrdude: Recv: . [10]
    avrdude: Send: A [41] . [82]   [20]
    avrdude: Recv: . [14]
    avrdude: Recv: . [04]
    avrdude: Recv: . [10]
    avrdude: Send: B [42] . [86] . [00] . [00] . [01] . [01] . [01] . [01] . [03] . [ff] . [ff] . [ff] . [ff] . [00] . [80] . [04] . [00] . [00] . [00] . [80] . [00]   [20]
    avrdude: Recv: . [14]
    avrdude: Recv: . [10]
    avrdude: Send: E [45] . [05] . [04] . [d7] . [c2] . [00]   [20]
    avrdude: Recv: . [14]
    avrdude: Recv: . [10]
    avrdude: Send: P [50]   [20]
    avrdude: Recv: . [14]
    avrdude: Recv: . [10]
    avrdude: AVR device initialized and ready to accept instructions

    Reading | avrdude: Send: u [75]   [20]
    avrdude: Recv: . [14] . [1e] . [95] . [0f] . [10]
    ################################################## | 100% 0.00s

    avrdude: Device signature = 0x1e950f
    avrdude: Send: V [56] . [a0] . [03] . [fc] . [00]   [20]
    avrdude: Recv: . [14]
    avrdude: Recv: . [00]
    avrdude: Recv: . [10]
    avrdude: Send: V [56] . [a0] . [03] . [fd] . [00]   [20]
    avrdude: Recv: . [14]
    avrdude: Recv: . [00]
    avrdude: Recv: . [10]
    avrdude: Send: V [56] . [a0] . [03] . [fe] . [00]   [20]
    avrdude: Recv: . [14]
    avrdude: Recv: . [00]
    avrdude: Recv: . [10]
    avrdude: Send: V [56] . [a0] . [03] . [ff] . [00]   [20]
    avrdude: Recv: . [14]
    avrdude: Recv: . [00]
    avrdude: Recv: . [10]
    avrdude: reading input file "/var/folders/56/7b6d3xm14n31kjrw8609ywjw0000gn/T/build1168987322216849272.tmp/Blink.cpp.hex"
    avrdude: writing flash (1084 bytes):

    Writing | avrdude: Send: U [55] . [00] . [00]   [20]
    avrdude: Recv: . [14]
    avrdude: Recv: . [10]
    avrdude: Send: d [64] . [00] . [80] F [46] . [0c] . [94] a [61] . [00] . [0c] . [94] ~ [7e] . [00] . [0c] . [94] ~ [7e] . [00] . [0c] . [94] ~ [7e] . [00] . [0c] . [94] ~ [7e] . [00] . [0c] . [94] ~ [7e] . [00] . [0c] . [94] ~ [7e] . [00] . [0c] . [94] ~ [7e] . [00] . [0c] . [94] ~ [7e] . [00] . [0c] . [94] ~ [7e] . [00] . [0c] . [94] ~ [7e] . [00] . [0c] . [94] ~ [7e] . [00] . [0c] . [94] ~ [7e] . [00] . [0c] . [94] ~ [7e] . [00] . [0c] . [94] ~ [7e] . [00] . [0c] . [94] ~ [7e] . [00] . [0c] . [94] . [9d] . [00] . [0c] . [94] ~ [7e] . [00] . [0c] . [94] ~ [7e] . [00] . [0c] . [94] ~ [7e] . [00] . [0c] . [94] ~ [7e] . [00] . [0c] . [94] ~ [7e] . [00] . [0c] . [94] ~ [7e] . [00] . [0c] . [94] ~ [7e] . [00] . [0c] . [94] ~ [7e] . [00] . [0c] . [94] ~ [7e] . [00] . [00] . [00] . [00] . [00] $ [24] . [00] ' [27] . [00] * [2a] . [00] . [00] . [00] . [00] . [00] % [25] . [00] ( [28] . [00] + [2b] . [00] . [00] . [00] . [00] . [00]   [20]
    avrdude: Recv: . [14]
    avrdude: Recv: . [10]
    #####avrdude: Send: U [55] @ [40] . [00]   [20]
    avrdude: Recv: . [14]
    avrdude: Recv: . [10]
    avrdude: Send: d [64] . [00] . [80] F [46] # [23] . [00] & [26] . [00] ) [29] . [00] . [04] . [04] . [04] . [04] . [04] . [04] . [04] . [04] . [02] . [02] . [02] . [02] . [02] . [02] . [03] . [03] . [03] . [03] . [03] . [03] . [01] . [02] . [04] . [08] . [10]   [20] @ [40] . [80] . [01] . [02] . [04] . [08] . [10]   [20] . [01] . [02] . [04] . [08] . [10]   [20] . [00] . [00] . [00] . [07] . [00] . [02] . [01] . [00] . [00] . [03] . [04] . [06] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [11] $ [24] . [1f] . [be] . [cf] . [ef] . [d8] . [e0] . [de] . [bf] . [cd] . [bf] . [11] . [e0] . [a0] . [e0] . [b1] . [e0] . [ea] . [e3] . [f4] . [e0] . [02] . [c0] . [05] . [90] . [0d] . [92] . [a2] 0 [30] . [b1] . [07] . [d9] . [f7] . [11] . [e0] . [a2] . [e0] . [b1] . [e0] . [01] . [c0] . [1d] . [92] . [ab] 0 [30] . [b1] . [07] . [e1] . [f7] . [0e] . [94] . [0c] . [02] . [0c] . [94] . [1b] . [02] . [0c] . [94] . [00] . [00]   [20]
    avrdude: Recv: . [14]
    avrdude: Recv: . [10]
    ######avrdude: Send: U [55] . [80] . [00]   [20]
    avrdude: Recv: . [14]
    avrdude: Recv: . [10]
    avrdude: Send: d [64] . [00] . [80] F [46] . [80] . [91] . [00] . [01] a [61] . [e0] . [0e] . [94] . [b8] . [01] h [68] . [ee] s [73] . [e0] . [80] . [e0] . [90] . [e0] . [0e] . [94] . [e5] . [00] . [80] . [91] . [00] . [01] ` [60] . [e0] . [0e] . [94] . [b8] . [01] h [68] . [ee] s [73] . [e0] . [80] . [e0] . [90] . [e0] . [0e] . [94] . [e5] . [00] . [08] . [95] . [80] . [91] . [00] . [01] a [61] . [e0] . [0e] . [94] y [79] . [01] . [08] . [95] . [1f] . [92] . [0f] . [92] . [0f] . [b6] . [0f] . [92] . [11] $ [24] / [2f] . [93] ? [3f] . [93] . [8f] . [93] . [9f] . [93] . [af] . [93] . [bf] . [93] . [80] . [91] . [06] . [01] . [90] . [91] . [07] . [01] . [a0] . [91] . [08] . [01] . [b0] . [91] . [09] . [01] 0 [30] . [91] . [0a] . [01] . [01] . [96] . [a1] . [1d] . [b1] . [1d] # [23] / [2f] - [2d] _ [5f] - [2d] 7 [37]   [20] . [f0] - [2d] W [57] . [01] . [96] . [a1] . [1d] . [b1] . [1d]   [20] . [93] . [0a] . [01] . [80] . [93]   [20]
    avrdude: Recv: . [14]
    avrdude: Recv: . [10]
    ######avrdude: Send: U [55] . [c0] . [00]   [20]
    avrdude: Recv: . [14]
    avrdude: Recv: . [10]
    avrdude: Send: d [64] . [00] . [80] F [46] . [06] . [01] . [90] . [93] . [07] . [01] . [a0] . [93] . [08] . [01] . [b0] . [93] . [09] . [01] . [80] . [91] . [02] . [01] . [90] . [91] . [03] . [01] . [a0] . [91] . [04] . [01] . [b0] . [91] . [05] . [01] . [01] . [96] . [a1] . [1d] . [b1] . [1d] . [80] . [93] . [02] . [01] . [90] . [93] . [03] . [01] . [a0] . [93] . [04] . [01] . [b0] . [93] . [05] . [01] . [bf] . [91] . [af] . [91] . [9f] . [91] . [8f] . [91] ? [3f] . [91] / [2f] . [91] . [0f] . [90] . [0f] . [be] . [0f] . [90] . [1f] . [90] . [18] . [95] . [9b] . [01] . [ac] . [01] . [7f] . [b7] . [f8] . [94] . [80] . [91] . [02] . [01] . [90] . [91] . [03] . [01] . [a0] . [91] . [04] . [01] . [b0] . [91] . [05] . [01] f [66] . [b5] . [a8] . [9b] . [05] . [c0] o [6f] ? [3f] . [19] . [f0] . [01] . [96] . [a1] . [1d] . [b1] . [1d] . [7f] . [bf] . [ba] / [2f] . [a9] / [2f] . [98] / [2f] . [88] ' [27] . [86] . [0f] . [91] . [1d]   [20]
    avrdude: Recv: . [14]
    avrdude: Recv: . [10]
    ######avrdude: Send: U [55] . [00] . [01]   [20]
    avrdude: Recv: . [14]
    avrdude: Recv: . [10]
    avrdude: Send: d [64] . [00] . [80] F [46] . [a1] . [1d] . [b1] . [1d] b [62] . [e0] . [88] . [0f] . [99] . [1f] . [aa] . [1f] . [bb] . [1f] j [6a] . [95] . [d1] . [f7] . [bc] . [01] - [2d] . [c0] . [ff] . [b7] . [f8] . [94] . [80] . [91] . [02] . [01] . [90] . [91] . [03] . [01] . [a0] . [91] . [04] . [01] . [b0] . [91] . [05] . [01] . [e6] . [b5] . [a8] . [9b] . [05] . [c0] . [ef] ? [3f] . [19] . [f0] . [01] . [96] . [a1] . [1d] . [b1] . [1d] . [ff] . [bf] . [ba] / [2f] . [a9] / [2f] . [98] / [2f] . [88] ' [27] . [8e] . [0f] . [91] . [1d] . [a1] . [1d] . [b1] . [1d] . [e2] . [e0] . [88] . [0f] . [99] . [1f] . [aa] . [1f] . [bb] . [1f] . [ea] . [95] . [d1] . [f7] . [86] . [1b] . [97] . [0b] . [88] ^ [5e] . [93] @ [40] . [c8] . [f2] ! [21] P [50] 0 [30] @ [40] @ [40] @ [40] P [50] @ [40] h [68] Q [51] | [7c] O [4f] ! [21] . [15] 1 [31] . [05] A [41] . [05] Q [51] . [05] q [71] . [f6] . [08] . [95] x [78] . [94] . [84] . [b5]   [20]
    avrdude: Recv: . [14]
    avrdude: Recv: . [10]
    ######avrdude: Send: U [55] @ [40] . [01]   [20]
    avrdude: Recv: . [14]
    avrdude: Recv: . [10]
    avrdude: Send: d [64] . [00] . [80] F [46] . [82] ` [60] . [84] . [bd] . [84] . [b5] . [81] ` [60] . [84] . [bd] . [85] . [b5] . [82] ` [60] . [85] . [bd] . [85] . [b5] . [81] ` [60] . [85] . [bd] . [ee] . [e6] . [f0] . [e0] . [80] . [81] . [81] ` [60] . [80] . [83] . [e1] . [e8] . [f0] . [e0] . [10] . [82] . [80] . [81] . [82] ` [60] . [80] . [83] . [80] . [81] . [81] ` [60] . [80] . [83] . [e0] . [e8] . [f0] . [e0] . [80] . [81] . [81] ` [60] . [80] . [83] . [e1] . [eb] . [f0] . [e0] . [80] . [81] . [84] ` [60] . [80] . [83] . [e0] . [eb] . [f0] . [e0] . [80] . [81] . [81] ` [60] . [80] . [83] . [ea] . [e7] . [f0] . [e0] . [80] . [81] . [84] ` [60] . [80] . [83] . [80] . [81] . [82] ` [60] . [80] . [83] . [80] . [81] . [81] ` [60] . [80] . [83] . [80] . [81] . [80] h [68] . [80] . [83] . [10] . [92] . [c1] . [00] . [08] . [95] . [cf] . [93] . [df] . [93] H [48] / [2f] P [50] . [e0] . [ca] . [01] . [86] V [56] . [9f] O [4f]   [20]
    avrdude: Recv: . [14]
    avrdude: Recv: . [10]
    ######avrdude: Send: U [55] . [80] . [01]   [20]
    avrdude: Recv: . [14]
    avrdude: Recv: . [10]
    avrdude: Send: d [64] . [00] . [80] F [46] . [fc] . [01] 4 [34] . [91] J [4a] W [57] _ [5f] O [4f] . [fa] . [01] . [84] . [91] . [88] # [23] i [69] . [f1] . [90] . [e0] . [88] . [0f] . [99] . [1f] . [fc] . [01] . [e8] Y [59] . [ff] O [4f] . [a5] . [91] . [b4] . [91] . [fc] . [01] . [ee] X [58] . [ff] O [4f] . [c5] . [91] . [d4] . [91] f [66] # [23] Q [51] . [f4] / [2f] . [b7] . [f8] . [94] . [8c] . [91] . [93] / [2f] . [90] . [95] . [89] # [23] . [8c] . [93] . [88] . [81] . [89] # [23] . [0b] . [c0] b [62] 0 [30] a [61] . [f4] / [2f] . [b7] . [f8] . [94] . [8c] . [91] . [93] / [2f] . [90] . [95] . [89] # [23] . [8c] . [93] . [88] . [81] . [83] + [2b] . [88] . [83] / [2f] . [bf] . [06] . [c0] . [9f] . [b7] . [f8] . [94] . [8c] . [91] . [83] + [2b] . [8c] . [93] . [9f] . [bf] . [df] . [91] . [cf] . [91] . [08] . [95] H [48] / [2f] P [50] . [e0] . [ca] . [01] . [82] U [55] . [9f] O [4f] . [fc] . [01] $ [24] . [91] . [ca] . [01]   [20]
    avrdude: Recv: . [14]
    avrdude: Recv: . [10]
    ######avrdude: Send: U [55] . [c0] . [01]   [20]
    avrdude: Recv: . [14]
    avrdude: Recv: . [10]
    avrdude: Send: d [64] . [00] . [80] F [46] . [86] V [56] . [9f] O [4f] . [fc] . [01] . [94] . [91] J [4a] W [57] _ [5f] O [4f] . [fa] . [01] 4 [34] . [91] 3 [33] # [23] . [09] . [f4] @ [40] . [c0] " [22] # [23] Q [51] . [f1] # [23] 0 [30] q [71] . [f0] $ [24] 0 [30] ( [28] . [f4] ! [21] 0 [30] . [a1] . [f0] " [22] 0 [30] . [11] . [f5] . [14] . [c0] & [26] 0 [30] . [b1] . [f0] ' [27] 0 [30] . [c1] . [f0] $ [24] 0 [30] . [d9] . [f4] . [04] . [c0] . [80] . [91] . [80] . [00] . [8f] w [77] . [03] . [c0] . [80] . [91] . [80] . [00] . [8f] } [7d] . [80] . [93] . [80] . [00] . [10] . [c0] . [84] . [b5] . [8f] w [77] . [02] . [c0] . [84] . [b5] . [8f] } [7d] . [84] . [bd] . [09] . [c0] . [80] . [91] . [b0] . [00] . [8f] w [77] . [03] . [c0] . [80] . [91] . [b0] . [00] . [8f] } [7d] . [80] . [93] . [b0] . [00] . [e3] / [2f] . [f0] . [e0] . [ee] . [0f] . [ff] . [1f] . [ee] X [58] . [ff] O [4f] . [a5] . [91] . [b4] . [91] / [2f] . [b7]   [20]
    avrdude: Recv: . [14]
    avrdude: Recv: . [10]
    ######avrdude: Send: U [55] . [00] . [02]   [20]
    avrdude: Recv: . [14]
    avrdude: Recv: . [10]
    avrdude: Send: d [64] . [00] < [3c] F [46] . [f8] . [94] f [66] # [23] ! [21] . [f4] . [8c] . [91] . [90] . [95] . [89] # [23] . [02] . [c0] . [8c] . [91] . [89] + [2b] . [8c] . [93] / [2f] . [bf] . [08] . [95] . [cf] . [93] . [df] . [93] . [0e] . [94] > [3e] . [01] . [0e] . [94] . [97] . [00] . [c0] . [e0] . [d0] . [e0] . [0e] . [94] . [80] . [00]   [20] . [97] . [e1] . [f3] . [0e] . [94] . [00] . [00] . [f9] . [cf] . [f8] . [94] . [ff] . [cf] . [0d] . [00]   [20]
    avrdude: Recv: . [14]
    avrdude: Recv: . [10]
    ### | 100% 0.21s

    avrdude: 1084 bytes of flash written
    avrdude: verifying flash memory against /var/folders/56/7b6d3xm14n31kjrw8609ywjw0000gn/T/build1168987322216849272.tmp/Blink.cpp.hex:
    avrdude: load data flash data from input file /var/folders/56/7b6d3xm14n31kjrw8609ywjw0000gn/T/build1168987322216849272.tmp/Blink.cpp.hex:
    avrdude: input file /var/folders/56/7b6d3xm14n31kjrw8609ywjw0000gn/T/build1168987322216849272.tmp/Blink.cpp.hex contains 1084 bytes
    avrdude: reading on-chip flash data:

    Reading | avrdude: Send: U [55] . [00] . [00]   [20]
    avrdude: Recv: . [14]
    avrdude: Recv: . [10]
    avrdude: Send: t [74] . [00] . [80] F [46]   [20]
    avrdude: Recv: . [14]
    avrdude: Recv: . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff]
    avrdude: Recv: . [10]
    #####avrdude: Send: U [55] @ [40] . [00]   [20]
    avrdude: Recv: . [14]
    avrdude: Recv: . [10]
    avrdude: Send: t [74] . [00] . [80] F [46]   [20]
    avrdude: Recv: . [14]
    avrdude: Recv: . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff]
    avrdude: Recv: . [10]
    ######avrdude: Send: U [55] . [80] . [00]   [20]
    avrdude: Recv: . [14]
    avrdude: Recv: . [10]
    avrdude: Send: t [74] . [00] . [80] F [46]   [20]
    avrdude: Recv: . [14]
    avrdude: Recv: . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff]
    avrdude: Recv: . [10]
    ######avrdude: Send: U [55] . [c0] . [00]   [20]
    avrdude: Recv: . [14]
    avrdude: Recv: . [10]
    avrdude: Send: t [74] . [00] . [80] F [46]   [20]
    avrdude: Recv: . [14]
    avrdude: Recv: . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff]
    avrdude: Recv: . [10]
    ######avrdude: Send: U [55] . [00] . [01]   [20]
    avrdude: Recv: . [14]
    avrdude: Recv: . [10]
    avrdude: Send: t [74] . [00] . [80] F [46]   [20]
    avrdude: Recv: . [14]
    avrdude: Recv: . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff]
    avrdude: Recv: . [10]
    ######avrdude: Send: U [55] @ [40] . [01]   [20]
    avrdude: Recv: . [14]
    avrdude: Recv: . [10]
    avrdude: Send: t [74] . [00] . [80] F [46]   [20]
    avrdude: Recv: . [14]
    avrdude: Recv: . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff]
    avrdude: Recv: . [10]
    ######avrdude: Send: U [55] . [80] . [01]   [20]
    avrdude: Recv: . [14]
    avrdude: Recv: . [10]
    avrdude: Send: t [74] . [00] . [80] F [46]   [20]
    avrdude: Recv: . [14]
    avrdude: Recv: . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff]
    avrdude: Recv: . [10]
    ######avrdude: Send: U [55] . [c0] . [01]   [20]
    avrdude: Recv: . [14]
    avrdude: Recv: . [10]
    avrdude: Send: t [74] . [00] . [80] F [46]   [20]
    avrdude: Recv: . [14]
    avrdude: Recv: . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff]
    avrdude: Recv: . [10]
    ######avrdude: Send: U [55] . [00] . [02]   [20]
    avrdude: Recv: . [14]
    avrdude: Recv: . [10]
    avrdude: Send: t [74] . [00] < [3c] F [46]   [20]
    avrdude: Recv: . [14]
    avrdude: Recv: . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff] . [ff]
    avrdude: Recv: . [10]
    ### | 100% 0.16s

    avrdude: verifying ...
    avrdude: verification error, first mismatch at byte 0x0000
             0x0c != 0xff
    avrdude: verification error; content mismatch
    avrdude: Send: Q [51]   [20]
    avrdude: Recv: . [14]
    avrdude: Recv: . [10]

    avrdude done.  Thank you.

title: Is my Arduino dead or is it just its processor?

Answers: 4

body:
It's possible you have a non-fatal problem

 - check power
 - check connections
 - reflash the Arduino bootloader

If your Arduino has a socketed microcontroller you can try swapping it out with one that has the bootloader preloaded.

body:
I've faced this problem several times!
If you are using arduino UNO, make sure to remove any serial connected device on the (Tx,RX) pins. Upload your sketch, then connect them back again.
It's because the arduino UNO has on serial pins which is used for uploading the code, there will be a conflict if there was a device that is connected to the serial the same time you upload the code.

body:
This happened to me with a bare-bones Arduino. I disconnected everything and it still happens. I don't know what the cause is but you definitely will need to reflash the bootloader or replace the chip.

It isn't a connection or power issue, and it isn't related to having devices connected to pins 0/1 (although that can also cause problems, it will give a different error).

body: I had faced similar problems and the solution that worked for me was to power the burning circuit with the Arduino onboard 5 volt. 3.3 Volt does work but at times it gives these errors especially while burning the bootloader.


body:
I have an Arduino motor shield like this one plugged into my Mega board.

![Arduino motor shield][1]

I would like to know some more information about the orange and white pin blocks on the board. The [Arduino website][2] has the following information, but it doesn't give any explanation of what is best to use them for or which pins are mapped to the data pins etc.

 - TinkerKit connectors for two Analog Inputs (in white), connected to A2 and A3.
 - TinkerKit connectors for two Aanlog Outputs (in orange in the middle), connected to PWM outputs on pins D5 and D6.
 - TinkerKit connectors for the TWI interface (in white with 4 pins), one for input and the other one for output.

What I want to do is connect a servo up to the board and was hoping I could use one of the orange `OUT` blocks. I haven't been successful in finding any examples of this which leaves me in doubt as to whether it is possible or not. I would just plug it in, but I'm afraid of frying the shield/mega/servo. Probably an irrational fear, but I can't afford another one of any at the moment!

I don't know which pins in the block are assigned to the data, vcc and out, so if anyone know I would be grateful for the answer.

Also, just because it is annoying not to understand, what are the `TWI` connectors for?

I hope this isn't too general a question as I could really use some answers!

  [1]: https://i.stack.imgur.com/cKBqi.jpg
  [2]: http://arduino.cc/en/Main/ArduinoMotorShieldR3#.UxXT9vl_skI

title: Arduino motor shield orange/white pin usage

Answers: 4

body:
> I don't know which pins in the block are assigned to the data, vcc and
> out, so if anyone know I would be grateful for the answer.

Following the example on [TinkerKit's Custom Distance Sensor][1] page, we see that:

> If you look on the edge of the sensor, you can see the three pins,
> that are power (5V), ground and signal. The same as your TinkerKit!
> modules, just in a different order.
>
> The only difference is that the signal and ground cable are inverted.

So the order in the connector is Vcc Signal Ground.

Another way, and what I would do to be 100% sure, is measure resistance with a multimeter. If your meter has a continuity test feature, that's even better because it'll beep.

Anyway, put one end of the probe on pin 1 of the connector and the other end on GND and see if the resistance is very close to 0 ohms. If it's reading OL (Over-Limit) then that pin is not GND.

Put the probe on Vcc instead and it should show 0 ohm or beep. So now you know that pin is Vcc.

Do the same for the other pins and find out which one is ground. The third pin is your PWM output. It's connected to D5 or D6, check the continuity on those pins to see which one.

  [1]: http://www.tinkerkit.com/custom-distance-sensor/

body:
>...which pins are mapped to the data pins etc.

The shield page provides a [schematic](http://arduino.cc/en/uploads/Main/arduino_MotorShield_Rev3-schematic.pdf)

>I would like to know some more information about the orange and white pin blocks on the board

These have the reference printed on the board
![enter image description here][1]

----------

# TWI IN and TWI OUT #
They are the same and are both connected to the same I2C pins of Arduino (SCL, SDA). They are intended to help in case you want to connect more than one device.
![enter image description here][4]

----------

# OUT 5, OUT 6 #
Connected to Arduino pins 5 and 6 (PWM outputs)

![enter image description here][2]

----------

# IN 2, IN 3 #
Connected to Analog in A2 and A3

![enter image description here][3]

----------

The power outputs of [L298](http://www.st.com/st-web-ui/static/active/en/resource/technical/document/datasheet/CD00000240.pdf) intended to drive the motor are the blue screw connectors.

![enter image description here][5]

  [1]: https://i.stack.imgur.com/H7mnt.jpg
  [2]: https://i.stack.imgur.com/5YY7w.jpg
  [3]: https://i.stack.imgur.com/AK2nq.jpg
  [4]: https://i.stack.imgur.com/bAIkc.jpg
  [5]: https://i.stack.imgur.com/9zRaY.jpg

body:
You can use Thinkerkit pins(out ~5 and ~6) for controlling servos. Just need to do a bit of tweaking here. Hobby servo motors have got 3 pins orange(signal) , red(live+) in the middle, and brown(gnd-). But, the motor shield rev3 uses the middle pin for signal. To overcome this problem, swap the middle wire with the orange one on the servo plug.

There are three small latches that prevent wires coming out of the plug, use the tip of a needle and with little force slightly lift them up then pull out the wires from the servo plug, they should come off easily.

Remember to attach pin 5 or 6 in the arduino code. I used servo.h library.

body: Although the 'Orange' (Out) pins of the Deek-Robot Motor Shield can be used to drive a servo by swapping the '+5vdc' and 'Signal' wires at the servo harness plug it is best to not do as this.  This is because the current drive for the servo is drawn from the Arduino UNO.  Given that an individual servo can draw well in access of 125ma the current draw may/will exceed the current sink limitations of the associated Arduino UNO circuitry. It is best to use an external power source, properly filtered for electrical noise, as the current source for the servo(s).  This has been documented/recommended in multiple information sources.


body:
In this [code][1] for heating monitor, there appears to be macros called `FLASH_ARRAY` and `FLASH_TABLE`. I can't find any reference to them either in this code, Arduino, or on the Internet. What do they do?

    FLASH_ARRAY(byte, VARIABLE_DEVICE_TABLE,
        DEVICE_LADDNING_RETUR,
        DEVICE_LADDNING_UT,
        DEVICE_TANK1,
        DEVICE_TANK2,
        ...
        VARIABLE_ID_LOAD,
        VARIABLE_ID_TIME_EMPTY);

and

    FLASH_TABLE(byte, NUMBER_TEMP_TABLE, 7,
      {DEVICE_LADDNING_RETUR, 99,  5, 10,  7, MAIN_TYPE_TEXT_CELCIUS, 2},
      {DEVICE_LADDNING_UT,    99, 43, 10,  7, MAIN_TYPE_TEXT_CELCIUS, 2},
      ...
      {DEVICE_UTE,             0, 55, 15,  7, MAIN_TYPE_TEXT_CELCIUS_WITH_NEGATIVE, 103},
      {VARIABLE_ID_EFFECT,   114, 29, 10,  7, MAIN_TYPE_TEXT_VARIABLE, 2});

  [1]: https://code.google.com/p/heating-monitor/source/browse/HeatingMonitor/consts.h

title: What are the FLASH_ARRAY/FLASH_TABLE macros in this code?

Answers: 2

body:
After further digging, this appears to be from Mikal Hart's [Flash library][1].

The reason this library was developed is:

> Storing static program data in flash/PROGMEM is a tricky part of
> Arduino programming. To save precious RAM, a novice user already at
> odds with unfamiliar C++ syntax must digest such daunting concepts as
> prog_char, PSTR(), PROGMEM, pgm_read_word(), etc. Even seasoned users
> get tripped up by the indirection and typecasting that are required to
> retrieve valid PROGMEM data. Add to that a couple of apparent bugs in
> the implementation, and it’s clear that PROGMEM is a complicated mess.
>
> I have written a new library, Flash, which abstracts away most of this
> complexity. It provides new String, Array, Table, and String Array
> types that make ROM-based data collections as easy to use as “normal”
> types. Each overrides the C++ [] operator, so to extract individual
> elements one uses familiar array access syntax:

Specifically, these are macros and a simple helper class to make it easier to create arrays and tables of values in program memory.

The two macros are declared as so:

    // Example: FLASH_ARRAY(float, temperatures, 98.1, 98.5, 99.1, 102.1);
    #define FLASH_ARRAY(type, name, values...) \
      static const type name##_flash[] PROGMEM = { values }; \
      _FLASH_ARRAY<type> name(name##_flash, sizeof(name##_flash) / sizeof(type));

    // Example: FLASH_TABLE(uint8_t, fonts, 7, {ON, OFF, ON, ON, OFF, ON, OFF}, {OFF, ON, OFF, ON, OFF, ON, OFF});
    #define FLASH_TABLE(type, name, cols, values...) \
      static const type name##_flash[][cols] PROGMEM = { values }; \
      _FLASH_TABLE<type> name((const PROGMEM type *)name##_flash, sizeof(name##_flash) / sizeof(name##_flash[0]), cols);

The helper functions include size and override the operator [] so that they can easily be accessed like so

    FLASH_ARRAY[0]

I disagree with zmo - this is more than boilerplate. The area of PROGMEM causes a lot of questions from Arduino users, and it is very easy to do things wrong when creating arrays in PROGMEM.

  [1]: http://arduiniana.org/libraries/flash/

body:
The flash array is from Mikal Hart's [flash library](https://github.com/mikalhart/Flash/blob/master/Flash.h#L39) as you show, and what it does is that they declare an array or a matrix (table) object in the PROGMEM memory:

<!-- language: lang-cpp -->

    #define FLASH_ARRAY(type, name, values...) \
    static const type name##_flash[] PROGMEM = { values }; \
    _FLASH_ARRAY<type> name(name##_flash, sizeof(name##_flash) / sizeof(type));

which is an instance of the `_FLASH_ARRAY` class defined in that same file, which is a facility to access PROGMEM/Flash memory.

Basically, it's a lot of boilerplate for what already does the `PSTR()` macro amongst other from `pgmspace.h`. I personally would avoid using that and prefer to use the original macros along with my own index and pointers.

BTW, except for some Arduono IDE magic, I don't think that can compile, as the `Flash.h` is not included.

EDIT:

To make another point against the `FLASH_TABLE`/`FLASH_ARRAY` boilerplate/overhead, since avc-gcc 4.8 has been introduced the [`__flash` qualifier](http://gcc.gnu.org/onlinedocs/gcc/Named-Address-Spaces.html) which is a replacement for the `PROGMEM` macro, simplifying the whole stuff:

<!-- language: lang-cpp -->

    // to use string literals without having to cast
    #define FSTR(X) ((const __flash char[]) { X })

    // create string pstr in the .progmem.data address space
    const __flash char* pstr = FSTR ("foo");

and no more use of the `pgm_read_*()` functions, you can now access the content of the flash memory using `*pstr`, as shown is [this thread](http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&p=1129848). In case you want to keep a code compatible with older version of avr-gcc, [here's a post](https://codereview.stackexchange.com/questions/33883/embedded-conditional-code-compaction) that offers macros to deal with both systems.


body: I've seen many temperature sensors, but the highest temperature they go up to is 125 degrees C (257 degrees F). I want to reach *higher* temperatures than that. I'm thinking about rigging up a closed loop sensor for my soldering iron (for a convenient LCD display), but I can't find out how to sense the temperature of the tip due to the higher operating temperature than most sensors.

title: How can I sense very high temperatures with Arduino?

Answers: 2

body:
One of the options to measure high temperatures would be to use [thermocouples][1]. This table provides a basic description of [the types][2] and the corresponding temperatures that they can sense.

A simple search led me to these components.

- [Thermocouple Type-K Glass Braid Insulated][3] - A mid range thermocouple
- [Thermocouple Amplifier MAX31855 breakout board][4] - Board to interface the thermocouple with the Arduino. This is needed as the voltage changes in the thermocouple are extremely small, and the rise is non-linear.

>This is how the board is connected to the thermocouple.
>![enter image description here][5]

There is also a [tutorial on Adafruit][6] that deals with using and interfacing thermocouples.

> This is an image of the thermocouple interfaced with the Arduino.
>![enter image description here][7]

  [1]: http://en.wikipedia.org/wiki/Thermocouple
  [2]: http://en.wikipedia.org/wiki/Thermocouple#Thermocouple_comparison
  [3]: https://www.adafruit.com/products/270
  [4]: https://www.adafruit.com/products/269
  [5]: https://i.stack.imgur.com/oV37Y.jpg
  [6]: http://learn.adafruit.com/thermocouple/
  [7]: https://i.stack.imgur.com/tvzG0.jpg

body:
You probably want to use a [thermocouple][1]. It'll give you the ability to measure much higher temps than regular temperature sensor. You'll also need a IC like the [MAX6675][2] to interface with it.

> The MAX6675 performs cold-junction compensation and digitizes the
> signal from a type-K thermocouple. The data is output in a 12-bit
> resolution, SPI™-compatible, read-only format.
>
> This converter resolves temperatures to 0.25°C, allows readings as
> high as +1024°C, and exhibits thermocouple accuracy of 8 LSBs for
> temperatures ranging from 0°C to +700°C.

![enter image description here][3]

[Page 6 of the datasheet][4] has the serial interface protocol information and. You can really just set the Chip Select line and it'll give you 16 bits of information, 12 of which will be the temperature.

  [1]: http://en.wikipedia.org/wiki/Thermocouple
  [2]: http://www.maximintegrated.com/datasheet/index.mvp/id/3149
  [3]: https://i.stack.imgur.com/pyNbk.gif
  [4]: http://datasheets.maximintegrated.com/en/ds/MAX6675.pdf


body:
I am integrating the MPU-6050 Accelerometer + Gyro sensor into a large project that contains 12 Arduino boards and 6 Raspberry Pis. At some point, I will have to load the output of my MPU-6050 sensor into another application through command line. The process is to be all done with Python and Bash (on the Raspberry Pi side), and so what I need is a way to store the output of my Arduino boards.

What I am currently looking at is the python program `ino`. I have used the product for about a year now, and as far as I am aware of, the only way to exit out of serial mode in `ino` is by closing the command-line window!

Is there a way I can achieve what I've discussed above? Essentially, all I want is a way to hold the output of my Arduino serial output so I can use it later in other parts of my project.

title: Redirecting Arduino Serial Output to a File

Answers: 1

body:
Well, I don't know about your `ino` program, but here's how I'd do it:

get_serial.py

    import serial, sys

    with serial.Serial(port=sys.argv[1], baudrate=sys.argv[2]) as ser:
        while ser.isOpen():
            print(ser.readline())

The idea, here, is to print on `stdout` the data coming on the serial line:

    python get_serial.py /dev/ttyACM0 115200 > output.log

or you can do it this way:

get_serial.py

    import serial, sys

    with open(sys.argv[3]) as f:
        with serial.Serial(port=sys.argv[1], baudrate=sys.argv[2]) as ser:
            while ser.isOpen():
                f.write(ser.readline())

which is ran:

    python get_serial.py /dev/ttyACM0 115200 output.log

Hope this helps!


body:
I want an I/O pin to return current in a circuit, similarly to the function of ground.

Which of these will achieve what I require?

    pinMode(pinnumber, OUTPUT)
    digitalWrite(pinnumber, LOW)

or

    pinMode(pinnumber, input)

title: A digital I/O pin as ground

Answers: 1

body:
Your first snippet is the correct solution.

    pinMode(pinnumber,OUTPUT)
    digitalWrite(pinnumber,LOW)

Be careful though, you can only sink up to 6mA or 9mA per pin (as per the [documentation][1] ["Input and Output" section], I never tried more). If you need more current, use a transistor ([this][2] looks like a good example, you just need to invert the output pin to `HIGH`).

When the pin is configured as input it is supposed to be high impedance, not what you want.

  [1]: http://arduino.cc/en/Main/ArduinoBoardDue
  [2]: http://learn.adafruit.com/adafruit-arduino-lesson-13-dc-motors/transistors


body:
I'm currently changing some libraries to use flash instead of RAM for string storage so that I do not run out of SRAM on a project.

Some strings in the library are declared in this manner:

    const char *testStringA = "ABC";

This is different to how I normally see this done:

    const char testStringB[] = "DEF";

However, I think that these two are equivalent when declared const and initialised in the declaration. Both work fine in code.

I attempted to move these to flash:

    const prog_char *testStringC PROGMEM = "GHI";

I then found that this didn't work. It was producing gobbledegook when printed.

However, following the more usual pattern of:

    const prog_char testStringD[] PROGMEM = "JKL";

works fine.

I can see in the disassembly:

    00000068 <testStringC>:
      68: 04 01                                               ..

    0000006a <_ZL11testStringD>:
      6a: 4a 4b 4c 00                                         JKL.

So it is clear the pointer and PROGMEM results in the string/array not being initialised.

Why is this?

Example code:

    #include <avr/pgmspace.h>

    const int BUFFER_LEN = 20;

    const char *testStringA = "ABC";
    const char testStringB[] = "DEF";
    const prog_char *testStringC PROGMEM = "GHI";
    const prog_char testStringD[] PROGMEM = "JKL";

    void setup()
    {
        Serial.begin(9600);
    }

    void loop()
    {
        char buffer[BUFFER_LEN];

        Serial.println(testStringA);
        Serial.println(testStringB);

        strncpy_P(buffer, testStringC, BUFFER_LEN);
        Serial.println(buffer);

        strncpy_P(buffer, testStringD, BUFFER_LEN);
        Serial.println(buffer);

        delay(1000);

    }

title: Why can I not use pointers instead of array with PROGMEM?

Answers: 2

body:
What this line:

    const prog_char *testStringC PROGMEM = "GHI";

does is to write prologue code to copy the characters in the string to SRAM, and then initializes the *pointer* stored in flash to this SRAM location. You must load the pointer via normal means, and then dereference the pointer as usual.

    const char *str = pgm_read_word(&testStringC);
    Serial.println(str);

This line:

    const prog_char testStringD[] PROGMEM = "JKL";

creates the *array of characters* in flash, allowing you to access it as expected.

body:
Well, this question has been wisely answered in [an answer to Stack Overflow question *C: differences between char pointer and array*][1].

Basically, what you're declaring as PROGMEM with,

    const prog_char testStringD[] PROGMEM = "JKL";

is both the array and the memory it points to, that is, the elements of the array, both in current's scope stack. Whereas with:

    const prog_char* testStringC PROGMEM = "GHI";

you declare a PROGMEM pointer to a constant string that may stay elsewhere in memory, but not declared as a PROGMEM string.

Though I did *not* test that, but you should try to declare:

    const prog_char* testStringC PROGMEM = F("GHI");

to actually allocate the pointed string within the PROGMEM space. I *guess* it should be working, using Arduino's [`F()` macro][2], which adds a lot of boilerplate code to actually have the same result as the array declaration.

As said in comments, if not in a global context, the `PSTR()` macro could be used instead of the `F()` macro.

Simpler is better: use the array declaration, not the pointer one!

Cf [that other answer](https://arduino.stackexchange.com/a/614/379), the `__flash` qualifier is a third solution ;-)

  [1]: https://stackoverflow.com/a/1335836/1290438
  [2]: http://andybrown.me.uk/wk/wp-content/images//avr-gcc-4.7.0/WString.h


body: How can I run a webserver in a Arduino Uno? I want to use my Arduino to monitor things in my home such as temperature. I want to be able to access this data through the internet.

title: Webserver on Arduino

Answers: 2

body:
You'll need something like the Ethernet Shield to connect your Arduino Uno to a LAN.

As for webserver functionality, the [Webserver Example][1] sketch does the bulk of what you need.

![enter image description here][2]

For the "access this data through the internet" part, assuming you want access beyond your LAN; you'll need to perform Port Forwarding on your local router (i.e. allow the "Internet" to see your Arduino).

If you need wifi, then personally I prefer the [CC3300][3] to the Arduino Wifi shield.

  [1]: http://arduino.cc/en/Tutorial/WebServer
  [2]: https://i.stack.imgur.com/ju3X6.png
  [3]: https://www.adafruit.com/products/1469

body:
The [Arduino Yún][1] has been made with this use case in mind. The [Bridge library][2] allows your sketch to publish data such as sensor readings: this data is available through a REST api.

Say you want to publish the temperature of your living room: you'll write something like

`Bridge.put("living_room", String(19)); //celsius`

You can then access the data via web with a URL like

`http://arduino.local/data/get/living_room`

You can get all sensor readings without specifying the key name, with

`http://arduino.local/data/get`

  [1]: http://arduino.cc/en/Main/ArduinoBoardYun
  [2]: http://arduino.cc/en/Reference/YunBridgeLibrary


body:
I just finished testing a haptic device at university, and when I took it home I got the joy of finding the device not working. Here's what I can trace the problem to: when multiple pins are set to output (pin 2~11), pin 3 writes constantly to high and there is nothing I can do to make it stop.

Using a blinker program one pin at a time produces no problems, however when I run a blinker program that cycles through all pins, pin 3 is set to constant high. My actual code is similar in function but more complex. This program below though gets the same error.

    void setup()
    {
      for (int c =2; c<12; c++){
        pinMode(c, OUTPUT);
      }
    }

    void loop()
    {
      for (int c =2; c<12 ; c++){
         digitalWrite(c, HIGH);
         delay(100);
         digitalWrite(c, LOW);
         delay(100);
      }
    }

Is this a sign my arduino died? My device had been working for weeks on my prior code with no problem (and no updates).

title: All voltage directed to pin 3 when multiple pins are set to out put

Answers: 1

body: It is probably a dead chip. Try getting a new ATmega chip for the Arduino (easily found online for ~$5) and see if that fixes it.