text:
How do I change the default number of parameters SDI 12?
I am a nooby so this might be an obvious answer kind of a question, but how do I change how many parameters arduino-uno reads from a sensor using SDI communication? My code (which was in public domain, an example for SDI communication) has no problems taking 3 or less parameters but the probe I have has 7 sensors in it and I need all of their values (but all I get in return is 1, literally just the number 1). If I remove and leave only 3 sensors in the probe it works normally. So the problem is not in the communication but in the quantity of data. My code:
    #include <SDISerial.h>
    #define DATALINE_PIN 2
    #define INVERTED 1

    SDISerial sdi_serial_connection(DATALINE_PIN, INVERTED);

    char* get_measurement(){
     char* service_request = sdi_serial_connection.sdi_query("?M!",60000UL);
     char* service_request_complete = sdi_serial_connection.wait_for_response(900);
     return sdi_serial_connection.sdi_query("?D0!",60000UL);
    }

    void setup(){
     sdi_serial_connection.begin(); // start our SDI connection
     Serial.begin(9600); // start the connection
     Serial.println("OK INITIALIZED"); // startup string
     delay(90000); // startup delay to allow sensor to powerup, 1.5 min
    }

    void loop(){
     char* response = get_measurement(); // get measurement data

     if (response!=NULL && response[0] != '\0')
      Serial.println(response);
     else
      Serial.println("No Response");
     delay(1500);
    }

Check the timeout values. 60000 should be 60000UL as the parameter is defined as uint32_t. The statement "uint8_t wait_for_response_ms = 180000" is also very wrong but not used. Same goes for "int j=0". Please clean up the code.

get_measurement(); is called only once in loop().

get_measurement(); within the loop is just fine, it does continuously call for the values even though it is not in classical form of a loop -again, this is a public code which i just tweeked a little to fit my needs.
However, the rest of the suggestions were spot on and thank you for that, even though it does not solve my problem it does speed up the execution.


text:
Arduino not working / not uploading
Could anybody please help me with my problem? My Arduino doesn't work correctly. I was between a project, and suddenly it started acting weird. First, it started taking about 4 minutes to compile and a minute to upload, I do not know why!
Second, now it doesn't accept any code at all. I will paste the error message below.
Also, could anything be damaged as I inserted the USB cable of the Arduino to my power bank, rated 5V 2A, for about 30 seconds as power source and then again inserted it to the computer itself.
Please help me. I have already tried searching on various forums, reinstalling the software and driver on my PC, pressing the reset button... No help so far.

ERROR MESSAGE:
  Arduino: 1.6.7 (Windows 10), Board: "Arduino/Genuino Uno"
avrdude: Version 6.0.1, compiled on Apr 15 2015 at 19:59:58
           Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/
           Copyright (c) 2007-2009 Joerg Wunsch
System wide configuration file is "C:\Program Files (x86)\Arduino\hardware\tools\avr/etc/avrdude.conf"

Using Port                    : COM6
Using Programmer              : arduino
Overriding Baud Rate          : 115200
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 1 of 10: not in sync: resp=0x49
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 2 of 10: not in sync: resp=0x49
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 3 of 10: not in sync: resp=0x49
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 4 of 10: not in sync: resp=0x49
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 5 of 10: not in sync: resp=0x49
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 6 of 10: not in sync: resp=0x49
Error opening serial port 'COM6'. (Port busy)
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 7 of 10: not in sync: resp=0x49
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 8 of 10: not in sync: resp=0x49
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 9 of 10: not in sync: resp=0x49
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 10 of 10: not in sync: resp=0x49

avrdude done.  Thank you.

Problem uploading to board.  See http://www.arduino.cc/en/Guide/Troubleshooting#upload for suggestions.

Also see Have I bricked my Arduino Uno? Problems with uploading to board

Connecting to the 5v/2A power supply would cause no trouble at all. Taking 4 minutes to compile is strange but unlikely to be related to the Arduino board. "programmer is not responding" errors are communication errors.

Did the program compile without errors?
Are any LEDs lit or blinking on your board?
Is the correct board selected in the Tools | Boards menu?
Is the correct port selected in the Tools | Ports menu?
Is the correct programmer selected in the Tools | Programmer menu?
Try another USB cable.
Try pressing/releasing the board's reset button right after you click the upload button.

Don't forget the programmer option!

yes it compiled without errors
yes LED on the board blink like normal
yes correct board is selected
yes correct port is selected
programmer im nt sure.... wat exctly shud it be?
another usb cable, ok il try that soon as i get my hands on another cable,
i tried the reset button thingy...dint work  :(

I am getting the same exact errors.  Tried different boards, cables, upgrade to 1.6.7, etc.  Maybe will go back to pre1.6 and try.  Will also try via tinyisp when I get a chance.  FYI - having no issues with studio 6/tinyusb/avrdude combination, just on arduino.  Wonder if it is a USB driver or arduino version of avrdude problem?

Confirmed - no problems uploading via usbtinyisp. Must evolve around Arduino USB?

Another confirmation - not only does usbtinyisp work good but I can also read the serial port in Putty.  Definitely something going on in Arduioland!

source: Stack Exchange

license: Creative Commons - Attribution Share-Alike - https://creativecommons.org/licenses/by-sa/3.0/

sort: votes


text:
Where am I supposed to get an I2C BUFFER_LENGTH defined?
I am using a BLE nano - as soon as I try to include I2Cdev.h and compile, I get this error:
Arduino\libraries\I2Cdev\I2Cdev.cpp:276:62: error: 'BUFFER_LENGTH' was not declared in this scope

How should I fix this? I imagine I can hard-code it in and guess around as to the value (32 seems common), but I think I am missing something else as far as it using the right libraries for the hardware, so how can I check/fix that if it is indeed the case?

BUFFER_LENGTH is set in I2Cdev.h depending on the target. BLE nano is not directly supported (what I can see).
Cheers!

all_licenses: Creative Commons - Attribution Share-Alike - https://creativecommons.org/licenses/by-sa/3.0/


text:
Capacitive "keys" press event registration issues
Seeing as this is my first post I would like to thank everyone ahead who take their time to delve into my whimsical code, whoever you may be, be merciful ;)
For one of my uni projects, I would like to make a physical interface that can be operated via touch "keys" that rely on the human capacitance effect. I have relentlessly researched it (as much as feasible in my time as a student for this project) and even created a working prototype with 4 unique keys.
As you will see in my code below, I am using the capacitiveSensor.h library, which I could unfortunately not find much documentation about other than a few videos and tutorials that build upon it.
I tried deciphering the workings of it by looking at its code to see if I can manipulate it for my own biddings but quickly realized it is beyond my skill to understand.
The problem I am facing right now is that while the touch keys work, they trigger each other because of the capacitance build up when one of the keys is being pressed or when the hand is close to other keys while pressing a key.
Essentially, I am looking for an algorithm that will reduce processing time & effort for the Arduino as the one I have implemented below slows it down way too much to be of any use for my project.
Sorry for the long post, here is my current code:
#include < CapacitiveSensor.h >
#include < pitches.h >

CapacitiveSensor cs_4_2 = CapacitiveSensor(4, 2); // 10M resistor between pins 4 & 2, pin 2 is sensor pin, add a wire and or foil if desired
CapacitiveSensor cs_4_3 = CapacitiveSensor(4, 3); // 10M resistor between pins 4 & 6, pin 6 is sensor pin, add a wire and or foil
CapacitiveSensor cs_4_5 = CapacitiveSensor(4, 5); // 10M resistor between pins 4 & 8, pin 8 is sensor pin, add a wire and or foil
CapacitiveSensor cs_4_6 = CapacitiveSensor(4, 6);

# define COMMON_PIN 4 // send pin
# define CAP_THRESHOLD 450 // overall threshold
# define NUM_OF_KEYS 4 // Number of keys that are on the keyboard
# define noteDur 50 // duration of note
# define BUZZER_PIN 12 // The output pin for the piezo buzzer
# define noMulti 0.9 // incremental factor per key
# define overkill 5 // register no touch after this cap factor is exceeded

// This macro creates a capacitance "key" sensor object for each key on the piano keyboard:
# define CS(Y) CapacitiveSensor(COMMON_PIN, Y)

CapacitiveSensor keys[] = {
CS(2), CS(3), CS(5), CS(6)
};

void setup() {

Serial.begin(57600);

// Turn off autocalibrate on all channels:
for (int i = 0; i < NUM_OF_KEYS; ++i) {
keys[i].set_CS_AutocaL_Millis(0xFFFFFFFF);
}

}

void loop() {

// needs to be repeated here to work in THIS scope
long sensor01 = cs_4_2.capacitiveSensor(30); // pin 2 is cap sensor, pin 4 is "common send"
long sensor02 = cs_4_3.capacitiveSensor(30);
long sensor03 = cs_4_5.capacitiveSensor(30);
long sensor04 = cs_4_6.capacitiveSensor(30);

Serial.println("");
Serial.print("key1");
Serial.print("\t");
Serial.print("key2");
Serial.print("\t");
Serial.print("key3");
Serial.print("\t");
Serial.print("key4");
Serial.println("");
Serial.print(keys[0].capacitiveSensor(CAP_THRESHOLD));
Serial.print("\t");
Serial.print(keys[1].capacitiveSensor(CAP_THRESHOLD));
Serial.print("\t");
Serial.print(keys[2].capacitiveSensor(CAP_THRESHOLD));
Serial.print("\t");
Serial.print(keys[3].capacitiveSensor(CAP_THRESHOLD));

// algo for key 1
if (keys[0].capacitiveSensor(CAP_THRESHOLD) > CAP_THRESHOLD &&
keys[1].capacitiveSensor(CAP_THRESHOLD) < keys[0].capacitiveSensor(CAP_THRESHOLD) * noMulti &&
keys[2].capacitiveSensor(CAP_THRESHOLD) < keys[0].capacitiveSensor(CAP_THRESHOLD) * noMulti &&
keys[3].capacitiveSensor(CAP_THRESHOLD) < keys[0].capacitiveSensor(CAP_THRESHOLD) * noMulti) {
Serial.print("key pressed on sense1");
Serial.println("");
tone(BUZZER_PIN, NOTE_A7, noteDur);

}

// algo for key 2
else if (keys[1].capacitiveSensor(CAP_THRESHOLD) > CAP_THRESHOLD &&
keys[0].capacitiveSensor(CAP_THRESHOLD) < keys[1].capacitiveSensor(CAP_THRESHOLD) * noMulti &&
keys[2].capacitiveSensor(CAP_THRESHOLD) < keys[1].capacitiveSensor(CAP_THRESHOLD) * noMulti &&
keys[3].capacitiveSensor(CAP_THRESHOLD) < keys[1].capacitiveSensor(CAP_THRESHOLD) * noMulti) {
Serial.print("key pressed on sense2");
Serial.println("");
tone(BUZZER_PIN, NOTE_B7, noteDur);

}
// algo for key 3
else if (keys[2].capacitiveSensor(CAP_THRESHOLD) > CAP_THRESHOLD &&
keys[1].capacitiveSensor(CAP_THRESHOLD) < keys[2].capacitiveSensor(CAP_THRESHOLD) * noMulti &&
keys[0].capacitiveSensor(CAP_THRESHOLD) < keys[2].capacitiveSensor(CAP_THRESHOLD) * noMulti &&
keys[3].capacitiveSensor(CAP_THRESHOLD) < keys[2].capacitiveSensor(CAP_THRESHOLD) * noMulti) {
Serial.print("key pressed on sense3");
Serial.println("");
tone(BUZZER_PIN, NOTE_C7, noteDur);

}
// algo for key 4
else if (keys[3].capacitiveSensor(CAP_THRESHOLD) > CAP_THRESHOLD &&
keys[1].capacitiveSensor(CAP_THRESHOLD) < keys[3].capacitiveSensor(CAP_THRESHOLD) * noMulti &&
keys[2].capacitiveSensor(CAP_THRESHOLD) < keys[3].capacitiveSensor(CAP_THRESHOLD) * noMulti &&
keys[0].capacitiveSensor(CAP_THRESHOLD) < keys[3].capacitiveSensor(CAP_THRESHOLD) * noMulti) {
Serial.print("key pressed on sense4");
Serial.println("");
tone(BUZZER_PIN, NOTE_D7, noteDur);

}

}

Guys, I realized how to "bypass" the lag caused by the capacitance build up once a key is triggered - namely by increasing the size of the resistors (from 1k to 1mOhm) between the "keys", e.g. the aluminum foil in this case, and the Arduino input pins. What this does is reducing the maximum capacitance that can be reached on each key and so reduces the overall period needed to register the maximum capacitance, which I assume is done by some magic internally in CapacitiveSensor.h. As a result, pressing a key does not lag the Arduino nearly as much as was the case when using 1k resistors.

You might experiment with the code shown at the end of this answer.  It is fairly responsive, in the sense that readings are taken reasonably quickly (several per millisecond), which should leave a good deal of time available for other processing.
In this code, all of the pins that are on the same port are sampled at the same time.  For example, pins 2,3,5,6  on an Uno are all on port D so their four pads can be tested all at the same time.  But if the pins list includes pins from k different ports, sampling will take up to k times as long as when sampling from a single port.  For example, on a Mega2560, pins 2, 3, 5 are on port E and pin 6 is on port H, so this code's execution time when processing buttons on pins 2,3,5,6 is about twice as long on a Mega as on an Uno.
[Edit:  For Uno port-to-pin assignments, see an Arduino Uno Pinout Diagram.  On such diagrams, labels like ADC0 PCINT8 14 A0 23 PC0 show the Arduino digital pin reference number (eg, 14), analog pin label (eg, A0), its various functional designations (ADC0, PCINT8, and PC0, meaning analog input pin 0, pin-change-interrupt pin 8, and bit 0 of port C), and the physical pin number (23).   For hardware level information about Uno ports, see Atmel's document #8271.  Use Google images similarly to find other-model diagrams, eg Mega 2560 pinouts.]
You may need to tune some of the constants to fit your own circuitry or switch-function requirements.  I'm not able to tell from the question what resistor sizes you are using or what your circuit is.  For preliminary tuning, enable the secondly() function and disable testChange() functions.  If your circuit is similar to that shown below but uses higher resistances, you may need to increase nsamp, IsHighCount, and preSamp.
Here is the general idea of circuitry I used:

In the above, "Drive" refers to pin 4.  "Sense 1" ... "Sense j" (with j=4) refer to pins 2, 3, 5, 6, as in your example code.  The capacitors illustrated are tape-covered aluminum-foil pads, eg 22 x 44 mm and the resistors are 440 KΩ each (two 220 KΩ's in series).  Those resistor values produce an RC time constant of a few dozen microseconds when a button isn't touched, and a couple hundred microseconds when a button is touched.
Here is some example output:
2 on  199 7587
2 off 179 7702
1 on  196 10798
1 off 154 10802
1 on  253 10900
1 off 180 10924
2 on  219 18097
2 off 166 18134
3 on  214 21105
3 off 155 21385
3 on  227 24312
3 off 72 24535

In that output, the first column is switch number.  The last column is the current reading of millis() at time of printing.  The third column is total counts accrued from 12 sets of contact readings.  The simple-minded on/off algorithm used in the testChangeA() function is that a contact is on when its 12-sample count exceeds 180.  One could also add calibrations, adaptive threshholds, debouncing, etc to the code.
Here is the code (which was run on an Uno, but I tested most of it on a Mega also, and it should run ok on other Arduinos as well since the direct port accesses are computed via functions like portInputRegister, portModeRegister, etc in countPins7() setup before it calls portSampler7() to run the test.
/* Via serial port, tell the current time when capacitive readings on
 various digital pins show a button has been "pressed" or "released".
 JW - 25 Dec 2015

 See eg refs at http://playground.arduino.cc/Code/CapacitiveSensor and
 http://www.arduino.cc/en/Reference/PortManipulation and
 http://garretlab.web.fc2.com/en/arduino/inside/arduino/Arduino.h/digitalPinToPort.html

 */
#include <Streaming.h>      // provides nicer syntax for printing
// Set upper size on pins count per sample; #samples saved per reading;
//  #samples tossed; threshold for Button-is-on; #samples per set; etc
enum { nbits=8, nsamp=40, preSamp=1, SettleDown=90 };
enum { IsHighCount=15, SampleSets=12, IsHighTotal=IsHighCount*SampleSets };
void setup() {
  Serial.begin(115200);     // initialize serial port
}
//-----------------------------------------------------------
// portSampler7(): Sample a port nsamp times and return the results.
// Inputs:  drivePin, portCode, pinsMask, preWait.  Constant nsamp.
// Output:  array of nsamp samples.
// This version takes 8 cycles per sample, and as inputs switch
// on after about one RC time constant, on a 16MHz Arduino an
// m-count result (that is, a bit clear in m of the nsamp readings)
// suggests RC is about m/2 + preWait/2 us.
void portSampler7(uint8_t drivePin, uint8_t portCode, uint8_t pinsMask,
          uint8_t preWait, uint8_t *samples) {
  volatile uint8_t *pin, *port, *ddr;
  // pin, port, and ddr are pointers to registers with volatile
  // contents: input port, output port, direction register.
  pinMode(drivePin, OUTPUT);
  digitalWrite(drivePin,LOW);
  pin =  portInputRegister (portCode); // eg points to PIND
  port = portOutputRegister(portCode); // eg points to PORTD
  ddr =  portModeRegister  (portCode); // eg points to DDRD
  *port &= ~pinsMask;        // Turn off our pins
  *ddr  |= pinsMask;         // Make our pins be outputs, briefly
  for (uint8_t i=0; i<SettleDown; ++i) *pin;  // Delay to let pins settle low
  *ddr &= ~pinsMask;         // Make our pins be high-impedance inputs
  digitalWrite(drivePin,HIGH); // Turn on driver pin
  for (uint8_t i=0; i<preWait; ++i) *pin;  // Baseline Delay
  for (uint8_t i=0; i<nsamp; ++i) // Take and store nsamp readings
    samples[i] = *pin;
}
//-----------------------------------------------------------
/* Sample a pins-list and report results in counts array.  Eg,
   pinsList can look like "2,3,4,5,6" or "2,4,5,12,9,23,17,7"
   etc.  A list may contain digits and commas only.  Pins may be
   listed in any desired order.  Elements of counts will be in
   list-order.  Eg, in the "2,3,4,5,6" example, counts[0] is the
   count for pin 2, counts[1] is the count for pin 3, etc.  A
   larger count implies longer rise time and larger capacitance.
   Use preWait to suppress baseline-level counts (and to reduce
   sample array size) by waiting a while before beginning to sample.
 */
uint8_t countPins7(uint8_t drivePin, char *pinsList,
           uint8_t *counts, uint8_t preWait) {
  uint8_t pnum, pomask, pocode, potem, i, j, mul;
  uint8_t sampl[nsamp], pim[nbits], pat[nbits], bout=0, nat=0, pcon;
  char *c, cc;
  int usedPorts=0;  // To track which ports are done
  for (c=pinsList, counts[0]=pcon=0; *c; ++c) // Zero the counts array
    if (*c < '0' || *c > '9') counts[++pcon] = 0;
  // In each pass, group bit numbers by port and sample the port
  while (nat<pcon) { // Each loop pass sets one bit in usedPorts
    pnum = pocode = pomask = bout = pcon = 0;
    c = pinsList;
    while ((cc=*c++)) {  // Loop until c is at end of string
      if ('0' <= cc && '9' >= cc) {
    pnum = 10*pnum + cc - '0';
    if ( *c < '0' || *c > '9') { // See if pin # is complete
      potem = digitalPinToPort(pnum);  // Get port #, in range 1 to 12
      if (!(usedPorts & (1<<potem))) { // Is potem's port already done?
        if (!pocode)           // If pocode not set, set it
          pocode = digitalPinToPort(pnum);
        if (pocode == potem) {  // Process pin if it's in current port
          pomask |= (pim[bout] = digitalPinToBitMask(pnum));
          pat[bout++] = pcon; // Save location of pin's bit in results
        }
      }
      pnum = 0; // Clear # accumulator
      ++pcon;   // Count pin numbers
    }
      }
    }
    // Now pomask is a mask for all bits to be read from port pocode
    // and we are ready to sample current port
    portSampler7(drivePin, pocode, pomask, preWait, sampl);
    usedPorts |= 1<<pocode;       // Mark the port finished
    // Count up # of zeroes (ie rise times) in sampled bits
    for (j=0; j<bout; ++j) {
      int count;
      uint8_t m=pim[j];
      for (count=i=0; i<nsamp; ++i)
    count += sampl[i] & m;
      counts[pat[j]] += nsamp - count/m;
    }
    nat += bout;        // Count number of pins done so far
  }
  return pcon;          // Return # of pins processed
}
//-----------------------------------------------------------
// secondly() will report counts at start-of-second
void secondly() {
  uint8_t counts[nbits], j, nc;
  if (millis()%1000) return;    // Wait for start-of-second
  nc = countPins7(4, "2,3,5,6", counts, preSamp);
  Serial << "Counts: ";
  for (j=0; j<nc; ++j)      // Marshal output
      Serial << counts[j] << " ";
  Serial << " t=" << millis() << endl;
  while ((millis()%1000)==0) {}; // Await end-of-millisecond
}
//-----------------------------------------------------------
uint8_t ostate[nbits] = {0};
void testChange1() {
  uint8_t counts[nbits], j, nc, s;
  nc = countPins7(4, "2,3,5,6", counts, preSamp);
  for (j=0; j<nc; ++j) {
    s = counts[j] > IsHighCount;
    if (s ^ ostate[j]) {
      Serial << j << (s? " on  " : " off ") << counts[j] << " " << millis() << endl;
      ostate[j] = s;
    }
  }
}
//-----------------------------------------------------------
void testChangeA() {
  uint8_t counts[nbits], j, k, nc, s;
  int sumcount[nbits]={0};
  for (k=0; k<SampleSets; ++k) {
    nc = countPins7(4, "2,3,5,6", counts, preSamp);
    for (j=0; j<nc; ++j) {
      sumcount[j] += counts[j];
    }
  }
  for (j=0; j<nc; ++j) {
    s = sumcount[j] > IsHighTotal;
    if (s ^ ostate[j]) {
      Serial << j << (s? " on  " : " off ") << sumcount[j] << " " << millis() << endl;
      ostate[j] = s;
    }
  }
}
//-----------------------------------------------------------
// Take samples of rise times at  designated pins.  When a pin's
// time changes from small to large, report rising edge; or
// when it changes from large to small, report falling edge.
void loop() {
  //secondly();
  //testChange1();
  testChangeA();
}

Thank you for a most comprehensive answer jwpat7! I will try your solution but I have to ask - why does setting the input pins to high impedance is important? Also, I did not know of the presence of the ports you mention in your answer, is there a reference to them in the arduino documentation you could perhaps share with me? Again, thank you for taking your time to reproduce my problem here!

Each input pin is monitoring the voltage on a pad, as that voltage drops according to v(t) = v(0) * exp(-tau * t), where tau = RC time constant.  If the input pin weren't hi-Z it would affect the rate of voltage drop.  Regarding ports, see edit

@Grove, I don't understand your comment, eg what you mean by  “the pulsating nature” or by  “the on/off algorithm”.   Three notes: 1, There should be a layer of insulation (eg packing tape or a solder-resist coating) on top of each key, so it shouldn't matter to the user how the key is being tested.  2, If you mean "only test the button when it's being pressed", I don't know of a way to do that.  3, why does whatever you are referring to matter?  Ie will it save energy, time, or what?

Hey jwpat7, I deleted my original comment because I found a way to solve my problem: I was trying to attach an event to a specific key once it was pressed but used the on/off algorithm to check its state and was naturally unsuccessful because when a key was pressed it still was less than 180 at one point in the "capacitance cycle". So instead, I just used the j variable as a starting point to see which key was being pressed, as j returns a constant value, i.e. the key number.
Thank you again for your help!


text:
How can I attach I2C sensors on the small board of Intel Edison?
Sensors like Skin conductance, Body temperature and Heart Rate. Please imagine to talk to a child and keep the answer very simple so I can understand you and you don't lose time to write explanations for your answer.

Something like https://www.sparkfun.com/products/13034 would be helpful, in connecting. You need at least something to convert the 70-pin Hirose Header into a more usable connection type.

I didn't get "You need at least something to convert the 70-pin Hirose Header into a more usable connection type."

The only way to connect anything to the edison is via the 70 pin connector. Unless you're very skilled in soldering, connecting something to these pins with 0.4mm (15mil) spacing is impossible.

Surely I'm not skilled. It is the only solution you see?

If you're using the mini-breakout board (https://www.sparkfun.com/products/13025), then you can get the I2C connections from the board (connections available through holes under the Edison; you can see them from the backside; see: https://cdn.sparkfun.com//assets/parts/1/0/0/1/1/13025-02.jpg). You can solder headers on or can solder wires directly to the required pins. You can find the pin mapping here: http://iotdk.intel.com/docs/master/mraa/edison.html

Use the I2C breakout board. This will also handle voltage shift from 1.8 V to the sensor voltage level.


text:
Problem Uploading to arduino uno board
I have an arduino uno. Whenever I try to upload code to the arduino I get this error.
avrdude: ser_open(): can't open device "/dev/cu.usbserial-AL01EI7I": Device not configured

ioctl("TIOCMGET"): Inappropriate ioctl for device Problem uploading to board.
See http://www.arduino.cc/en/Guide/Troubleshooting#upload for suggestions.

What OS are you on? Do you have the necessary drivers installed?

The error message is telling you that avrdude failed to open the device and read the modem status (basically the information about whether a device is present and ready on a serial line). The most likely causes of this are:

Using the wrong serial port (Tools > Port in the Arduino IDE).
The IDE not recognizing the board.
Using a power only USB cable.

The Arduino IDE seems to remember the device that your board was last connected through, but on some Unix flavored OSes the device name depends, in part, on method of connection – which port, hub or no hub, etc. So if you change the board or the port you plug it into, the name changes.
So, the very first thing to do is to look under  Tools > Port in the Arduino IDE to see if there is another device present. Also confirm that you're using a USB cable with data wires. There are "power only" USB cables…
Failing that, check to see if the OS sees the board. On OS X you would go to the Apple menu and choose About this Mac and then look at at the System Report to see what devices have been detected on your USB busses. I'd be surprised if there wasn't something similar on Linux (and Windows too for that matter). If you're comfortable on the command line you could look in /dev for devices with similar names.
If the board is present, but not seen by the Arduino IDE, try restarting the IDE and/or plugging and unplugging the USB cable. Sometimes it helps to plug the cable into a different port.


text:
Use Unix terminal instead of the Monitor on Arduino IDE
I want to make a shell or C script that interprets the Arduino serial input to run commands. For that, I will need to make that script be the Serial monitor for my arduino. Another reason I want to use scripts or the command line as a Serial I/O is because the Arduino monitor function freezes the IDE.
My arduino's serial port is /dev/tty.usbmodem1d112
This is what I have tried so far:

cat /dev/tty.usbmodem1d112 < This returns absolutely nothing
screen /dev/tty.usbmodem1d112 < This Prints output, but has problems with input.
cat < /dev/tty.usbmodem1d112 < Same result as cat without the < symbol.

Sometimes, I also get annoying Resource Busy messages. This makes me re-plug the Arduino board.

OS X (10.9.5) Arduino IDE latest version. Arduino M0 pro board.

On linux, I usually have to configure the device with stty to raw mode or whatever I want first, but I'm not sure how portable that is.

screen /dev/SomeUSBSerial SerialSpeed works fine here on Debian with CP2102, FTDI232, Atmega32u4 (Leonardo), Atmega8U2 (serial chip of UNO-R2)... input and output are ok.

For what it is worth, the 1st and 3rd versions of your command are identical in function. In the 1st, cat uses the argument as the file to display. In the 2nd, the shell sets the standard input for cat to the file. The net result of both is that cat reads from the file and writes to standard output. The < and > operators are used to redirect the input and output of a program.

Have you tried miniterm.py? It works really well in Ubuntu as serial monitor with Arduino boards.

Yes, miniterm really works very well on Ubuntu and faster than screen, minicom, cu, etc. https://helpmanual.io/help/miniterm.py/

https://playground.arduino.cc/Interfacing/LinuxTTY/ might help

You'll need to condition the serial line with the stty command to get this to work. One of the easier ways to do it is to start by using the Serial Monitor and running the command:
stty -g < /dev/tty.usbmodem1d112
That will show you all of the settings that the Serial Monitor used to conditions the line. The -g flag to stty tells it to give you the results in a form that can be used as the arguments to another stty command. You could do this like this:
echo -n 'stty ' > stty.arduino ; sudo stty -g -f /dev/tty.usbmodem1d112 >> stty.arduino
chmod +x stty.arduino
The first line creates a shell script to condition the serial line. The second line makes it executable so that you can run it as a shell command – ./stty.arduino. The sudo runs the command as root (with elevated privilege) which allows you to open the port even though the Serial Monitor will already have it open.
If you want you could move the command into a directory on your $PATH (for example ~/bin) so that it can be found regardless of where your current directory is.
After getting set up you can see the output from Serial.println() on the Arduino by doing:
./stty.arduino
cat < /dev/tty.usbmodem1d112
Depending on what you are trying to do, you might find the expect or script commands helpful. Expect (man page) lets you automate interactions with a text based application or process. Script (man page) creates a transcript of your interactions on the command line with another program or process.

Strangely, running the stty -g < /dev/... acts like the command is running, but nothing happened for long. When I use the second command to make a shell script, upon execution, it freezes my Terminal command line.

Can you show the output you get from stty -g…? Are you running the command with -f and/or sudo? I'm very puzzled that the second command, chmod, would hang your shell – it should succeed (or fail) immediately.

chmod was fine. The long command creating shell script works, but the execution of the sh hangs shell. I did try sudo, and -f, but it shows new line as if processing, but nothing seems to happen

When you say "nothing seems to happen" do you mean the command produces no output and you get your prompt back? Or, the prompt doesn't come back until you interrupt the command? Or, it appears to execute as you'd expect by the settings on the serial line are unchanged? Or,… Too many possible nothings :-)

Sorry for that inspecificness. Upon entering a command and pressing return, you get a blank line, and once the command executes, the usual Name@Device:~$ Shows up. And upon hitting return on that command, I do not get that Name@Device:~$ on the new line

Would you try ./stty.arduino < /dev/tty.usbmodem1d112 and see if that works? Looking this over, I see that the command to condition the line doesn't specify the line – so it's going to act on your terminal, and that's almost certainly not what you want.

I just get Resource busy when I try stty -g < /dev/tty.SLAB_USBtoUART on my machine. This is the correct path for my nodeMCU.


text:
Help reading a 125khz FSK RFID
Reddit doesn't seem to be much help, so I'm posting here as well.
I'm try to read (what I think is) an HID Duoprox II 125kHz FSK RFID and am having a bit of trouble. I'm using an Arduino nano and am copying the code from the Arduino Playground. The changes I've made to the code are adjusting the frequency to 125kHz, changing debug to true, and reducing maxBuf to 100. I believe I also have to change val = digitalRead(inPin); to val = !digitalRead(inPin);, and I made grnLED turn on before "got buf num: " is sent, and turn off after. Rather than build the circuit shown, I bought an Rdm6300, reverse engineered the front end, and disconnected the back end from it, letting me use the Arduino as the back end instead.
As far as hardware goes, the reader seems to be working properly. The coil has a nice sine wave on it, and the output of the circuit seems to be a proper FSK data stream . (I scoped LedPin, 13, which is outputted by the Arduino after it has recieved the signal on pin 7.)
For some reason, the Arduino is not sending anything back to the computer. I'm fairly certain that this is somehow a software issue, despite me copying the code from the Arduino website. The TX LED does not light up at all. Even if the data being sent to the Arduino were corrupted, it should still send "got buf num: " every 100 changes of the input signal. (grnLED does turn on for 37.4ms, but no serial data is sent, and the pin never turns on again.)
What's going on? Why doesn't the Arduino send anything back to the computer?
Full code:
#include "TimerOne.h"

int ledPin = 13; // LED connected to digital pin 13
int inPin = 7;   // sensing digital pin 7
int val;
int bitlenctr = 0;
int curState = 0;

#define maxBuf 100 //reduce to 100 or so for debugging
#define debug  true

char raw[maxBuf];

int index = 0;
int bufnum = 0;
#define   redLED 12
#define   grnLED 11

void setup()
{
  Serial.begin(9600);
  Timer1.initialize(8);  // initialize timer1, and set the frequency; this drives both the LC tank as well as the pulse timing clock
  // note: modify this as needed to achieve resonance and good match with the desired tags
  // the argument value is in microseconds per RF cycle, so 8us will yield RF of 125kHz, 7us --> 143kHz, etc.

  Timer1.pwm(9, 512);           // setup pwm on pin 9, 50% duty cycle
  Timer1.attachInterrupt(callback);  // attaches callback() as a timer overflow interrupt, once per RF cycle

  pinMode(ledPin, OUTPUT);      // sets the digital pin 13 as output for scope monitoring
  pinMode(inPin, INPUT);      // sets the digital pin 7 as input to sense receiver input signal
  pinMode(grnLED, OUTPUT);
  pinMode(redLED, OUTPUT);
  digitalWrite(grnLED, 0);
  digitalWrite(redLED, 1);
}

void callback()
{
  val = !digitalRead(inPin);
  digitalWrite(ledPin, val); // for monitoring
  bitlenctr++;
  if(val != curState) {
    // got a transition
    curState = val;
    if(val == 1) {
      // got a start of cycle (low to high transition)
      if(index < maxBuf) {
        raw[index++] = bitlenctr;
      }
      bitlenctr = 1;
    }
  }
}

void loop()
{
  if(index >= maxBuf) {
    digitalWrite(grnLED, 1);
    Serial.print("got buf num: ");
    Serial.println(bufnum);
    digitalWrite(grnLED, 0);

    if(debug) {
      for(int i = 0; i < maxBuf;
      i++) {
          Serial.print((int)raw[i]);
        Serial.print("/");
      }
      Serial.println("///raw data");
      delay(2000);
    }

    // analyze this buffer
    // first convert pulse durations into raw bits
    int tot1 = 0;
    int tot0 = 0;
    int tote = 0;
    int totp = 0;
    raw[0] = 0;
    for(int i = 1; i < maxBuf; i++) {
      int v = raw[i];
      if(v == 4) {
        raw[i] = 0;
        tot0++;
      }
      else if(v == 5) {
        raw[i] = raw[i - 1];
        totp++;
      }
      else if(v == 6 || v == 7) {
        raw[i] = 1;
        tot1++;
      }
      else {
        raw[i] = 101; // error code
        tote++;
      }
    }

    // next, search for a "start tag" of 15 high bits in a row
    int samecnt = 0;
    int start = -1;
    int lastv = 0;
    for(int i = 0; i < maxBuf; i++) {
      if(raw[i] == lastv) {
        // inside one same bit pattern, keep scanning
        samecnt++;
      }
      else {
        // got new bit pattern
        if(samecnt >= 15 && lastv == 1) {
          // got a start tag prefix, record index and exit
          start = i;
          break;
        }
        // either group of 0s, or fewer than 15 1s, so not a valid tag, keep scanning
        samecnt = 1;
        lastv = raw[i];
      }
    }

    // if a valid prefix tag was found, process the buffer
    if(start > 0 && start < (maxBuf - 5*90)) { //adjust to allow room for full dataset past start point
      process_buf(start);
    }
    else {
      Serial.println("no valid data found in buffer");
    }
    if(debug) {
      for(int i = 0; i < maxBuf;
        i++) {
          Serial.print((int)raw[i]);
        Serial.print("/");
      }
      Serial.print("///\nbuffer stats: zeroes:");
      Serial.print(tot0);
      Serial.print("/ones:");
      Serial.print(tot1);
      Serial.print("/prevs:");
      Serial.print(totp);
      Serial.print("/errs:");
      Serial.println(tote);
      delay(1000);
    }

    // start new buffer, reset all parameters
    bufnum++;
    curState = 0;
    index = 0;
  }
  else {
    delay(5);
  }
}

// process an input buffer with a valid start tag
// start argument is index to first 0 bit past prefix tag of 15+ ones
void process_buf(int start) {
  // first convert multi bit codes (11111100000...) into manchester bit codes
  int lastv = 0;
  int samecnt = 0;
  char manch[91];
  char final[45];
  int manchindex = 0;

  Serial.println("got a valid prefix, processing data buffer...");
  for(int i = start + 1; i < maxBuf && manchindex < 90; i++) {
    if(raw[i] == lastv) {
      samecnt++;
    }
    else {
      // got a new bit value, process the last group
      if(samecnt >= 3 && samecnt <= 8) {
        manch[manchindex++] = lastv;
      }
      else if(samecnt >= 9 && samecnt <= 14) {
        // assume a double bit, so record as two separate bits
        manch[manchindex++] = lastv;
        manch[manchindex++] = lastv;
      }
      else if(samecnt >= 15 && lastv == 0) {
        Serial.println("got end tag");
        // got an end tag, exit
        break;
      }
      else {
        // last bit group was either too long or too short
        Serial.print("****got bad bit pattern in buffer, count: ");
        Serial.print(samecnt);
        Serial.print(", value: ");
        Serial.println(lastv);
        err_flash(3);
        return;
      }
      samecnt = 1;
      lastv = raw[i];
    } //new bit pattern
  }

  Serial.println("converting manchester code to binary...");
  // got manchester version, convert to final bits
  for(int i = 0, findex = 0; i < 90; i += 2, findex++) {
    if(manch[i] == 1 && manch[i+1] == 0) {
      final[findex] = 1;
    }
    else if(manch[i] == 0 && manch[i+1] == 1) {
      final[findex] = 0;
    }
    else {
      // invalid manchester code, exit
      Serial.println("****got invalid manchester code");
      err_flash(3);
      return;
    }
  }

  // convert bits 28 thru 28+16 into a 16 bit integer
  int code = 0;
  int par = 0;
  for(int i = 28, k = 15; i < 28+16; i++, k--) {
    code |= (int)final[i] << k;
  }
  int paritybit = final[28+16];
  for(int i = 0; i < 45; i++) {
    par ^= final[i];
  }

  if(par) {
    Serial.print("got valid code: ");
    Serial.println((unsigned int)code);
    // do something here with the detected code...
    //
    //
    digitalWrite(redLED, 0);
    digitalWrite(grnLED, 1);
    delay(2000);
    digitalWrite(grnLED, 0);
    digitalWrite(redLED, 1);
  }
  else {
    Serial.println("****parity error for retrieved code");
    err_flash(3);
  }
}

// flash red for duration seconds
void err_flash(int duration) {
  return;
  for(int i = 0; i < duration*10; i++) {
    digitalWrite(redLED, 0);
    delay(50);
    digitalWrite(redLED, 1);
    delay(50);
  }
}

EDIT:
Even the following code doesn't work! All I receive is "St"! Increasing the PWM period does fix this.
#include "TimerOne.h"
int val = 0;
int inPin = 7;

void setup(){
  Serial.begin(9600);
  Serial.print("Starting!!");
  Timer1.initialize(8);
  Timer1.pwm(9, 512);
  Timer1.attachInterrupt(callback);
  pinMode(inPin, INPUT);
  }

void callback(){
  val = digitalRead(inPin);}

void loop(){
  Serial.println("hi!");}

If you invert what you read from pin 7, you should at least invert the initial and later settings of curState too as well as the if(val == 1) ....

The only reason I'm inverting what I'm reading from pin 7 is because the circuit I'm using inverts the signal compared to the circuit on the Arduino website (I think.) The program should send debug information either way.

Have you tried using different serial baud rates? Just a stab in the dark...

Did you figure this out? It looks like it's printing the first 2 letters of "Starting".  Adding a delay between your print and Timer1.initialize printed the rest of it.


text:
Nokia 5110 Screen Pixel by Pixel
I have got this LCD screen

I'd like to be able to decide every pixel status of the screen. Do I need to work directly with the buffer or is there another method?

Create a byte buffer where you draw everything (and check pixel values) and flush it to the display after changes. This way you can also implement double buffering to avoid any flickering during animations.

The 5110 Nokia LCD display is based on PCD8544. It is not possible to read the device display memory. The controller has only serial data input.
Typically a graphical device driver for that display will use an offscreen bitmap (buffer). To check the pixel status you would need to check the status in the offscreen bitmap.
Some device drivers use only text and copy font bitmap directly to the display memory. In that case you cannot check the status of the pixel (if the text is not buffered).


text:
RobotLinking 18B20 pinout and circuit board weirdness
I have a Dallas Semiconductors 18B20 temperature sensor on a RobotLinking board. It's part of the RobotLinking 37 Sensors Kit. The board has a LED to indicate activity. It resembles this:

Here's what's weird. All the guides I can find for the 18B20 say that the pin order is GND, DQ, VDD. That should mean pin 1 goes to GND, pin 2 goes to a GPIO, and pin 3 goes to 3.3V or 5V (this one can take either). Yes, I am looking at the sensor's pins from its bottom.
If I do this, the board's LED is lit solidly. I get 0 degree readings, the same as if no device was connected. (Infinite resistance?)
To make this work, and get valid temperature readings, I have to hook it up this way: sensor GND to the GPIO, sensor DQ to GND, and sensor VDD to 5V or 3.3V. The LED only flashes when the temperature is actually read.
Here's a twist: if you look at the circuit traces on the RobotLinking board, it looks like the paths between the male breadboard connectors and the sensor's pins 2 and 3 are reversed. This means if you think you are connecting to pin 3 via the male connectors, you are in fact connecting to pin 2, and vice versa. The path from pin 1 on the sensor to the male pin 1 where it plugs into the breadboard is straight, so pin 1 probably means pin 1.
When I described the above connections I made, I accounted for this apparent circuit pathing weirdness.
Another twist is in the manual, the sensor is soldered to the middle leads. My sensor is instead on the furthest leads from the pins, like in the attached image.
The manual with this kit didn't explain any of this. I'm at a loss to understand my observations. For a generic sensor kit for n00bs, why would one want the pins on the bottom of the circuit board not correspond to the pinout of the sensor?

Please see http://bigfieldsblog.cloudapp.net/keyes-18b20-temperature-sensor-and-raspberry-pi-2/ for info on how to connect.

From the look of the board, it is designed to support multiple devices. I'd suspect that the three sets of holes give different mappings of the device pins to the board pins. Could it be that the sensor is soldered into the wrong set of holes?
If you have a meter or can see the traces you could look to see if the middle set of holes is wired the way you would expect. If that is a photo of your board, it looks like you have enough length in the leads on the sensor to move it to the middle holes.


text:
What causes a "blip" in LED brightness with sequence of 254, 255, 0, 1 brightness values?
I am seeing a "blip" in LED brightness when trying to fade a red LED on an Arduino UNO.
This code demonstrates the "blip" seen in brightness right after a 254, 255, 0 sequence.  When the brightness is then set to 1, the actual brightness is much higher for a short period of time.  The blip is not seen during the entire delay interval, just at the beginning.
I see the blip every time except for the very first cycle, before the 255 to 0 transition has ever happened.
My best guess is that there is a PWM "accumulation" that is not seen when the brightness is set to zero, but it is used when the brightness is set to a non-zero value.
/*
 FadeBlip
 Derived from Fade.ino.
 */

int led = 9;
int brightness = 0;
int fadeAmount = 1;
int skipBegin = 5;
int skipEnd = 254;

// If you try a shorter delay, you must make the skip range smaller
// to pick out the blip.  If you try a longer delay, the blip is not
// as bright.
int delayms = 1000;

void setup()  {
  pinMode(led, OUTPUT);
  Serial.begin(9600);
  delay(1000);  // give us time to bring up serial monitor
}

void loop()  {
  Serial.println(brightness);
  analogWrite(led, brightness);

  brightness = brightness + fadeAmount;

  // skip the boring middle values
  if (skipBegin < brightness && brightness < skipEnd)
    brightness = skipEnd;

  if (brightness > 255)
    brightness = 0;

  delay(delayms);
}

Also see  Why does an LED sometimes flash when increasing brightness?,

The Why does an LED sometimes flash when increasing brightness? question does exactly describe my problem (except for the substitution of pin 11 for pin 9).  That question refers to this post at forum.arduino.cc which gives the beginnings of an answer.
The problem is caused by the fact that analogWrite(led, 0) does not use PWM, it just sets the pin to LOW.  So when you call analogWrite(led, 0), the value in the Output Compare Register (OCR) is left at 255.  When you call analogWrite(led, 1), the OCR value is changed to 1, but due to double-buffering this doesn't take effect until the next timer cycle begins.  So for a fraction of the current timer cycle the output pin is left at HIGH.
The solution is to either avoid calling analogWrite(led, 0) or to explicitly set the OCR value to 0 when analogWrite(led, 0) is called.  This will only work if another call to analogWrite() is not made in the current timer cycle.  Given that the default timer cycle takes 32 microseconds, this is unlikely to happen.  32 microseconds = 256 (ticks per timer cycle) / 16MHz (clock ticks per second) * 2 (default timer prescale factor).
For pin 9, the solution was to add these lines immediately after the analogWrite() call:
if (brightness == 0) {
    OCR1A = 0;
}

For other pins, use the correct Output Compare Register.  For the Arduino UNO they are:
+-------------+----------+-------+
| Arduino Pin | Chip Pin | OCR   |
+-------------+----------+-------+
|           3 |        5 | OCR2B |
|           5 |       11 | OCR0B |
|           6 |       12 | OCR0A |
|           9 |       15 | OCR1A |
|          10 |       16 | OCR1B |
|          11 |       17 | OCR2A |
+-------------+----------+-------+

Of course this solution will need to be modified if you have changed anything related to timers such as the PWM mode.
The solution given by the forum.arduino.cc post indicated that the Timer/Counter Control Register (TCCR) needed to be modified in addition to setting the OCR value.  This modification was to configure the PWM mode, but the PWM mode would have already been correctly configured by any previous call to analogWrite() for that pin.
Others have suggested that calling analogWrite(led, 1) before analogWrite(led, 0) would be a simpler solution, but that still results in a flash, albeit shorter.
Resources:

LED fade malfunction (random flash) (forum.arduino.cc/index.php?topic=360468.msg2486781)
hardware/arduino/cores/avr/arduino/wiring_analog.c
Secrets of Arduino PWM (www.righto.com/2009/07/secrets-of-arduino-pwm.html).  There is a more recent copy of this article at arduino.cc (www.arduino.cc/en/Tutorial/SecretsOfArduinoPWM), but that copy has the useful graphics stripped out.
Arduino Timers and Interrupts (arduino-info.wikispaces.com/Timers-Arduino)


text:
arduino beginner documentation help
I plan to buy these 2 products to begin to play with arduino to learn.

Board with LCD touch
Yun board expansion

I have a mega 2560 which i bought with a starter kit and i love to play with. I have not played with the shield yet. I understand some shields can be used together, some not. and some with modification on the board and in the code.
I can't find pins specification for the touch screen and the support on the website doesn't respond.
If some one can help me find specifications for the touch screen, or help me choose some shields that will allow me to use a USB host, wifi, and a touchscreen it will be nice.
Thanks all.

The link you posted describes a TFT LCD Touch screen unit with the SPFD5408 controller, referenced in this Instructable for use with the Mega. You might start there and migrate to the Yun once you get the screen working.


text:
Re-use smartphone/tablets parts like a camera
For learning and hacking purposes, I plan to study and use parts from smartphones and tablets like Galaxy or iPhone. They are really efficient and pretty cheap...
Did anybody do this before? If yes, can anybody tell me what kind of connector is this one on the galaxy camera, Galaxy Tab S 10.5 Front Facing Camera (Wi-Fi), and whether it can be found for attaching it to an Arduino project?
Edit: Someone else asked a similar question here, How to reuse quality camera from old / broken phone.

People might also be interested by these links :
http://www.chipworks.com/sites/default/files/Apple_iPhone_6s_A1688_Smartphone_Chipworks_Teardown_Report_BPT-1509-801_with_Commentary.pdf

https://raspberrypi.stackexchange.com/questions/22963/using-other-camera-modules-to-build-custom-webcams
http://pinouts.ru/forum/index.php?topic=5111.0

The connector on the flex circuit from that camera was made by Hirose (it has an HRS logo on it), and might be in the BM10, BM14, or BM20 series.  You can measure the pin spacing, stacking height, etc. to check which series it's in.  For example, the Hirose BM14 series of FPC to board connectors has pins at 0.4 mm Pitch and 0.8 stacking height.
Mouser.com carries a 24-pin BM14 connector that might mate or match with the pictured connector.  For other photos of Hirose FPC connectors, see google images for hirose fpc.
While you probably can find a matching connector (via careful measurement and perhaps some trial and error) and build an interface, it may be difficult to use the camera once it's hooked up.  Most Arduino models have too little RAM to support image processing.  A Yun might do it, a Tre, or some other micro entirely, eg Beagle or Raspberry.

As a side question, how do you know how much RAM such a camera requires ?

@Charaf, I don't know what protocol that camera uses.  On some, the readout rate is 40 MHz, ie too fast to process in realtime on most Arduino models, but if a camera has a readout the Arduino can clock, and if your image processing can go line by line or is concentrated on a small region of the whole image, you might get by with a few thousand bytes.   For whole-image processing, having a few megabytes of RAM is helpful.

The ballpark RAM required for video processing is a product of the size of the image. A camera which outputs a 30fps 640x480 image would take a minimum of 6404803 bytes = 920 kB per frame. This is already orders of magnitude more than the Atmel-based arduinos have. In addition, the CPU and buses must run faster than the data coming in, which is 6404803*30 bytes per second = 27.6 MB/s, i.e. greater than 27.6 MHz. So in summary, video processing requires closer to a "computer" than a "microcontroller", simply because of the size of video. FPGAs are a whole different story.

As a second side question, i found the iPhone 4S Rear-Facing Camera really really cheap here http://www.repairsuniverse.com/apple-iphone-4s-camera-replacement.html … But given that it's Apple featured, do you think there is a chance for the signal to be encrypted so that we could not reuse this part ?
@cortices : understood. Better use it in conjonction with a raspberry, may be.

@Charaf, the price is for a reason -- it gives you no help with decoding the signal from the camera. It's not that it's encrypted per se, just that the details of the output protocols of these proprietary camera chips are usually not public, and even if they are, it is infeasible to implement it yourself.

(summary of comment thread)
I strongly recommend against trying to use any of these smartphone camera replacement parts. While they are cheap, this is because the signal they output is nigh impossible for you to use, even if you knew its specifications, which is unlikely given proprietary parts often have proprietary, non-public protocols. Even if you did have it, you'd likely have to implement a linux kernel extension for Raspberry Pi yourself to support it. Far more work than it's worth.
If you actually want to do image processing, there is a clear recommendation: the Raspberry Pi camera interface. RasPis have a special flex socket on the board for a camera, and you can buy cameras which work with the raspivid etc. commands included in raspbian with no extra setup. This allows you to use OpenCV or similar image processing libraries, or write your own, without having to worry about bitbanging obscure camera protocols.
No-name camera boards can be bought from eBay or similar sites for less than US$20, and they support 30fps 5 MP image/video capture to the Raspberry Pi natively and easily. Just search for "Raspberry Pi camera".
However...
If you're really sure you're up to the challenge of hacking a proprietary camera module, you'll want to do thorough research finding the exact protocol specifications for these camera chips first, and try to find ones that are the most common, for the highest chance of compatibility, and likelihood of others having made progress on using them. Good luck!


text:
Lightblue Bean BTLE tinkering
How does one modify the Bluetooth settings, like services or pincode, on a light blue bean?
Ps I'm on Android
http://legacy.punchthrough.com/bean/ if you don't know what I'm talking about


text:
What phone carriers are available in the USA that are compatible with a sim900 breakout board
I was wondering what carriers are compatible with a sim900 breakout board. I know it needs a GSM network (AT&T,T-mobile,?) but what networks can I use?
It needs a 850/ 900/ 1800/ 1900 MHz frequency to work but who offers that frequency? I personally could not find what frequency cell phone companies offered. From how I understand it is that T-Mobile definitely will work.I have heard several different answers about companies like AT&T and I have seen discussion about sprint (which I don't understand because they are a CDMA carrier).
I have also heard that there are other carriers (Vondafone, nextel,Ting) that might be more cost effective for people like me who are only going to be using the text messaging.
Can someone please set me straight on who I can use.

Vonda Phone? You mean Vodafone?

My apologizes. I have corrected the error. Thank you.

SIM900 should be compatible with both AT&T and T-Mobile. T-Mobile uses 1900Mhz for 2G and AT&T uses 850Mhz and 1900Mhz. Although both carriers are upgrading to 4G, they still support 2G devices. My personal experience is that most quadband 2G devices still work with AT&T and T-Mobile and there is no technical reason why SIM900 shouldn't work. However, there can be issues with incompatible data plans that are compatible only with their own devices. You need to be careful when selecting the contract and buying the sim card.
Nextel and Ting uses Sprint's network which is CDMA and thus wouldn't work. However Vodafone seems to be using T-Mobile's network and may work.


text:
Hardware Interrupt Triggered Randomly
So there is this pretty generic part of my project that involves triggering an ISR that will flip a boolean value. I have set up the software side like so:
void setup() {
  attachInterrupt(digitalPinToInterrupt(2), displayConvergence, FALLING);
}

void loop() {
  if(flashConvergence) {
    //Do stuff that takes several seconds
    delay(3000);
    flashConvergence = false;
  }
}

void displayConvergence() {
  if (!flashConvergence) {
    flashConvergence = true;
  }
}

The schematic is as follows:

simulate this circuit – Schematic created using CircuitLab
But the behavior of my circuit surprised me as the pin interrupt would get triggered randomly at a frequency at (guessing here) 3 times a second.
Weird, I thought. I fiddled around and found that when the boost converter's 180V is not connected to any load, the interrupt service triggers as expected, as in it starts working correctly. So I thought perhaps the issue was some noise introduced by the boost converter.
I modified the circuit by adding a capacitor across the switch:

simulate this circuit
I tried 1 uF at first, but that didn't help and neither did 10 uF. However, when I tried 100 uF (I thought decoupling capacitors are usually 0.1uF to 1 uF, is the value I am using too big?), things seem to be working as expected with the exception that when I hold the switch in the closed position for a long time, then let it go back in the open position, the interrupt service can be triggered randomly for a short period right after I let go of the switch.
Is my initial assumption that the ISR is triggering randomly due to EMI from the boost converter correct? Perhaps there are other causes I am not looking at? Is there a way to make this work 100% (as in solve the issue right after the switch is put in the open position)?
Thanks for the help!

You could try; lowering the pull-up resistor. Moving the button away from the boost converter and it's wires. Move the pull-up nearer  to pin 2. Use a pull-down system (by swapping R1 and SW1), instead of pull-up. PS the capacitor isn't used for decoupling here, but as a low-pass-filter.

Why would a pull-down system have more noise immunity than a pull-up system?

I'm not sure if it would, but might be worth a try.

Buck-Boost converters are pretty noisy. If the interrupt is triggered randomly without you even touching the switch, that means some noise is definitely causing the issue. If you have an oscilloscope you can hook it up to D2 to see what is happening. Try adding a 100uF and a 0.1uF cap on the 5V before it connects to the Arduino circuit.

I think if you only want to flip a value of a Boolean try using this only in the ISR "flashConvergence = !flashConvergence;" it will save a ton of space and is less complicated.

It has come to my attention I never posted a followup to this but I was actually able to solve this problem by shielding the wire going from the switch to the arduino. The switch's wire was about 2 to 3 inches long and I wrapped aluminum foil around it, which shielded the signal from what I suspected was EMI induced by the switching converters.

If you don't have any bulk capacitance (100uF or so) on your logic supply you will have noise problems.  You should also use some smaller (1uF and 0.1uF) to provide bypass for higher frequency noise in the power supply system.
Glenn

An alternative approach is to detach the interrupt handler and use the internal pullup instead of external resistor (and capacitor).
const int BUTTON = 2;
volatile bool flashConverage = false;

void setup()
{
  setmode(BUTTON, INPUT_PULLUP);
  attachInterrupt(digitalPinToInterrupt(BUTTON), displayConvergence, FALLING);
}

void loop()
{
  if (!flashConvergence) return;

  // Do stuff that takes several seconds
  delay(3000);
  flashConvergence = false;
  attachInterrupt(digitalPinToInterrupt(BUTTON), displayConvergence, FALLING);
}

void displayConvergence()
{
  detachInterrupt(digitalPinToInterrupt(BUTTON));
  flashConvergence = true;
}

The processing ("stuff that takes several seconds") will debounce the button (or at least ignore it :).
Cheers!

The problem isn't (only) switch bounce. It's false triggers. This code won't help with that.

Well we have provided a few solutions to test. I do agree that the noise from the Converter might be the issue. Moving the 100 uF capacitor to filter noise on the power (5V) might also help.

all_licenses: Creative Commons - Attribution Share-Alike - https://creativecommons.org/licenses/by-sa/4.0/


text:
How to Send Live Sensor Data to iOS Custom Apps with BLE
I am looking for a Bluetooth Low Energy (BLE) device that could send live sensor data from Arduino to iOS custom apps, not the app that is already in the app store. I would like to create my own apps to receive the sensor data. Or are there any other ways to achieve it?

I would expect this to be pretty straight forward. Off hand, I can't think of anything that would be a major roadblock to creating your iOS apps. It seems like there are two problems you'll need to solve:

Finding a BLE chip that is relatively easy to integrate with an Arduino, and
Selecting the tools that you'll use on the iOS side to develop your app.

Since I haven't done this my self, I started off looking on the Arduino side – mostly because it seemed like the problems there would be larger. I searched on Google using the terms:
aruduino ble
I found quite a few candidates that look promising, here are some of the better ones:

Bluefruit LE - Bluetooth Low Energy (BLE 4.0) - nRF8001 Breakout - v1.0 – I put this one on the top of my list because the price is pretty reasonable (< $20 US) and Adafruit tends to do a good job of supporting their products with tutorials and at least a basic library that demonstrates the functionality of the device.
Redbear Labs - I don't know anything about Redbear, but they do well in Google searches and appear to have several products, including a BLE shield, that might do what you want.
BLEduino - this is a Kickstarter, and while it looks interesting, a very quick investigation didn't reveal a source where you can buy one.

The choice of devices will partly depend on what your ultimate goal is. Something like the BLEduino will give you an all-in-one package to build your project around. The downside of this is that you may be spending money on functionality that you don't need/want to duplicate. A breakout board like the Bluefruit LE gives you a smaller device and possibly more flexibility at the expense a bit more work to get up and running.
Next you'll need to select development tools. I started by searching with the terms:
ble swift ios
I got a number of promising results, including:

Arduino Tutorial: Integrating Bluetooth LE and iOS with Swift
Apple: Bluetooth for Developers
Adafruit - Introduction to Bluetooth Low Energy

These first three look like good starting points for "getting your bearings," the following two are specific to actual boards.

Getting Started with the nRF8001 Bluefruit LE Breakout
RedBearLab/iOS


text:
Reading SPI between an MCU and NRF24L01
I have a remote control that has an STM32 MCU and sends data via NRF24L01. What I would like to do is clone the data sent when buttons are pressed by reading what is being sent to the RF24 and then replicating these messages with my own "remote".
I have tried sniffing the data wirelessly with my Pro Mini and NRF24L01. I have everything plugged in correctly, the BasicExample seems to be running fine, but when I run a promiscuous channel activity sniffer, I don't get any wireless data, not even running wifi and bluetooth near the NRF. Pro Mini is 5V and NRF sniffer is powered by an external 3.5V battery with cap on VCC-GND, ground is common to Pro Mini. I have also tried the WireShark approach, but with 0 packets found.
Therefore I want to try it directly wired to the remote. I don't have a logic analyzer handy. How would I read the data? By just connecting MISO and CS to an arduino and running an SPI reader? What would be the best way to do this? I have the Pro Mini and many Teensy boards ready.

That was an interesting challenge. There are some obstacles to consider when trying to use RF sniffing:

What channel is used? (128)
What bit-rate is used? (250K-1M-2M)
How many address bytes? (3-5 byte)
How many bits in CRC? (1-2 byte)
Auto-Acknowledgement? (1 bit)
etc.

Without any info on the remote NRF configuration this is tedious to break. Probing the hardware signals (MISO, MOSI, SCK, SS) on the remote NRF chip with a logic analyzer seems (much) easier.
Cheers!

I found this wonderful tutorial http://yveaux.blogspot.com/2014/07/nrf24l01-sniffer-part-1.html but I haven't had any luck receiving anything yet.

First thing you have to make sure you have wired the receiver correctly. (Also download the latest RF24 library from built-in library manager or from github.com/TMRh20/RF24) Then solder at least 100uF capacitor directly to the power pins of the Nrf24l01. If you wish to reverse engineer it, you must make sure it's not your hardware or software letting you down. (When you manage to reverse engineer it, please leave a comment here for others wishing to do the same)


text:
How can I make Arduino IDE use Atmel's provided toolchain? (Linux/Ubuntu)
I have an Arduino based board using ATmega168PB, but so far only Atmel's provided toolchain supports this microcontroller. I can download the toolchain from Atmel's website, but I am not sure how to make the Arduino environment use it.

In the directory for the new core create a new platform.txt and give the entry for compiler.path the location of the bin/ directory containing the Atmel toolchain.
compiler.path=/path/to/bin/


text:
Measuring voltage on an analog pin - What do I need to know about amperage?
I'd like to measure the voltage at a test point on a stepper motor driver chip with an arduino. The voltage at this point controls the amperages to the phase coils and is adjusted to trim the driver.
I have a common ground with the driver already, I'd like to wire the drivers v-ref point to an analog input to drive an LCD showing the output amp number so I can adjust the driver.
The issue I am worried about is that with the hardware I have to test with a properly trimmed driver is pushing 0.84A.
Is this safe to do without killing the arduino board?

Yes. The only thing you need to be concerned about is the voltage. It needs to be less than the Arduino Vcc.
The voltage sense circuit (analog inputs) typically have a high impedance and should draw a negligible current from the circuit being sensed. I didn't have much luck finding the actual spec for any of the AVR chips, but I did find this answer to the question on Electronics.StackExchange – where they say "hard to tell, the specs are incomplete, but 10 KΩ seems like a reasonable guesstimate/assumption" (I paraphrase). The reasoning is interesting and worth a read.

Awesome thank you, I'll give it a try tonight.


text:
Teensy 2.0++ SDA SCL pins not accesible using ARDUINO software
Hi I was looking to interface Teensy++ 2.0 with MPU6050 for a simple IMU project.
I have done this previously using Teensy 3.1 by trying the project of kriswiner however I also wanted to try it out on my Teensy++ 2.0 board.
But when I went to check the pin assignments for Teensy++ 2.0 on the pjrc website it has been mentioned that the pins PD0 and PD1 can be used as SDA and SCL using C Language but there is no assignment of SDA SCL on Teensy ++ 2.0 using Arduino Software
Does that mean we cannot use these pins using Arduino software at all? Or is there a workaround to this?

Here is more info https://www.pjrc.com/teensy/td_libs_Wire.html.

BW What do you mean by ARDUINO software? The core for the Teensy++ 2.0 board is provided by PJRC (and not Arduino LLC). And you can use D0 and D1 for as digital pin, pwm, interrupt or I2C.

The pin assignments for Teensy ++ 2.0 were mentioned as such on the pjrc page. using arduino software this and using C language this

Thanks for the update. Guess that ARDUINO software should be interpreted as Arduino API. In any case, I2C is not an issue. You might consider posting PJRC a message about the "misleading documentation".


text:
Read a String from serial to debug the AT commands sent to my GPS shield
I want to extract an AT command's response (via serial port) to find out if the GPS shield is working as it should be.
I used:
  if(Serial.available()>1){
     String response = Serial.read();
     Serial.println(response);
  }

Normally the response to AT is OK but it keeps telling me that it cannot convert int to String .... can someone help?

if (Serial.available() > 1) is wrong. Always use if (Serial.available()) in such cases. Also it seems you are communicating with the GPS shield using Hardware Serial. However, the Arduino also uses the same serial port for communicating with the PC via the USB connection. So what you have basically is:

Arduino TX, PC RX and GPS RX are all connected
Arduino RX, PC TX and GPS TX are all connected

So anything the Arduino writes to the Serial port using Serial.println() is received by both the PC and the GPS shield. And the other hand, responses from the GPS shield and commands sent from the serial monitor all arrive at the same Arduino pin. So when you use Serial.read(), assuming you used the serial monitor to send the command, you will end up receiving your own command (like some sort of echo), and according to your program, you use Serial.println() to send the command again which is received by both PC and GPS shield, with the GPS shield responding to the same command again. All undesirable.
TLDR; use SoftwareSerial instead for the GPS shield. Connect the GPS shield TX to pin 2 and its RX to pin 3 and use this code:
    #include <SoftwareSerial.h>

    SoftwareSerial gps(2,3);   // pin 2 = RX, pin 3 = TX

    void setup(){
        Serial.begin(57600);
        gps.begin(57600);    // change to your baud rate, if not auto-baud
    }

    void loop(){
        while (Serial.available())     //used to send commands from PC
            gps.write(Serial.read());   // to gps
        while (gps.available())        // used to read responses from gps
            Serial.write(gps.read());  // to PC
    }

So the Arduino forwards everything it receives from the PC monitor (commands) to the shield and sends everything it receives from the shield (responses) to the PC to be displayed in the serial monitor.

Serial.read() returns a byte (a single character), you've told the compiler that response is a string. It doesn't know how to deal with the difference…
What you want to do it to read the response in a loop until you've got it all.
Here's an example.


text:
Link to an project for remotely turning off light switch?
I want to build a contraption using an arduino that allows me to turn off my light from across the room. I plan to use a solenoid to move the lights switch up and down. I'm sure I'll have some specific questions later on but to start with, has anybody made or seen a similar project? All I'm really looking for is a link to a project (unless you're willing to give advice/suggestions). Thanks!

Light switches are made with a variety of actuators. You will have to share what type you intend to control because that will impact the remote triggering mechanism. (I will show examples in an answer due to not being able to add pictures here).

Using a solenoid to control a manual switch is possible for sure, but very uncommon, so I guess you won't find references easily. A solenoid capable of moving switches may consume a lot of power, so most engineers will replace the combination switch/solenoid by a relay. Controlling a relay is a very common task, with many references available. But as a relay contains a solenoid, you may find helpful hits there, too [http://www.electroschematics.com/8975/arduino-control-relay/].

MicroBot Push: a robotic finger for your buttons...

https://www.indiegogo.com/projects/microbot-push-a-robotic-finger-for-your-buttons#/
The Robotoic Light Switch

http://hackaday.com/2015/11/06/the-robot-light-switch/
Wifi controlled light switch

https://hackaday.io/project/5141-wifi-controlled-light-switch

This isn't exactly what you asked for, but may be a better idea.
Light switches are electrically just switches.  Either two points are connected or they are not.  In this case they are meant to be mechanically actuated by humans.
Instead of making a electrically controlled contraption that mechanically activates the existing switch, you could more easily use a electrically-activated switch directly.  Such things are called relays, and are quite common and readily available.  You can easily get a relay that can be actuated from 5 V that can switch 120 or 240 Vac at a few amps.
Put the relay in parallel across the switch if you want the switch to be able to override the light on, and in series if you want the switch to be able to override the light off.
To allow both the relay and the switch to toggle the light on/off independently, each needs to be a SPDT (single pole double throw) switch or relay.  Actually, you'll have a hard time finding a relay that isn't at least SPDT.  Ordinary wall switches aren't, but ones meant for multiple switches to control the same light are, like you often find at the top and bottom of the same set of stairs.

I fully agree that this is a better idea and I considered it but decided to go with mechanical actuation for a few reasons. First, I want more experience with mechanical projects, not just electrical. But also I want my device to be easily removed or switched. Assuming the switch type is the same, I want to be able to move it to any random light switch and have it working in seconds. My goal is to create a mechanical one for now (something that just works) and in the future, design a better system like the one you suggested.

Various types of light switch actuators. Which is it?

I apologize, I should've been clear about that in my initial question. Pretty much all the switches I intend to use are the same and standard, corresponding to your first picture.

@JamesM. - Good to know. By the way, "standard" really does not apply because if it did there would be only one picture.


text:
Options for measuring position of garage door
I'd like to be able to measure the position of my garage door. Determining if the garage door is fully open or fully closed should be fairly simple with some magnetic reed switches but I'd like to know the position of the door when it's partially open/closed.

Well, if it's not open and not closed, it's inbetween ;) you'll neer two sensors though to be able to distantiate beteren these states.

If you really want some amount of precision inbetween, you could mount a "ultrasonic sensor" or "ir ranging" sensor to the door and measure the distance to the ground. However, I don't see why it would be neccesary. Most garage doors would shut down when blocked, but ask your manufacturer.

A couple of possibilities occur to me. One would be to mount a rotary encoder on a rotating part of the door. Another would be to attach a reed switch to the track and a series of magnets to the door. I suppose you could do something with a proximity sensor as well.
How much precision do you need in the position of the door? What do you know that is deterministic? For example is the door transit time predictable? Is it a positive drive? Do you get to know when the door starts moving? That might be enough right there.
If you can say more about what you're trying to do it would make it easier to provide suggestions and insight.

As for precision, within a couple of inches or so would be fine. It's mostly for informational/educational purposes.

Seems like a reed switch and magnets might be one of the simpler ways to go about it. Or if you control the motor and the door drive is positive you could just time it.

Timing it wouldn't help if the door gets stuck (how would you know where it got stuck) and would probably be less precise than I want if the door doesn't travel at a constant rate.  Magnetic reed switches would work but would require a lot of them and hooking them up would take some fancy electronics or a lot of pins.  Plus there would be some uncertainty if the door stopped inbetween the switches.  So far a rotary encoder tracking the movement of the chain sounds like the best bet.

The way I would do it with a reed switch (or maybe two or three) is to use one switch and many magnets – at most you would use three pins. You would keep track of the door position by counting switch closures. You could make it a bit more positive if you also used a switch or possibly two for "open" and "closed" – you could reset your count when the open or closed switch was tripped which might make it easier to keep track of your position. One thing to keep in mind is how you will deal with different failure modes. The rotary encoder will give you the wrong answer if the chain breaks.

I would suggest an Ultrasonic Range Finder. There is an example in the Arduino Tutorials and they are available cheaply on ebay.

Can you add a link to the tutorial? Or at least describe the general idea?

A linear encoder (usually comprising an LED, a photodetector, and an encoder strip with black lines on it) would work, but a long encoder strip is expensive and probably not reliable a garage environment.  You could use a radial encoder attached to the motor, but that is probably too expensive too and overkill for your application.
Ranging devices are often difficult to use with something narrow and dirty like the bottom edge of a garage door.  Placing devices on the door itself is probably not the most reliable and inexpensive way to do this either.
A Solution for Any Large Spring Loaded Position Sensing
One way that can be very reliable and is inexpensive is to use two strain gauges.  In spite of the low cost, this approach is used in many industrial and laboratory arrangements.  You could use an IN114 or a similar 8-pin dip instrument amplifier to convert the differential strain gauge resistance to a Voltage within the range of the Arduino analog input.
I'd guess a cost around $100 with shipping for the IN114, the rest of the circuit, strain gauges, emery cloth, bonding cement, temperature sensor (optional), power supply, jacks, solder, circuit housing, PCB breadboard, and cabling.
You will need to use a Wheatstone bridge at the + and - input of the instrument amp. There are plenty of example circuits.  Search for, "instrument amp wheatstone bridge strain gauges," to get some schematic diagrams.
An adjacent two of the four legs of the Wheatstone bridge are the two strain gauges.  One of the other two legs would be a potentiometer in series with a fixed resistor to give you offset adjustment.  Another potentiometer adjusts gain.  The IN114 spec sheet shows how to set the gain and how to power the chip.
Mechanically, the strain gauges would go on opposite sides of the exact same point on the spring, near where it attaches to the stationary frame to which the tracks are mounted.  One strain gauge must be bonded to the inside of the spring.  The other to the outside, directly opposite the inside one through the thickness of the spring wire.  This will allow the Voltage you measure to indicate the strain on the spring which is related to the position of the door.
(The image at http://recordtek.com/sites/default/files/Gauge-spring.png shows a strain gauge bonded to the outside of the spring.  The inside complement would go directly underneath it on the inside.)
I'd recommend an Arduino Due to read the output voltage of the IN114, setting the gain and offset to stay within the 1.55 to 2.75 V range of the analog inputs of the Due for all garage door positions.  That will take some trial and error with a Voltmeter before you connect the Due.
To calibrate the system, the analogRead() values for ten somewhat equally spaced garage door positions are placed in an array of integers.  Another same size array of doubles receives the corresponding door positions in whatever units you want.  These can be static arrays that are initialized in your Arduino code.
You would get the position from the analogRead() at any point in time by interpolating the data in the table represented by the two corresponding arrays.  That is easier than it sounds.  There are articles explaining how and libraries providing linear interpolation in C, some of which may be usable without modification in an Arduino sketch.
Bonding the Strain Gauges
There are many articles available on using strain gauges and how to rigorously clean the surface and position and orient the gauges before bonding them to the metal of the spring.  That's critical.  They have to point in a particular direction, and the bond will come apart if you don't clean the metal well enough, which would not be good.
Going High End
If you wanted high accuracy, you could enhance your design to possibly get three or more significant figures as you reach expert level.

Read and factor in temperature when doing the interpolation
Take more than 10 calibration samples and use larger arrays to match
Use a quadratic or cubic interpolation instead of linear
Write a calibration algorithm to fill the two arrays with new values
automatically every time the door goes from one extreme position to
the other


text:
Arduino Uno ADC behavior in free running mode
I'm using my ATmega328P to sample an analog signal in free running mode. The ADC clock frequency is set to ÷128. I've read that a single analog conversion lasts 13 clock cycles. I would like to know if the number of clock cycles changes if I make the ADC trigger an interrupt after every conversion (ADIE bit set to one). Or will the ADC still use 13 clock cycles and start again on the 14th?
If ADIE is set to zero (no interrupts) will the result of the conversion still be written to ADCL and ADCH? And at what time of the 13 clock cycles is this result written to those registers? This is important to me so I can calculate how much time I have to read those registers.
Would it be possible to set ADIE to zero and instead use a timer interrupt to read ADCL and ADCH every ~1 millisecond. Or am I missing something important?

What are you trying to achieve? 13 clock cycles are way below 1 ms.

Can no one answer these questions about the adc behavior (1. & 2.)? It isn't really made clear in the data sheet. I know that 13 clock cycles are below 1 ms but those questions are still important to me.

You might take a look at Amanda Ghassaei's tutorial on Arudino Frequency Detection, she has a neat trick where she toggles a pin in her ISR to get a mark on a scope trace which allows her to see the time interval between ADC conversions.

Yes, it would still be written to the ADCx registers, or just test it out? But why would you want to read out the ADC value if it hasn't changed? How you mean, how much time you have to read it out, these are two registers and could be read in like 2 or 3 cycles. Are you afraid the reading and writimg would be at the same time?

I want to sample with a constant rate of ~1000/500/200 Hz. The ADC runs in the background with a frequency of 9615 Hz, so I  only need every ~10th/... result. I don't want to interrupt the processor everytime an conversion finished bc I don't need those results. That's why I want to set a timer interrupt to read those values from ADCL and ADCH with the right frequency.

In that case, why don't you use the timer to read the value, and then start a new conversion, instead of using free running mode.

You may want to take a look at Amanda Ghassaei's tutorials on Arduino DSP techniques or the FFT/FHT code at the Open Music Labs. Both use the Arduino ADC in free running mode. Amanda's code uses interrupts, the Open Music Lab code sits in a tight loop waiting for the conversion to complete.
Based on the Open Music Lab code I can say, yes, the conversion is still written to ADCL and ADCH regardless of the interrupt setting in ADIE. I can't tell from your question how concerned you are about cycle counts, but I don't think you'd see a significant change using interrupts (I'd expect it to be zero). But using interrupts you'll take a hit as you enter and return from the ISR.
As I mentioned in the comment, take a look at Amanda Ghassaei's code. She toggles pin 12 which creates a spike in the trace if you have a scope attached to pin 12 (or a logic analyzer). That will give you a very easy way to determine the actual time to handle the conversion.

So the result is written to ADCL and ADCH at some time (probably at the end) of these 13 clock cycles and I can read those registers until the same time in the next round (then they are overwritten)?


text:
Declaring Variables in a For Loop
I am trying to use a for loop for getting readings on two parallax ping sensors and want to find the difference between both readings.
But am having trouble doing so. Whenever I declare print ping(1), I don't actually get the value of ping(1). How can I have two variables for ping(0) and ping(1) that I can call whenever I want and have them be accurate.
Code
int ultraSoundSignalPins[] = {5,7};
int tx = 4;
char *pingString[] = {"Ping1 ","Ping2 "}; // just something to print to indicate direction

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

void loop()
{

 unsigned long ultrasoundValue;
 for(int i=0; i < 2; i++)
 {
   ultrasoundValue = ping(i);
   Serial.print(pingString[i]);
   Serial.print(ultrasoundValue);
   Serial.print("cm, ");
   delay(500);

 }
}

//Ping function
unsigned long ping(int i)
{
 unsigned long echo;

 pinMode(ultraSoundSignalPins[i], OUTPUT); // Switch signalpin to output
 pinMode(tx, OUTPUT);
 digitalWrite(ultraSoundSignalPins[i], LOW); // Send low pulse
 digitalWrite(tx, LOW);
 delayMicroseconds(2); // Wait for 2 microseconds
 digitalWrite(ultraSoundSignalPins[i], HIGH); // Send high pulse
 digitalWrite(tx, HIGH);
 delayMicroseconds(5); // Wait for 5 microseconds
 digitalWrite(ultraSoundSignalPins[i], LOW); // Holdoff
 pinMode(ultraSoundSignalPins[i], INPUT); // Switch signalpin to input
 digitalWrite(ultraSoundSignalPins[i], HIGH); // Turn on 0pullup resistor
 echo = pulseIn(ultraSoundSignalPins[i], HIGH); //Listen for echo
 return (echo / 29.1); //convert to CM then to inches
}

Your question is not very clear. Where did you put the print statement, what did you expect, and what did get printed instead?

I'd convert ultrasoundValue into an array, just like ultraSoundSignalPins. That way you can retrieve both values using ultraSoundSignalPins[0] and ultraSoundSignalPins[1]

can you maybe lead me to how i would do that

unsigned long ultrasoundValue[2] and ultrasoundValue[i] = ping(i);.

license: Creative Commons - Attribution Share-Alike - https://creativecommons.org/licenses/by-sa/4.0/


text:
Problem with serial driver for CH340G board
I bought a USB Nano V3.0 ATmega328 16M 5V Micro-controller CH340G board For Arduino and tried it with Arduino 1.6.6 on my MacBook Pro running OS X 10.11.1
The USB serial could not be seen. I searched on the web and found a few posts about this board, and downloaded http://www.wch.cn/download/CH341SER_MAC_ZIP.html
Most of the instructions were in Chinese, but the driver CH341SER_MAC.ZIP 资料类型：应用资料 资料大小：250KB 资料版本：1.1 更新时间：2013-12-25 seemed to install, but I cannot seem to find any /dev/tty and Arduino can't see any serial ports.
Has anyone had any success with this. (The seller has sold 18000 of these so someone may have got it working.)

I'm not sure if it's the answer, but your driver is for the CH341, not the CH340G

Well, that's what you get for buying cheap clones. Those chips are notoriously difficult to get working with OS X. Some have done it, some have failed miserably. Simplest just to cut your losses and buy a real Arduino.

I suggest you do not give overly great weight to (the great*) Majenko's advertising for "real" Arduino's. While there are indeed many substandard 'clones' the Arduino platform is, by the originator's intentions, open source, and it does much violence to their philosophy and intended open-ness of the design to disclaim "realness" for all products not made by one or two companies. The seller of the product should be able to provide drivers that work with any mainstream O/S. If the do not and cannot then by all means include them on Majenko's no-go list. I have had excellent results with ....

.... Baite electronics  Arduino compatible products. Great name ! :-). Also great price and rapid delivery (in my experience). I am not associated with the company in any way and gain nothing financially (or any other way) from recommending them. || * I consider Majenko to be very highly capable a superb source of technical advice. We may disagree on some unimportant secondary issues :-).

@FuaZe, the 340 and 341 are very similar, most drivers support both.

These cheap clones always give me a problem on a Mac, but when I have plugged them into a PC (of any age) they have always worked as expected. Don't get me wrong, I love Macs, but sometimes you have to use a PC...

Using different search criteria I found http://kiguino.moos.io/2014/12/31/how-to-use-arduino-nano-mini-pro-with-CH340G-on-mac-osx-yosemite.html
This indicated a newer driver for OSX 10.9 and above at:-
http://kiguino.moos.io/downloads/CH34x_Install.zip
It is now working OK.
PS This was probably a Mac question, but I will answer as it is mainly of interest to Arduino users.
PPS The board worked on my Raspberry Pi which had the driver installed.
WARNING
The driver worked on OS X 10.11 but after upgrading to OS X 10.11.2 when I plug the USB cable into the Mac it causes a crash. This may or may not be related to the upgrade but after this happened twice I gave up.

I think you should mark your answer as correct

This worked for me: http://kig.re/2014/12/31/how-to-use-arduino-nano-mini-pro-with-CH340G-on-mac-osx-yosemite.html

The CH340 is a chip with notoriously iffy driver support, definitely for OS X, and reportedly also for Windows. Some driver authors are not very fond of it, as evidenced by this affectionate comment
/*
 * driver for WinChipHead CH341/340, the worst USB-serial chip in the world.
 */

On the upside, the chip costs an order of magnitude less than the commonly used FTDI chips.
I've seen drivers from 3 sources:

The manufacturer drivers work off and on. The ones on the official site are not signed, and at some point, they started causing kernel panics for me.
The Codebender team is including free CH340 drivers in their installer, and I've had some success running those, although I'm having some difficulties with the latest version. YMMV.
So far, the drivers developed by Repleo have been rock solid for me. These are commercial, but, at less than $10, a pretty good deal in my opinion.

On MacOS Sierra it kept crashing the OS,  but version 1.3 works on MacOS Sierra.
Found here:  https://github.com/adrianmihalko/ch340g-ch34g-ch34x-mac-os-x-driver

Yep. That works. :-)


text:
detecting presence inside - PIR or ultrasound?
(I am professionally a software guy working in the GCC compiler with MELT, so I am fluent in software, but much less in hardware - I did use a solder for a 74LS00 nand gate based stuff in the 1990s. This is my first Arduino project)
My first Arduino project would be to automate the lights and the fan in my inhouse WC toilet in Paris (France) suburb. I bought several Arduino Nano v3 boards. I'm thinking of driving with a relay a low voltage 12v LED lightbubble. I want to detect human presence in the toilets. I'm thinking of some PIR sensor, but I am afraid that PIR won't detect anything if the temperature is above 37°C (or about 100F), which is unusual in Paris (France) but may happen a few days per year (I've got no air conditioning). Is my worry correct, or can a PIR still work with very warm outside temperature? Should I use an ultrasound detector instead?

I thought about the same thing. My ideal system would be to detect if the door is open using a hall-effect-sensor or reed-switch, and to detect if the door is locked (not quite sure what would be the ideal sensor for that). That way you can detect when people enter (open; close; lock), and when they leave (unlock; open; close).

PIR sensors work fine and are probably easier to program for than ultrasonic sensors. For example, this tutorial on a PIR sensor sold by Adafruit has a datasheet at the bottom that says:

Operating Conditions Operating Temperature -20 ˚C to +70 ˚C
Storage Temperature -30 ˚C to +80 ˚C
Operating Voltage 3 to 10 V at Rs = 47 kΩ

You can try to find and check the datasheet for the sensor you intend to purchase to determine if it will work.

One thing to be wary of with PIR sensors is that they only detect moving heat.  That means that your light would turn on as you enter the toilet, but would turn off again when the sensor fails to detect movement.  That will be once you're sat on the toilet and reading the newspaper.  To keep the light on you would need to flail your arms around to keep the sensor on, and thus the light on.
So from that perspective alone the ultrasound would possibly be a better option since it can detect the presence of anything within its cone of sound - as long as that something is big enough, like a human body.
A third option that you haven't mentioned is infra-red beams.  Depending on how big the toilet is you may be able to just have one IR beam passing through the room, and when someone is in the room that beam will be broken.  Only works in small cubicles though.  For larger rooms you may need either a mesh of beams to cover the whole room, or a dual-beam in-out counting arrangement on the entrance (two beams, one before the other. If beam A breaks before beam B then someone has entered - if beam B breaks before beam A then someone has left. When there are 0 people in the room then turn the light off).


text:
Use of additional i/o ports in Arduino Mega
I'm a newbie in Arduino and I bought an Arduino Mega instead of the Uno. I want to know what the so-called additional i/o pins do. Are they the same with PWM and SPI? What can they do?

Do a google image search for "arduino mega pinout" - there's thousands of results that show you exactly what each and every pin can do.

When asking "obvious" questions it helps to explain what you've done to find an answer for yourself – then explain why you are still confused. That way we have a better idea about your question.

Firstly some background info on the Arduino Mega:
I haven't used the Mega, but I've used the Uno, and have worked with a variety of ATmega microcontrollers.
First thing you need to know is that the Arduino Mega (or any other Arduino) is a board that uses the Atmel ATmega microcontrollers. The specific microcontroller used on the Mega is the ATmega1280 ATmega2560.
So if you are keen to learn more about your Arduino, a good place would be to look at the datasheet of the microcontroller itself. Just google ATmega1280 ATmega2560 datasheet.
However this might be a fair bit complicated, since you are new to the Arduino and microcontroller world.
A good place to start would be the Arduino website itself (but I suppose you've already looked at it).
Now, regarding your question:
I'm not sure what you are referring to as "additional i/o pins", but here's a quick rundown on what I/O pins are and used for.
As you may know I/O pins are used by the microcontroller to talk to the outside world. On the ATmega chips, most of these are GPIOs (General Purpose I/Os) that can be programmed to receive or send digital signals. Of these GPIOs some are used for PWM, and some may be used for some communication protocol. And of course there are analog input & reference pins, voltage supply, ground etc.
You can find all this information in the datasheet I linked above.
If you are curious how Arduino has routed the pins, you can have a look at the schematic of the Arduino Mega here.
If you also have a look at the Arduino website, they have a very good description on what each pin does: Arduino Mega.
Look at "Inputs and Outputs".

Even though the poster said he bought an "Arduino Mega", what he almost certainly bought is an Arduino Mega 2560, so the microcontroller in question is an ATmega2560 (Identical to the ATmega1280, except that it has twice the flash capacity).

Additional I/O pins means more inputs and outputs. Therefore, you can have more signals. There are also some more specialized pins. For example, there are more PWM pins, more TX and RX pins for serial communication and more analog read pins.