message:
How many LED Strips can we connect to an Arduino Uno? Is there a way to connect 1-3 meters worth without needing extra parts (relays)?

I am looking at Adafruit to purchase some LED strips for a mod for my computer case, and want to power it with an Arduino.

I am looking at the Uno, but the Mega looks good too.  I hear the Uno is good because if the chip fries, you can just replace it easier than the Mega's chip.  I did hear that the Uno chip had issues, but that was a 2013 post.

Anyways, I am essentially looking to connect about a foot of 144 leds/m to the front of my case, and connect that to the Arduino.  I will then be lining the inside of my case with about 12-15" per side (x4 sides) of 60 leds/m so I wanted to connect that to another part of the Arduino.

I read that each led takes something like 6mA or 60mA each, so that is what we should watch for.  I was trying to search for this question that others asked, but people were looking to connect a lot of strips, and needed relays and whatnot, so I wanted to make sure the Arduino itself could power about 1.5 to 2 meters of Led strips in at least 2 different strip configs (or whatever you want to call them).

I also am curious if there will be an issue programming each strip setup or, if it just is a little more work to get it setup?

Since this is a computer cause led setup, I'm not sure if I should go USB power, or a wall charger?  What is the recommended approach for something like this?

I will definitely be reading up more tutorials and all that important stuff, but I want to buy the stuff now since I realized there's a cyber Monday deal going on, so I don't want to miss out...

Any help is appreciated, thank you!

body:
Yes, the current draw is the main factor here.  That's not really an Arduino issue though, as I will enlighten you about later on when I talk power supplies.

**I assume, since you don't mention what the LEDs are, that you are talking about strips of WS2812 "NeoPixel" LEDs (the ones where you can control the colour of each and every individual LED).**

I would recommend keeping all the LEDs as one single strip.  That doesn't mean you can cut the strip into segments, just join the ends to each other using wire in one chain.  That way you just have one chain to deal with in the Arduino.  Running multiple chains can be somewhat more resource hungry and I'm not even sure it's possible on an Arduino.  So keep it all as one long chain split into chunks and re-joined with wire.

Now for power.  Your computer has a big powerful power supply in it.  That gives a very good regulated 5V supply with many many amps available.  More than enough to run hundreds of LEDs.  By all means run the Arduino from USB (makes for easy programming - inspect your motherboard, it may well have an internal USB connector that would be ideal (I know mine has).  And then run the LEDs themselves off the +5V direct from the computer's power supply.  A spare hard drive power connector could be good for that.


sender: user

sender: assistant

body:
The important thing to understand here is that there are two things going on:

1. Powering the LEDs – that's the big power draw and it makes a ton of sense to do that off of the computer power supply.

1. Controlling the LEDs – that'a a very small load, using one (NeoPixel et al.) or two (DotStar et al.) pins on the Arduino. So there is no need to do anything fancy, you should have more than enough drive in the Arduino pin(s) to handle the LED control.

You might want to take a look at the [FastLED][1] library (or head directly to the [GitHub repo][2]) it explicitly support multiple strands of LEDs (and interchangeably supports a whole slew of LED type including NeoPixels and DotStars. I think, but haven't tried, you could support multiple strands of NeoPixels by creating several instances and giving each instance its own pin.

DotStars come (if you get a "finished" end) with a connector that has all four wires (Vcc, Gnd, data, and clock) as well as two additional wires for "bulk" power. But if you don't get a finished end you would just solder to the pads that are at each cut point. You probably want to power the strip(s) in parallel – feeding them from each end so that the LEDs at the end don't see too much of a voltage drop.

[1]: http://fastled.io
[2]: https://github.com/fastled/fastled


body:
The other answers you have here cover the points well, just to offer my $0.02.

# Using a wall adapter
It's really not necessary to use a separate wall adapter and you'd be adding another layer of complexity unnecessarily. So don't bother. Also with a wall adapter you would have to consider grounding it to the computer's power supply, not necessarily an issue, but not required if you use internal power.

# Powering your LEDs
your computers power supply is more than capable of handling EVERYTHING you've mentioned (unless you're already maxing it out, which I doubt).

Just make sure that you're powering the LEDs directly from the computer's power supply, and not from the (arduino) board itself, since that 5v is limited to 500mA from the USB connector, and definitely don't drive the main power from a data pin (I'm sure you know that—but just in case :P)

If you do split the strip (running two strips shouldn't be a problem) be sure to provide power where ever you can, ie each end, even in the middle. It will aid in providing even power throughout the strip.

# Powering the Arduino
I'd be running the Arduino off it as well, either grab a header cable off the board that has an end you could plug into your arduino and mount it inside, or feed a USB cable through the back and use one of the extra external USB ports. A bonus of running it outside would be you could physically reset the board by unplugging it :) or simply turning it off by doing the same.


message:
Using digital pin 11 for DMDCon and IR remote

I have a project where I would like to control a countdown clock using a remote with:

Arduino Uno R3 Development Board

Funduino Uno Protoshield Board

[Freetronics Dot Matrix Display Connector][1]

[Arduino IR Reciever][2]

Both the DMDCon and the IR use digital pin 11. Can these two share the pin 11 or is there a workaround of sorts?

  [1]: http://cdn.shopify.com/s/files/1/0045/8932/files/DMDCON_DMDConnector.pdf?100730
  [2]: https://arduino-info.wikispaces.com/IR-RemoteControl

body: The workaround would be to configure the https://github.com/shirriff/Arduino-IRremote library referenced in your question to any available digital input.


message:
Looking at Adafruit's website I'm confused which wallcharger I should get

As the title says there are many different wall chargers to choose from.

12v, 9v, 5v, with different mA amounts...

The starter kit on Adafruit's website mentions to get the 9V 1000mA switching power adapter, so I'm curious if that's what we should get?

here is the link to all of them.

There are regular wall adapters, and these big power supplies...

http://www.adafruit.com/search?q=switching+power+adapter&b=1

I'm just looking to run some LED Strip lights from the arduino and power some joystick buttons, some rotary encoder/knobs, and a keypad to work the LED lights

Thoughts?

Thanks!

body:
This website looks like a pretty official answer for you.
http://playground.arduino.cc/Learning/WhatAdapter

> Since you'll probably be connecting other things to the Arduino (LEDs, LCDs, servos) you should get an adapter that can supply at least 500mA, or even 1000 mA (1 ampère). That way you can be sure you have enough juice to make each component of the circuit function reliably.

And

>  The Arduino's on-board regulator can actually handle up to 20V or more, so you can actually use an adapter that puts out 20V DC. The reasons you don't want to do that are twofold: you'll lose most of that voltage in heat, which is terribly inefficient. Secondly, the nice 9V pin on the Arduino board will actually be putting out 20V or so, which could lead to potential disaster when you connect something expensive to what you thought was the 9V pin. Our advice is to stick with the 9V or 12V DC adapter.


body:
Your Arduino Uno will use 35 to 50 mA at 5V.  The  “joystick buttons, some rotary encoder/knobs, and a keypad” will draw a small amount of current, probably between 1 and 10 mA.  Thus, power for the Uno and your controls will be well under 100 mA and can be supplied via USB without any problem.  (Also see: *[How to get more than 100mA from a USB port](https://electronics.stackexchange.com/q/5498)*.)

If your Uno enumerates and negotiates to get 500 mA via USB, you might have 450 mA available out of the +5V pin.  However, in some cases if you need more than a few dozen mA to power other devices, it will make sense to get a separate 5V supply for them.  (Eg, if the devices drag down the +5V and cause the Uno to reset, or if the devices are electrically noisy, like motors, RC servos, relays, solenoids.)  Also, note that [thread #70450](http://forum.arduino.cc/index.php?topic=70450.0) at forum.arduino.cc says you can draw 650 mA (or 3.25 W of power) when the Uno is powered via its DC power jack.

If your LED string has up to 6 or 7 WS2812B equivalents, you can power it from the Uno's 5V.  Here is the all-lights-on, full-brightness calculation for six of them:  6 WS2812Bs x 3 LEDs per WS8211 x 21 mA per LED = 378 mA.  For seven:  7 x 3 x 21 mA = 441 mA, which is out there on the edge.

For longer LED strings, figure on a little over 3 W of power for every 10 WS2812B equivalents.  (Calculation: 5 volts x 10  WS2812Bs x 3 LEDs per WS2812B x 21 max mA per LED = 3150 mW = 3.15 W.)  For example, get a 10 W (2 A x 5 V) or greater 5V power supply for a meter of 30- WS2812B-per-meter LED strip, etc.  This power supply will connect directly to the LED strip's power connectors.  The ground from the LED strip will connect to the Uno's ground, to establish a signal reference point.

Note, the absolute max voltage rating for a WS2812B, according to its datasheet, is 5.3 V, so use a supply whose voltage does not exceed 5.3 V.  The absolute min voltage rating is 3.5 V; they will work ok on 3.7 V LIPO batteries, but 3V3 power is out of spec for a WS2812B.

As mentioned in a previous question, if your LED strip is being installed inside a desktop PC, the PC's power supply will have lots of 5 V power available, and you can hook on to one of the red +5V wires and black Gnd wires from its supply to power the LEDs, either while powering the Uno itself from USB power or while using the same +5V to power the Uno as the LEDs.


message:
Is my Arduino Uno broken?

I think I broke my Arduino Uno as I was playing with it. I connected an ultrasonic range finder to it and uploaded a sketch to it. It was working fine until I accidentally touched the ICSP headers for the USB interface (the pins near the USB port). Now,everything is still working but my computer cannot detect it and it does not show up in the device manager or the IDE. Please tell me if it is broken and how to fix it.

BTW, I just bought it and just started using it after another Arduino had the same problem.

body:
> Please tell me if it is broken and how to fix it.

See https://arduino.stackexchange.com/questions/13292/have-i-bricked-my-arduino-uno-problems-with-uploading-to-board

Those tips may also help with fixing problems with your Mega (if you ever have them). ;)


message:
How can I connect the MP503 to an Arduino Uno (Smoke, Alcohol Sensor)?

I don't know how I can connect an MP503 sensor to my Arduino.

Please help.

[![enter image description here][1]][1]
http://eleparts.co.kr/data/design/product_file/SENSOR/gas/MP503 (Ver1.4) - Manual.pdf

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

body:
Ok, first of all I doubt you will be able to get a lot of measurements with that. Because... I know that kind of sensors and you will quickly get tired of it.

Anyway, you have to connect

1. pin 1 to +5V
2. pin 2 to ground
3. pin 3 to +5V
4. pin 4 to a resistor towards ground. Value has to be determined.

To chose the value, you have to try. Change resistor values until, in fresh air, the voltage you can sense across the resistor is approx 1V. I think it is arount 10k, but you'll have to try

Chosen the resistor, you have to simply attach the node between pin 4 and the resistor to an analog input and then read the voltage.

Now you have to calibrate the sensor. Put it in a fixed-concentration gas and measure the voltage: `nCalib = analogRead(sensorPin);`.

Then, when you need to measure the concentration, you just have to read the voltage again with `nMeas = analogRead(sensorPin);`. The factor Rs/Ro can be calculated with the formula

    Rs_over_Ro = nCalib / (1024 - nCalib) * (1024 - nMeas) / nMeas;

Once you have the factor, look at the graph in figure 3 to get the concentration:

[![figure 3: sensitivity for Mp503][1]][1]

As I told you, I think you will quickly get tired of it, but this is how to use it.

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


message:
Leostick Receiving message from Uno using USB jumpers cables

I have a Arduino Uno which is looping over Serial.println("$testmessage"). Connected to this is a USB cable that i have cut and soldered male jumper leads to . I need to receive this message ("$testmessage") from the Uno using this USB cable without using the leosticks usb connector. After receiving the correct messgae from the Uno i plan to use Serial to send data from the leostick to my pc.

I'm stuck trying to figure out how to receive this message from the Uno.

Currently the the USB 5v and ground is connected to the leosticks 5V, GND pins. The Uno powers on and the the tx led is flashing every 100 milliseconds.

Can i just plug the green and white wires from the USB cable into D0&D1 and except it to work?

(Uno plugs into usb cable in the image)
https://i.stack.imgur.com/M0kbb.jpg

body: I don't think this has any chance of working. You can't use USB to interface between the two devices, as the Leostick can't work as USB host. Your best bet is to use (software) serial.


body:
While USB *is* a serial protocol, it's a completely different serial protocol than the RS-232-style logic-level serial protocol that the Serial library supports.  So the approach mentioned in the question has no logical chance of working.

  Also, the USB electrical signal is differential (double-ended, or line-to-line, rather than single-ended, or line-to-ground).  So the mentioned approach has no electrical chance of working.

What may work is to wire from Tx on the Uno to Rxd1 on the Leostick, and from Rx to Txd1, unless that conflicts with the Leostick's USB-Serial link.


message:
Newbie and string of 300 WS2811s

I’m trying to make a string of 300 Christmas tree lights where the colour of each of the lights is entirely controllable by my own code. I am a programmer so that side of things is the easy part as far as I’m concerned.

My researches so far have led me (no pun intended) to WS2811s driven by an Arduino. I prefer the look of these to the flat Adafruit-type ones. I don’t own an Arduino yet but have been dipping my toe into this site for quite a while now so am beginning to understand the basics.

I’ve established that I will need to have a fairly hefty 5volt power supply for the LEDs but that the Arduino itself can then run happily on its own USB supply.

Some of the things I’ve read seem to imply that the Arduino will struggle to process my program and supply the data to 300 LEDs at the same time, but it’s not clear what the problem will be. I assume each LED will continue to glow with the same colour until it receives the data for its next colour and the code for “Fire!” which then prompts all of them to switch to their next colour. Is this wrong?

I realise that 3 bytes per LED for 300 LEDs is a fair amount of data to keep having to send up the wire. I will also be having an array in the program to keep track of all 300 colour values.

Will this work? Can you offer any advice that might mean I don’t hit a brick wall somewhere when putting all this together?

body:
I don't think you'll have any problems. The LED's have a data rate of 800kbps, so you can theoretically push out 110 frames per second if your Arduino does nothing but transmit data. If you keep the routine that updates the colors fairly efficient then you'll have nothing to worry about.

Note that the array storing the colors would take up 900 bytes of memory, leaving you with only 1100 bytes for everything else your program would need to store (which should be fine).


message:
Arduino is freezing after 10-15 minutes

I am having a problem with my Arduino freezing after a small amount of time. I'm using an RTC DS1307 breakout to keep track of the time and display the time on an LCD. It displays hours, minutes and seconds (updated every second).

Then I have 25V which is supplied by a transformer and connected to a set of LEDs through a [CAT4101][1] constant-current sink LED driver. The Arduino board is powered by a 2amp USB transformer.

At a set time, the timer should set off the process to dim the lights.

Everything is working well if I set the lights to dim within a few minutes. However, if I leave the board on for more than 10-15 minutes then everything seems to freeze (i.e. the time on the LCD stops being updated and stays stuck at the moment it froze).

I originally thought it could have been something to do with my code. But I then skimmed everything down to the bare essential and just uploaded the code necessary to update the time on the LCD. And even in this case it freezes.

The only way I managed to avoid things freezing was to disconnect the CAT4101 pin 1 from Arduino's PWM and disconnect pin 2 from Arduino's 5V.

What could be causing this issue?

CAT4101

    pin 1 = connected to Arduino PWM
    pin 2 = connected to +5v
    pin 3 = connected to ground
    pin 4 = connected to ground with 2kOhm resistor
    pin 5 = connected to LED cathode

**UPDATE**

Code below (I have stripped down the code by removing any additional functions and leaving only the bare code which is leading the application to crash).
<!-- language-all: lang-cpp -->

    #include <Wire.h>
    #include <RTClib.h>
    #include <LiquidCrystal.h>

    RTC_DS1307 rtc;
    DateTime now;
    LiquidCrystal lcd(7, 8, 9, 10, 11 , 12);

    void setup() {
      Wire.begin();
      rtc.begin();
      lcd.begin(16,2);

     if (!rtc.isrunning()) {
        Serial.println("RTC is NOT running!");
        // following line sets the RTC to the date & time this sketch was compiled
        rtc.adjust(DateTime(__DATE__, __TIME__)); // time = hh:mm:ss format, e.g. 06:01:01
      }

      lcd.clear();
    }

    void loop() {
      now = rtc.now();
      updateDisplay();
    }

    void updateDisplay(){
     int h = now.hour(); // Get the hours right now and store them in an integer called h
     int m = now.minute(); // Get the minutes right now and store them in an integer called m
     int s = now.second(); // Get the seconds right now and store them in an integer called s

     lcd.setCursor(0, 0); // Set the cursor at the column zero, upper row...
     lcd.print(" The time is: "); // ...with spaces to clear characters from setting alarm.
     lcd.setCursor(4, 1); // Move the cursor to column four, lower row
     if (h<10){   // Add a zero, if necessary, as above
      lcd.print(0);
     }
     lcd.print(h);   // Display the current hour
     lcd.setCursor(6, 1); // Move to the next column
     lcd.print(":");  // And print the colon
     lcd.setCursor(7, 1); // Move to the next column
     if (m<10){   // Add a zero, if necessary, as above
      lcd.print(0);
     }
     lcd.print(m);   // Display the current minute
     lcd.setCursor(9, 1); // Move to the next column
     lcd.print(":");  // And print the colon
     lcd.setCursor(10, 1); // Move to the next column
     if (s<10){   // Add a zero, if necessary, as above
      lcd.print(0);
     }
     lcd.print(s);   // Display the current second
    }

[![enter image description here][2]][2]

  [1]: http://www.onsemi.com/pub_link/Collateral/CAT4101-D.PDF
  [2]: https://i.stack.imgur.com/WPClR.png

body:
I would add a `delay(100);` to the bottom of your loop()

I'm betting even odds that solves it.


message:
I2C connection with MT9D111 camera module, strange results after writing registers via i2C

I am currently working on a camera platform based on the MT9D111 module from Micron. The first thing to do is to write the configuration to the numerous registers of the chip which is done via an i2C connection.

I adapted the code from [here][1] for testing this with an Arduino Uno. 3.3V supply and 8MHz clock are also provided by the Arduino.

Everything seems to work fine, but there are some odds which I don't know the reason for.

So here is the code (I just added the soft reset sequence according to the Developers Guide):

    const int freqOutputPin = 9;   // OC1A output pin for ATmega328 boards

    #define TMR1 0

    #include <Wire.h>
    #include <avr/io.h>
    #include <util/delay.h>
    //#include <TimerOne.h>
    #include <avr/interrupt.h>

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

      TCCR1B |= (1 << CS10);  //selecting prescaler 0b001 (Tclk/1)
      TCCR1B &= ~((1 << CS12) | (1 << CS11)); // turn off CS12 and CS11 bits
      TCCR1A |= ((1 << WGM11) | (1 << WGM10)); //Configure timer 1 for TOP mode (with TOP = OCR1A)
      TCCR1B |= ((1 << WGM13) | (1 << WGM12));
      TCCR1A |= (1 << COM1A0); // Enable timer 1 Compare Output channel A in toggle mode
      TCCR1A &= ~(1 << COM1A1);
      TCNT1 = 0;
      OCR1A = TMR1;

      delay(500);  //Initial delay
      Wire.begin(); // join i2c bus as master
      Serial.begin(9600);
      Serial.println("MT9D111 Camera Module + Arduino");
      Serial.println("Read and Write 16-bit register value example");
      Serial.println("*  Read expected value = 0x1519 from Register 0x00");
      Serial.println("*  Write value = 0xA5F0 to Register 0x20:1");
      Serial.println();
      init1(); //execute code just 1 time
    }

    void loop() {
    }

    void init1() {
      int16_t a;

      delay(500);  //wait until start
      Serial.print("Soft reset first");
      Serial.println();
      soft_reset();//do a soft reset at startup

     //***************Configuration here!****************//
      Serial.print("Read result from register 0x00");
      a = read_reg(0);
      Serial.println();
      Serial.print("0x");
      Serial.println(a, HEX);  //print result
      Serial.println();
      Serial.print("Read original data from register 0x0a, should be 11");
      Serial.println();
      a = read_reg(10);
      Serial.print("0x");
      Serial.println(a, HEX);  //print result
      Serial.println();

      //Enable this part for writing register
      //Some example reads and writes follow
      Serial.print("Writing 0xA5F0 in register 0x20:1");
      Serial.println();
      write_reg(32, 1, 165, 240);
      Serial.print("Read new value from register 0x20:1");
      Serial.println();
      a = read_reg(32);
      Serial.print("0x");
      Serial.println(a, HEX);  //print result
      Serial.println();
      Serial.print("Writing 0xA1F3 in register 0x20:1");
      Serial.println();
      write_reg(32, 1, 161, 243);
      Serial.print("Read new value from register 0x20:1");
      Serial.println();
      a = read_reg(32);
      Serial.print("0x");
      Serial.println(a, HEX);  //print result
      Serial.println();
    }

    //Write 2Byte register
    void write_reg(int reg_address, int page, int data_msb, int data_lsb) {
      delay(5);  //5ms
      Wire.beginTransmission(93); // transmit to device 93, Camera Module
      Wire.write(240);   //page register address
      Wire.write(0);
      Wire.write(page);   //select page 0/1/2
      Wire.endTransmission(1);    // stop transmitting
      Wire.beginTransmission(93); // transmit to device 93, Camera Module
      Wire.write(reg_address);   //register address 8bit, decimal
      Wire.write(data_msb);  //msbyte
      Wire.write(data_lsb);  //lsbyte
      Wire.endTransmission(1);    // stop transmitting
    }

    //read 2Byte register
    //be careful about selected register page
    int16_t read_reg(int reg_address) {
      int16_t err;
      delay(5);  //5ms
      Wire.beginTransmission(93); // transmit to device 93, Camera Module
      Wire.write(reg_address);   //register address 8bit, decimal
      err = Wire.endTransmission(1);    // stop transmitting
      Serial.println(err);
      Wire.requestFrom(93, 2, 1); //request value form device 93, 2 bytes with stop bit
      int16_t result = ((Wire.read() << 8) | Wire.read());  //read 16 bits
      return result;
    }

    //Perform Soft reset, required at startup
    void soft_reset(){
      write_reg(101, 0, 160, 0);//write registers according to dev guide
      write_reg(195, 1, 5, 1);
      write_reg(13, 0, 0, 33);
      delay(5);
      write_reg(13, 0, 0, 0);
      delay(5);//wait for i2c to be ready again
    }

Running this code gives me the following result on the serial monitor:

[![Serial Monitor][2]][2]

So here are the questions:

 1. Do you have any ideas why I get an extra FFFF when reading a register after writing it? (underlined in blue)
 2. Why are there some extra zeros in the output? (marked in yellow)

  [1]: https://hackaday.io/project/6386-usensecam/log/20618-checking-mt9d111-communication
  [2]: https://i.stack.imgur.com/8j3Tr.png

body:
The `0` comes from your code:

    Serial.println(err);

It's printing the error code. 0, hence no error.

As for the extra `FFFF` I'd say it's because you are using signed integers. Change your `a` declaration to `uint16_t` and see if that fixes it.


message:
Arduino RTC - getting the time from RTC after the power is cut off

I have a new DS1307 (original, not a Chinese rip off), with a new battery. It is working great, but when I turn the Arduino off (it is currently connected to laptop) and then turn it back on, it resets the time.

The line that sets the time is (in setup part of code):

    setDS1307time(30, 42, 21, 4, 26, 11, 14);

So, when the Arduino gets the power back it runs the program again and it overrides the correct current time.

How can I avoid this?

body:
Without knowing the DS1307 well, I think there are two options:

1. Make the setting of the clock a UI function (you should probably do this in any case since you will want users to have the ability to set the clock). The user would have to initiate the action (and put in the time to set) so there would be no problems the clock getting reset inappropriately, or

1. Do a check for sanity of the clock before you run that line. You might be able to do that through the clock API (e.g., make a call to check the time, or to get the clock status and see if it makes sense) or you could do it by storing the clock status in nonvolatile memory. The very worst case would be that you store the time of last boot and check that it seems reasonable (e.g., the time you get from the RTC is after the last boot and is within reason – say no more than a month or a year ago). If the time is too far off to feel confident you could issue a "check time" warning.

If you have a network connection using NTP as well as the RTC would be a very smart option. NTP can hold the time within a few milliseconds. The RTC would then provide you with protection against a network outage.

If you are using the Arduino to manage scheduled events one thing you'll want to think about is events that are scheduled in a moment of time that is either "skipped" as you advance the clock or that "repeats" if you set the clock back. One way to handle that is to never "jump" time, but to always just speed it up or slow it down.


body:
If setup() runs, it is because the system has been restarted. It could becuase the reset button was pushed, or it could be due to a power-cycle. But either way, the code will start over completely. So you could

 1. Deal with restart issues in setup() as it will only be called once per session (unless you call it in your own code); or

 2. Make a variable `static boolean PowerCycled = true;` and clear it once your code has dealt with its re-start issues. After a restart, the initialzed data will get reloaded, including `PowerCycled` with it's initial value of `true` restored.


message:
Issue sharing MISO with multiple RC522 RFID Readers

so for about the last 8.5 hours (almost non-stop) I have been trying to figure out one issue and I have exhausted every search I could possibly think of.

I'm building a puzzle that requires 5 RFID readers on the 1 Arduino, but for the sake of testing i've only been using 2.

Both readers work independantly, I can read out the UIDs of the little cards, which is all I need to do, but as soon as I make them share the MISO line, it simply stops printing anything out. I have no idea why.

Both readers have a common external 3.3v power supply and ground, they share all other lines but have an individual Slave Select. For testing I put both of their MISO cables into a breadboard which then leads into the Arduino on PIN 12, but it will only print out the UID when only ONE cable is plugged into the breadboard.

So is there something special I need to do to make this work? Is there a reason why the readers sharing a MISO line would break it? Even if i don't initialise one of them, just for the fact that it's plugged in still breaks it. I have tried setting one to HIGH and one to LOW, both to LOW, both to HIGH, nothing changes it.

Also, something else kind of confusing to me, it's meant to be active LOW to activate the SS, but when only 1 is plugged into the MISO line, it doesn't seem to matter which state it's in, it always prints...

I did a little bit of testing on my sketch just a moment ago and realised that when both are plugged into the MISO, the sketch will not progress past this line (which is also the first line in the loop)

    if ( ! mfrc522_2.PICC_IsNewCardPresent())
            return;

I know everything else is working because it works when there is nothing else plugged into the MISO line, but I need it to work when all the others are plugged in too.

Please please please, if you have any idea, let me know.

I'm using the MFRC522 Library

EDIT:

This is basically the setup i'm using:
[![enter image description here][1]][1]

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

I'm not using any voltage translators or shifters, everything is 5v from the arduino except for the power to the readers which is coming from an external 3.3v supply like mentions previously.

I'm pretty certain that this is the datasheet for the RC522 i'm using, though i'm not sure if it's V1 or V2, but given the differences between them I don't think it matters:

http://www.nxp.com/documents/data_sheet/MFRC522.pdf

I don't know if they are able to share MISO lines like someone below said, I just assumed I could?

body:
Looking at the [datasheet for the MFR522][1], it is not clear that it even supports multidrop SPI. It does not mention anything about the state of the SPI output pins when the chip is not selected. It also mentions that the chip uses the slave select line to detect what communication mode to use upon startup, but does not mention anything about how the chip will react to changes on that pin after startup.

Considering this, along with the fact to your library also does not seem to support connections to multiple MFR522, my guess is that this chip only supports a 1-to-1 SPI link.

Further, the SPI Timing characteristics in the datasheet specify how lon gthe SS (called NSS) must be high before communication can begin, but does not specify how long after SS goes low that the MISO goes tri-state, which would be an important thing to know if the chip did support multidrop SPI.

This is all backed up by the behavior you are seeing. If both chips are driving the MISO line simultaneously, then communication will not be possible when both are connected.

To support multiple MFR522 connections, you could possibly...

1. Use a multiplexing buffer to only enable SPI lines to one chip at a time. Downside is you would need Extra hardware, but upside is that you could probably use existing library intact by selecting the desired MFR522 before making the linrary calls.

2. Connect each MFR522 to different GPIO pins on the Arduino and bit bang the SPI to each chip independently. Upside is that you don't need any extra hardware and you potentially have a lot of flexibility on how you access the MFR522's. Downside is you will have to retrofit this bit-banged SPI into the library or use (or write) a different library.

I've seen this question come up many times over the years, so if you do choose option #2, please publish your code so others can use it!

# An Experiment

I'd propose you do this to find out if your chips are compatible with multi-drop SPI...

1. Power up your system with a RC522 reader.
2. Check and make sure it works.
1. Disconnect the SS and MISO lines from the RC522 so they are no longer connected to the Arduino (or anything else). Leave the RC522 powered up - if it resets it might loose the auto-detected SPI configuration.
2. Use a jumper to connect the SS line to ground.
3. Connect the MISO line to ground with a 1K ohm resistor.
4. Use a multimeter to check the voltage on the MISO line.
5. Connect the MISO line to Vcc with the 1K ohm resistor.
6. Use a multimeter to check the voltage on the MISO line.
7. Connect the SS line to Vcc.
8. Repeat steps 3-6.

Report back the table of the 4 voltage readings you got and we should have our answer!

  [1]: http://www.nxp.com/documents/data_sheet/MFRC522.pdf


body:
I am joining this conversation VERY late, however maybe my answer can help someone who is just now looking into this.

I was able to get SEVEN RC522 readers working on one Arduino! My solution was very similar to your idea, except instead of the SS pin, I used the MISO pin.

[![Unique MISO diagram][1]][1]

If you look into how the pins work, all of them are outputs going from the master (Arduino) to the slaves (RC522), EXCEPT for the MISO pin which is an input going from the slaves to the master.

So I gave each RC522 scanner it's own MISO pin on the Arduino, and the rest of the pins were shared with all the scanners.

To get it working with the code, the simplest solution I found was to initialize a new RFID using the corresponding MISO pin each time I wanted to read from one of the RC522s.

This worked for the Arduino because you can set several of the digital pins as MISOs, however I haven't figured out how to get this working on a Raspberry Pi yet (without using a multiplexer) because the Pi has a few specific pins that are used for MISO.

I was using the old Sunfounder library. At the bottom of this page (http://wiki.sunfounder.cc/index.php?title=Mifare_RC522_Module_RFID_Reader), if you download the "RFID-RC522_test_experiment" zip file it will have the library included. Just copy and paste the RFID1 folder into your Arduino Library folder. Here is a simple tutorial for that library: https://www.sunfounder.com/learn/RFID_kit_V1_for_Arduino/lesson-29-rfid-entrance-guard-system-rfid-kit-v1-0-for-arduino.html

Here is some example code. It is pretty ugly but it worked.

    void checkRFID(int i){
      if(i==0){
        rfid.begin(2,4,5,7,3,6);
      }
      if(i==1){
        rfid.begin(2,4,5,8,3,6);
      }
      if(i==2){
        rfid.begin(2,4,5,9,3,6);
      }
      if(i==3){
        rfid.begin(2,4,5,10,3,6);
      }
      if(i==4){
        rfid.begin(2,4,5,11,3,6);
      }
      if(i==5){
        rfid.begin(2,4,5,12,3,6);
      }
      if(i==6){
        rfid.begin(2,4,5,13,3,6);
      }
      delay(100);
      rfid.init();
      uchar status;
      uchar str[MAX_LEN];
      // Search card, return card types
      status = rfid.request(PICC_REQIDL, str);
      if (status != MI_OK)
      {
        return;
      }
      // Show card type
      rfid.showCardType(str);
      //Prevent conflict, return the 4 bytes Serial number of the card
      status = rfid.anticoll(str);
      if (status == MI_OK)
      {
        memcpy(serNum, str, 5);
        rfid.showCardID(serNum);//show the card ID
        Serial.println();
        Serial.println();
      }
      delay(100);
      rfid.halt(); //command the card into sleep mode
    }

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


body:
I do not know if every module has a pull-up resistance in sck and mosi if that is the case, it could be that for every module connected over teh lines the resistance gets lower. so maybe the module can not drop the voltage so there is no comunication. check with a multimeter the resistance between Vcc and MOSI it has to be around 4.7k generally.
hope this could help.


message:
On Arduino Due webserver, there is a 5 second delay on Windows, only when connected via native port

My Due webserver was working perfectly fine for months when connected to Linux via the native port.

But when connected to Windows 10 via the native port, if the Arduino webserver is idle for about 5 minutes (when no client calls a webpage), then there is a strange 5-10 second delay before the webpage is able to load. This delay doesn't happen when connected to the webserver via the programming port.

It almost seems like maybe Windows is putting the port to sleep when it notices an idle delay, and then it has to wait for the port to wake up before it can call the webpage.

On the Windows "Power Settings" I set the computer to never go to sleep, and also in the Power "Advanced Settings" I disabled the USB "selective suspend".

Do you have any ideas why there would be this strange delay only on Windows and only when connected via the native port?

----------
**ADDITIONS:** I made a simplified example that reproduces the problem on my machine. I wonder if anyone can see any problems with this code.

First, the python code. Note that if the python script is never run, there are no delays on the Arduino webserver, and everything works as expected.

    import serial, sys

    SERIALPORT = "COM5" # Change this to your serial port!

    # Set up serial port
    try:
      ser = serial.Serial(SERIALPORT, 115200, timeout=0)
    except serial.SerialException:
      sys.exit()

    ser.write("Hello World")
    print("Hello World")

    ser.close()

And below is the simplified Arduino code. It's just a simple webserver that serves a page that has a "reload" button that reloads the page. You can hit "reload" as many times as you want, and the program never freezes. But if you run the python code above and then try to reload the page, there is a long delay (anywhere between 10-60 seconds by my current estimate).

If you comment out all of the "SerialUSB.print" lines that are anywhere in the loop (in this simplified case, there's only 1 line at: "SerialUSB.println (data);" in the processData function), then the webpage never freezes, even if you run the python code frequently.

In my real-world example, my python code was running once a minute, causing random freezes. If I stopped the python code from running, then there were no more freezes on the webpage. I ended up commenting out all of my SerialUSB.print statements that were in the loop, and that way I could have the python code running on schedule, and my program had full functionality (except for the loss of SerialUSB.print).

    #include <Ethernet.h>

    byte mac[] = {
      0x04, 0xBA, 0xB0, 0xCC, 0xDF, 0x04
    };
    EthernetServer server(80);
    EthernetClient client;

    const byte MAX_INPUT = 25; //for processIncomingByte

    void setup ()
    {
      SerialUSB.begin (115200);
      Ethernet.begin(mac);
      SerialUSB.print("server is at ");
      SerialUSB.println(Ethernet.localIP());
    }  // end of setup

    bool processIncomingByte (const byte inByte)
    {
      static char input_line [MAX_INPUT];
      static unsigned int input_pos = 0;
      switch (inByte)
      {
        case '\n':   // end of text
          input_line [input_pos] = 0;  // terminating null byte
          if (input_pos == 0)
            return true;   // got blank line
          // terminator reached! process input_line here ...
          processData (input_line);
          // reset buffer for next time
          input_pos = 0;
          break;
        case '\r':   // discard carriage return
          break;
        default:
          // keep adding if not full ... allow for terminating null byte
          if (input_pos < (MAX_INPUT - 1)) input_line [input_pos++] = inByte;
          break;
      }  // end of switch
      return false;    // don't have a blank line yet
    } // end of processIncomingByteWeb

    void processData (const char * data)
    { //Note: since there are no GET requests in this simple example, I removed the parts for processing GET.
      SerialUSB.println (data);
      if (strlen (data) < 4)
        return;
    }  // end of processDataWeb

    void loop ()
    {
      client = server.available();
      if (client) {
        boolean done = false;
        while (client.connected() && !done)
        {
          while (client.available () > 0 && !done)
            done = processIncomingByte (client.read ());
        }  // end of while client connected

          client.println("HTTP/1.1 200 OK");
          client.println("Content-Type: text/html");
          client.println();
          client.print("");
          client.print("Reload");
          delay(10); client.stop();
      }
    }  // end of loop

This is not technically a problem for me anymore, except for having had to comment out all my "SerialUSB.print" statements. But I am interested in learning what is causing this strange behavior.

Note: the "processIncomingByte" and "processData" functions are mainly from Mr. Gammon's writings and tutorials, and they are working flawlessly for me in 2 other Arduino webservers I have running. I wanted to note this because if I had written the functions myself, then obviously they would require much more scrutiny.

body:
This is speculation as it may be nearly impossible for any given person to simulate your network (for example, not only the version of Windows you are running but all the drivers installed and hardware specific to your Ethernet interface ... to only mention a few variables).

Consider using a [network monitor][1] to capture all communications set out by the Windows computer.  Consider the Windows computer occasionally failing your network.  Consider the delay you experience may be the time it takes for Windows to recover from what it thinks is a bad network.

The observation is that Windows sends out many autonomous messages over a new network in a "discovery" mode.  The suspicion is that the lack of response to some or all of these messages will result in Windows failing a network.

Windows does have ways of reporting the status of networks that vary with the version of Windows. But these methods (menus) can be frustrating to use as they don't appear to update often enough to reflect the true behavior of traffic coming out of the Windows computer.

Regardless, test if the state of the network is always good.  Also, test if connecting equipment Windows might expect on a functioning network (for example, a router with a DHCP server) improves the response time.  This, as an effort / test to determine if Windows is more responsive while connected to a healthy / active network.

  [1]: https://en.wikipedia.org/wiki/Wireshark


message:
Teensy MIDI Show Control

I'd like to use my Teensy 3.1 to send MIDI Show Control messages using USB MIDI in order to control an ETC Nomad system. These are different from standard NoteOn, NoteOff, ProgramChange, etc. commands, but as far as I can tell they are not supported by the standard library.

Is there any way I can send these messages directly (using lower level commands), as seen [here][1], or does anyone know of a library that supports this? Google has, unusually, not been much help.

  [1]: http://www.mymidiremotes.com/home/?page_id=46

body:
According to the [documentation](https://www.pjrc.com/teensy/td_midi.html), SysEx messages are sent like any other messages:

<!-- language: lang-c -->

    array[0] = 0xf0;
    array[1] = 0x7f;
    array[2] = 0x7f;
    array[3] = 0x02;
    array[4] = 0x7f;
    array[5] = 0x01;
    array[6] = 0xf7;
    usbMIDI.sendSysEx(7, array);


message:
Using a class instance with Wire.onReceive

Is it possible to register a class instance member function with Arduino's [Wire.OnReceive][1]?

I'm trying to make my code object-oriented, and want a specific non-static class function to handle I2C data, but if I'm reading [this thread][2] correctly, `onReceive` is incompatible with classes since it only accepts a function pointer, which won't store context.

  [1]: https://www.arduino.cc/en/Reference/WireOnReceive
  [2]: http://forum.arduino.cc/index.php?topic=116685.0

body:
A non-static class member function has an implicit `ClassName *this` parameter inserted as the first parameter in the parameter list.

Because the function prototype required for `Wire.onReceive()` does not have that parameter specified in its parameter list a non-static member function is not compatible with it.

The same goes for `attachInterrupt()` and anything else that takes a function pointer.


message:
Making Servo Motor Automatically Move Based on Input

sorry if I sound incompetent, but I know nothing about coding. I have a group project where I must sort various balls into different tracks. The final issue I have is that I must use an arduino for this portion. However, none of us know how to program, and the only experience we have is from doing the lessons from adafruit (copy and paste written code).

What I am attempting to do is attach a paddle to the tip of a high torque servo motor. I will then automatically feed the servo signals, ranging from 0 to 5. Each signal tells which position for the servo to turn to. Could anyone please help guide me in how to write this code? I was thinking of using
[this][1] guide for my motor. However it uses a POT. My project must be completely automated. The positons also are all within 180*.

Thank you!

  [1]: https://learn.adafruit.com/adafruit-arduino-lesson-14-servo-motors/overview

body:
So you have a "number" and you want to set the servo to some angle. The logic is very simple:

* If number is 0 then set angle to 90
* If number is 1 then set angle to 45

etc.

How you "get" the number hasn't been specified, so I will assume you just have an integer with a value between 0 and 5 inclusive.

Setting a servo's angle is as simple as *writing* that angle to the servo:

    servo.write(45); // Set the angle to 45 degrees

So how do you join the two together?  Well, there's three different ways that spring to mind.

1. A string of `if` statements
2. A [switch](http://hacking.majenko.co.uk/time-to-make-a-switch) construct
3. An array

The first one is just like the bullet points above, just written as C:

    if (number == 0) servo.write(90);
    if (number == 1) servo.write(45);
    ... etc ...

The second method is very similar but can be more efficient when you know you only ever select one item from a list of options.  Read this to see how: http://hacking.majenko.co.uk/time-to-make-a-switch

The third option, the array, is especially good when you have a lot of options to manage and they are all the same result with a different value:

    const int angles[6] = {90, 45, 315, 0, 0, 0};

    // ... later ...
    servo.write(angles[number]);


message:
Communication between two Bluetooth modules of two Arduinos

I am designing a home automation project. I want to control different home appliances through GSM. I am designing it in such a way that each apparatus is connected to an Arduino and bluetooth module. There is a master unit with Arduino, Bluetooth and GSM modules. When the user sends a message, the GSM receives it and communicates via Bluetooth to the corresponding Bluetooth module and Arduino.

Is it possible to communicate between two Bluetooth modules of two Arduinos? Is there a better solution?

body: I'm not sure how many bluetooth devices can be connected to your smartphone. But if you use smartphone, the you can eliminate the master Arduino. But as I said, it still depends on the number of devices you'd like to control. This is supposed to go in the comment section.


body:
How about little smart WiFi boards (such as [Red Bear WiFi Micro] or something similar), which are connected at your local home network? You can configure your own dyndns service or use a existing and built a web home appliances or web service for your own mobile application. In general please take care of security aspects, so that your home can not be manipulated...
[Red Bear WiFi Micro]:http://redbear.cc/wifi-micro/


body:
You connect your different sensors or devices to many slave arduinos and each slave arduino has its own bluwtooth module that send the data to Master Arduino that contains the Bluetooth and GSM Module.

And yes you can connect max 7 bluetooth devices to 1 Bluetooth module at a time so in that manner you can connect 7 slave devices to Master Arduino


message:
multiple connection with ISP Pin at Arduino Micro

Actually I'm not good at English ;-) trying to ask to you. please understand me :)

I needed connect SD card Shield and TFT LCD Screen to Arduino Micro.

successfully finished compile at source code but when i connect MISO together

it doesn't work. only SS pin is connected separate Pin's to Micro

How can i make it work together to Micro..

i've checked each device perfectly work at Micro

Plese Help me!!

Regards and Thanks

body:
Each SPI device must have a separate device/slave select pin. The device must disconnect (high impedance state) when not selected. The SD shield will have a level shifter. It may not correctly disconnect from MISO.

Depending on what libraries you are using you might also need to check that they set the SPI hardware attributes correctly (clock, mode, etc).

For more help please post code and references to the shields and libraries.

Cheers!


message:
How to correctly pack an unsigned long from 3 unsigned chars?

I would like to use 652 unsigned long values on an Arduino Uno, but it doesn't look like there's enough memory. I thought about the splitting unsigned long values to 3 unsigned chars to store in PROGMEM which I can letter recall and join as unsigned long as needed.

I'm not super experienced with byte manipulations and I got myself stuck when trying to merge the data. When I try with one variable at a time, I get the expected output. The part I'm confused about is why do I get different values when using a variable as an array index for each value ? How can I fix this ?

Here's my test code so far:

    #include <avr/pgmspace.h>
    #include "flashData.h"

    void setup() {
      Serial.begin(115200);
      unsigned long fromPROGMEM = (onsets1[0] << 16) | (onsets2[0] << 8) | onsets3[0];
      Serial.println(fromPROGMEM);

      unsigned long fromValues = (0x00 << 16) | (0x01 << 8) | 0xF3;
      Serial.println(fromValues);

      byte b1 = 0x00;
      byte b2 = 0x01;
      byte b3 = 0xF3;

      unsigned long fromBytes = (b1 << 16) | (b2 << 8) | b3;

      Serial.println(fromBytes);
      delay(2000);

      unsigned char c1,c2,c3;
      unsigned long value;

      Serial.println("data using same index:");
      for(int i = 0 ; i < 10; i++){
        c1 = onsets1[3];
        c2 = onsets2[3];
        c3 = onsets3[3];
        value = (c1 << 16) | (c2 << 8) | c3;
        Serial.print("index: ");
        Serial.print(i);
        Serial.print("\tvalue:");
        Serial.println (value);
        delay(10);
      }

      Serial.println("data using counter:");
      for(int i = 0 ; i < 10; i++){
        c1 = onsets1[i];
        c2 = onsets2[i];
        c3 = onsets3[i];
        value = (c1 << 16) | (c2 << 8) | c3;
        Serial.print("index: ");
        Serial.print(i);
        Serial.print("\tvalue:");
        Serial.println (value);
        delay(10);
      }
    }

    void loop() {

    }

and flashData.h:

    #ifndef _flashData_h_
    #define _flashData_h_

    static PROGMEM const unsigned char onsets1[652] = {0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x01,0x01,0x01,0x01,0x01,0x01,0x01,0x01,0x01,0x01,0x01,0x01,0x01,0x01,0x01,0x01,0x01,0x01,0x01,0x01,0x01,0x01,0x01,0x01,0x01,0x01,0x01,0x01,0x01,0x01,0x01,0x01,0x01,0x01,0x01,0x01,0x01,0x01,0x01,0x01,0x01,0x01,0x01,0x01,0x01,0x01,0x01,0x01,0x01,0x01,0x01,0x01,0x01,0x01,0x01,0x01,0x01,0x01,0x01,0x01,0x01,0x01,0x01,0x01,0x01,0x01,0x01,0x01,0x01,0x01,0x01,0x01,0x01,0x01,0x01,0x01,0x01,0x01,0x01,0x01,0x01,0x01,0x01,0x01,0x01,0x01,0x01,0x01,0x01,0x01,0x01,0x01,0x01,0x01,0x01,0x01,0x01,0x01,0x01,0x01,0x01,0x01,0x01,0x01,0x01,0x01,0x01,0x01,0x01,0x01,0x01,0x01,0x01,0x01,0x01,0x01,0x01,0x01,0x01,0x01,0x01,0x01,0x01,0x01,0x01,0x01,0x01,0x01,0x01,0x01,0x01,0x01,0x01,0x01,0x01,0x01,0x01,0x01,0x01,0x01,0x01,0x01,0x01,0x01,0x01,0x01,0x01,0x01,0x01,0x01,0x01,0x01,0x01,0x01,0x01,0x01,0x01,0x01,0x01,0x01,0x01,0x01,0x01,0x01,0x01,0x01,0x01,0x01,0x01,0x01,0x01,0x02,0x02,0x02,0x02,0x02,0x02,0x02,0x02,0x02,0x02,0x02,0x02,0x02,0x02,0x02,0x02,0x02,0x02,0x02,0x02,0x02,0x02,0x02,0x02,0x02,0x02,0x02,0x02,0x02,0x02,0x02,0x02,0x02,0x02,0x02,0x02,0x02,0x02,0x02,0x02,0x02,0x02,0x02,0x02,0x02,0x02,0x02,0x02,0x02,0x02,0x02,0x02,0x02,0x02,0x02,0x02,0x02,0x02,0x02,0x02,0x02,0x02,0x02,0x02,0x02,0x02,0x02,0x02,0x02,0x02,0x02,0x02,0x02,0x02,0x02,0x02,0x02,0x02,0x02,0x02,0x02,0x02,0x02,0x02,0x02,0x02,0x02,0x02,0x02,0x02,0x02,0x02,0x02,0x02,0x02,0x02,0x02,0x02,0x02,0x02,0x02,0x02,0x02,0x02,0x02,0x02,0x02,0x02,0x02,0x02,0x02,0x02,0x02,0x02,0x02,0x02,0x02,0x02,0x02,0x02,0x02,0x02,0x02,0x02,0x02,0x02,0x02,0x02,0x02,0x02,0x02,0x02,0x02,0x02,0x02,0x02,0x02,0x02,0x02,0x02,0x02,0x02,0x02,0x02,0x02,0x02,0x02,0x02,0x02,0x02,0x02,0x02,0x02,0x02,0x02,0x02,0x02,0x02,0x02,0x02,0x02,0x02,0x02,0x02,0x02,0x02,0x02,0x02,0x02,0x02,0x02,0x02,0x02,0x02,0x02,0x02,0x02,0x02,0x03,0x03,0x03,0x03,0x03,0x03,0x03,0x03,0x03,0x03,0x03,0x03,0x03,0x03,0x03,0x03,0x03,0x03,0x03,0x03,0x03,0x03,0x03,0x03,0x03,0x03,0x03,0x03,0x03,0x03,0x03,0x03,0x03,0x03,0x03,0x03,0x03,0x03,0x03,0x03,0x03,0x03,0x03,0x03,0x03,0x03,0x03,0x03,0x03,0x03,0x03,0x03,0x03,0x03,0x03,0x03,0x03,0x03,0x03,0x03,0x03,0x03,0x03,0x03,0x03,0x03,0x03,0x03,0x03,0x03,0x03,0x03,0x03,0x03,0x03,0x03,0x03,0x03,0x03,0x03,0x03,0x03,0x03,0x03,0x03,0x03,0x03,0x03,0x03,0x03,0x03,0x03,0x03,0x03,0x03,0x03,0x03,0x03,0x03,0x03,0x03,0x03,0x03,0x03,0x03,0x03,0x03,0x03,0x03,0x03,0x03,0x03,0x03,0x03,0x03};
    static PROGMEM const unsigned char onsets2[652] = {0x01,0x04,0x05,0x06,0x07,0x08,0x09,0x0A,0x0D,0x0E,0x0F,0x10,0x11,0x12,0x14,0x15,0x16,0x17,0x18,0x19,0x1A,0x1B,0x1D,0x1E,0x1F,0x20,0x21,0x22,0x23,0x25,0x26,0x28,0x29,0x2A,0x2B,0x2C,0x2E,0x2F,0x30,0x31,0x32,0x33,0x34,0x35,0x38,0x39,0x3A,0x3B,0x3C,0x3F,0x40,0x41,0x42,0x43,0x44,0x45,0x46,0x48,0x49,0x4A,0x4C,0x4D,0x4E,0x51,0x52,0x53,0x54,0x55,0x56,0x57,0x59,0x5A,0x5B,0x5C,0x5E,0x5F,0x61,0x63,0x64,0x65,0x67,0x6A,0x6B,0x6C,0x6D,0x6E,0x70,0x71,0x73,0x75,0x76,0x77,0x79,0x7C,0x7E,0x7F,0x80,0x82,0x84,0x85,0x86,0x87,0x88,0x89,0x8A,0x8C,0x8D,0x8E,0x8F,0x90,0x91,0x92,0x95,0x96,0x97,0x98,0x99,0x9A,0x9B,0x9C,0x9E,0x9F,0xA0,0xA1,0xA2,0xA3,0xA4,0xA7,0xA8,0xA9,0xAA,0xAB,0xAC,0xAD,0xAF,0xB0,0xB1,0xB2,0xB3,0xB4,0xB5,0xB6,0xB9,0xBA,0xBB,0xBC,0xBD,0xBE,0xC0,0xC2,0xC4,0xC6,0xC9,0xCB,0xCD,0xCF,0xD2,0xD4,0xD6,0xD8,0xDA,0xDB,0xDD,0xDF,0xE0,0xE2,0xE4,0xE6,0xE7,0xE8,0xE9,0xEB,0xEC,0xED,0xEE,0xEF,0xF0,0xF1,0xF2,0xF4,0xF6,0xF7,0xF8,0xF9,0xFA,0xFD,0xFE,0xFF,0x00,0x01,0x02,0x03,0x06,0x07,0x08,0x0A,0x0D,0x0F,0x10,0x11,0x12,0x13,0x14,0x16,0x18,0x19,0x1A,0x1C,0x1D,0x1F,0x21,0x22,0x23,0x25,0x28,0x2A,0x2B,0x2C,0x2E,0x30,0x31,0x33,0x34,0x35,0x38,0x3C,0x3D,0x3E,0x41,0x42,0x44,0x45,0x46,0x47,0x48,0x4A,0x4B,0x4C,0x4D,0x4E,0x4F,0x50,0x53,0x54,0x56,0x57,0x58,0x59,0x5B,0x5C,0x5D,0x5E,0x5F,0x60,0x61,0x63,0x65,0x66,0x67,0x69,0x6A,0x6D,0x6E,0x6F,0x70,0x71,0x72,0x73,0x75,0x77,0x78,0x79,0x7A,0x7B,0x7D,0x7E,0x7F,0x80,0x82,0x84,0x87,0x89,0x8B,0x8E,0x90,0x92,0x94,0x97,0x99,0x9B,0x9D,0xA0,0xA2,0xA4,0xA5,0xA6,0xA8,0xA9,0xAA,0xAB,0xAC,0xAD,0xAE,0xAF,0xB1,0xB2,0xB3,0xB4,0xB5,0xB6,0xB9,0xBA,0xBB,0xBD,0xBF,0xC0,0xC2,0xC4,0xC6,0xC7,0xC8,0xCB,0xCC,0xCD,0xCE,0xCF,0xD1,0xD4,0xD5,0xD6,0xD7,0xD8,0xD9,0xDA,0xDC,0xDD,0xDE,0xDF,0xE0,0xE1,0xE2,0xE4,0xE6,0xE8,0xEA,0xEB,0xED,0xEF,0xF1,0xF2,0xF3,0xF5,0xF6,0xF8,0xF9,0xFA,0xFB,0xFC,0xFF,0x01,0x03,0x04,0x05,0x07,0x08,0x09,0x0A,0x0B,0x0C,0x0D,0x0F,0x10,0x11,0x12,0x13,0x15,0x16,0x18,0x19,0x1A,0x1B,0x1C,0x1D,0x1E,0x20,0x21,0x23,0x24,0x25,0x27,0x29,0x2A,0x2B,0x2C,0x2D,0x2E,0x30,0x32,0x33,0x35,0x36,0x37,0x3A,0x3B,0x3C,0x3E,0x40,0x43,0x44,0x45,0x47,0x48,0x49,0x4A,0x4C,0x4D,0x4E,0x50,0x55,0x56,0x57,0x59,0x5A,0x5B,0x5E,0x5F,0x60,0x61,0x62,0x63,0x65,0x66,0x67,0x68,0x69,0x6B,0x6C,0x6F,0x70,0x71,0x72,0x73,0x74,0x76,0x77,0x79,0x7A,0x7B,0x7D,0x7F,0x80,0x81,0x82,0x83,0x84,0x85,0x86,0x88,0x89,0x8A,0x8B,0x8C,0x8D,0x90,0x91,0x92,0x93,0x94,0x95,0x96,0x97,0x99,0x9B,0x9D,0x9F,0xA2,0xA4,0xA6,0xA8,0xAB,0xAD,0xAF,0xB1,0xB4,0xB6,0xB7,0xB8,0xBB,0xBD,0xBE,0xBF,0xC0,0xC1,0xC2,0xC4,0xC5,0xC6,0xC7,0xC8,0xC9,0xCA,0xCC,0xCD,0xCE,0xCF,0xD1,0xD3,0xD6,0xD8,0xDA,0xDC,0xDE,0xDF,0xE0,0xE1,0xE3,0xE4,0xE5,0xE7,0xE8,0xE9,0xEA,0xEC,0xEF,0xF0,0xF1,0xF2,0xF3,0xF4,0xF5,0xF7,0xF8,0xF9,0xFA,0xFB,0xFC,0xFE,0x01,0x03,0x04,0x05,0x07,0x09,0x0A,0x0B,0x0C,0x0E,0x10,0x12,0x13,0x14,0x15,0x17,0x18,0x1A,0x1C,0x1E,0x1F,0x20,0x21,0x23,0x24,0x25,0x26,0x27,0x28,0x29,0x2B,0x2C,0x2D,0x2E,0x2F,0x30,0x31,0x32,0x34,0x35,0x37,0x39,0x3C,0x3E,0x40,0x42,0x43,0x45,0x47,0x49,0x4A,0x4B,0x4C,0x4E,0x50,0x52,0x53,0x54,0x56,0x57,0x58,0x59,0x5B,0x5C,0x5D,0x5F,0x60,0x61,0x62,0x64,0x66,0x68,0x69,0x6B,0x6C,0x6D,0x6E,0x70,0x71,0x72,0x74,0x75,0x76,0x78,0x79,0x7B,0x7C,0x7D,0x7F,0x80,0x81,0x82,0x83,0x84,0x85,0x86,0x87,0x88,0x8A,0x8B,0x8C,0x8D,0x8F,0x90,0x91,0x93,0x94,0x95,0x96,0x97,0x98,0x9B,0x9D,0x9F,0xA1};
    static PROGMEM const unsigned char onsets3[652] = {0xF3,0x31,0x59,0x76,0x98,0xBA,0xDD,0xFF,0x43,0x66,0x88,0xAA,0xC7,0xEF,0x0B,0x2D,0x50,0x72,0x8E,0xB1,0xD3,0xF5,0x17,0x3A,0x5C,0x7E,0xA0,0xC8,0xE5,0x0D,0x29,0x6E,0x90,0xAC,0xD5,0xF7,0x13,0x35,0x58,0x7A,0x9C,0xB9,0xE1,0xFD,0x42,0x6A,0x86,0xA8,0xC5,0x0F,0x31,0x54,0x7C,0x92,0xB5,0xCB,0xF9,0x1B,0x43,0x60,0xA4,0xC1,0xE3,0x28,0x4A,0x72,0x8E,0xB1,0xD3,0xF5,0x17,0x34,0x5C,0x78,0xBD,0xDF,0x01,0x46,0x62,0x84,0xCF,0x0D,0x30,0x52,0x7A,0x91,0xD5,0xF7,0x1A,0x5E,0x86,0xA3,0xE7,0x26,0x5F,0x92,0xAF,0xF3,0x1B,0x32,0x5A,0x7C,0x9F,0xBB,0xE3,0x00,0x28,0x4A,0x66,0x89,0xAB,0xC7,0x0C,0x34,0x4A,0x72,0x95,0xB7,0xD9,0xFB,0x1E,0x3A,0x62,0x7F,0x9B,0xC3,0xE0,0x2A,0x52,0x69,0x91,0xB3,0xD5,0xF7,0x1F,0x36,0x58,0x80,0x9D,0xB9,0xE1,0xF8,0x42,0x65,0x81,0xA9,0xCB,0xE8,0x10,0x54,0x93,0xD2,0x16,0x60,0x9F,0xE4,0x28,0x6D,0xAB,0xF0,0x12,0x34,0x79,0xB2,0xDA,0x02,0x46,0x85,0xAD,0xCF,0xF2,0x0E,0x30,0x4D,0x75,0x97,0xB9,0xD0,0xFE,0x1A,0x65,0x87,0xA3,0xC5,0xE2,0x2C,0x4E,0x6B,0x8D,0xAF,0xD7,0xEE,0x38,0x5B,0x77,0xC1,0x00,0x45,0x67,0x89,0xAB,0xCE,0xF0,0x01,0x57,0x7F,0x95,0xDA,0xFC,0x1E,0x5D,0x7F,0x9C,0xE0,0x25,0x6F,0x91,0xAE,0xF2,0x14,0x3C,0x7B,0x98,0xBA,0x04,0x82,0xAF,0xCC,0x16,0x33,0x77,0x94,0xBC,0xD2,0xFA,0x1D,0x3F,0x61,0x7D,0xA6,0xC8,0xE4,0x29,0x51,0x8F,0xAC,0xCE,0xF0,0x13,0x35,0x57,0x79,0x9C,0xBE,0xE0,0x02,0x47,0x69,0x8B,0xCA,0xF2,0x31,0x53,0x75,0x98,0xBA,0xD6,0xF9,0x15,0x5F,0x82,0xA4,0xC6,0xE8,0x05,0x33,0x60,0x7D,0xBC,0xFA,0x3F,0x83,0xC2,0x0C,0x51,0x95,0xD4,0x18,0x5D,0xA1,0xE0,0x25,0x69,0xA8,0xD0,0xE7,0x0F,0x31,0x53,0x75,0x98,0xB4,0xDC,0xF9,0x1B,0x3D,0x5F,0x7C,0xA4,0xC0,0x05,0x21,0x49,0x88,0xD2,0xF4,0x11,0x55,0x94,0xBC,0xDE,0x1D,0x4B,0x62,0x8F,0xAC,0xF0,0x2F,0x57,0x74,0x96,0xB2,0xD5,0xF7,0x1F,0x3B,0x63,0x86,0xAE,0xC4,0xEC,0x09,0x47,0x8C,0xD0,0xF3,0x15,0x54,0x98,0xC0,0xE2,0x05,0x21,0x66,0x88,0xA4,0xD2,0xEF,0x39,0x72,0xBC,0xD9,0xFB,0x23,0x3F,0x62,0x84,0xA0,0xC3,0xF0,0x07,0x2F,0x4C,0x74,0x90,0xCF,0xF7,0x13,0x3B,0x58,0x74,0x9C,0xB9,0xDB,0x03,0x1F,0x6A,0x86,0xA3,0xED,0x0F,0x31,0x4E,0x76,0x92,0xB5,0xF9,0x27,0x38,0x7C,0xA4,0xC1,0x05,0x28,0x4A,0x8E,0xCD,0x11,0x3A,0x50,0x9B,0xBD,0xDF,0x93,0x24,0x40,0x68,0xA7,0x2A,0x58,0x74,0xB9,0xDB,0xF7,0x3C,0x5E,0x80,0xA3,0xC5,0xE7,0x09,0x2C,0x48,0x70,0x8D,0xD1,0xF9,0x38,0x54,0x77,0x9F,0xBB,0xDD,0x00,0x22,0x60,0x83,0x9F,0xE9,0x11,0x2E,0x50,0x72,0x95,0xB7,0xDF,0xFB,0x18,0x40,0x5C,0x7F,0xA1,0xB8,0x08,0x2A,0x46,0x6E,0x8B,0xAD,0xD5,0xFD,0x14,0x58,0x97,0xDC,0x20,0x59,0xA9,0xEE,0x32,0x71,0xB5,0xF4,0x38,0x77,0x99,0xC1,0x06,0x4A,0x6D,0x8F,0xAB,0xCE,0xF0,0x0C,0x34,0x57,0x79,0x95,0xBD,0xDA,0x02,0x1E,0x46,0x5D,0xA7,0xE6,0x25,0x6F,0xAE,0xF2,0x14,0x37,0x5F,0x7B,0xC0,0xE8,0xFE,0x21,0x43,0x6B,0x8D,0xC6,0x10,0x33,0x55,0x77,0x99,0xBC,0xD8,0x00,0x1D,0x45,0x5B,0x83,0xA0,0xE4,0x29,0x67,0x8F,0xAC,0xF0,0x18,0x35,0x63,0x79,0xB8,0xFD,0xC1,0x4D,0x6F,0x86,0xCA,0xF2,0x09,0x4D,0x92,0xBA,0xD6,0xF9,0x15,0x37,0x59,0x82,0xA4,0xBA,0xE8,0x05,0x27,0x49,0x6B,0x8E,0xAA,0xCC,0xEF,0x17,0x33,0x78,0xB6,0x01,0x3F,0x7E,0xC3,0xEB,0x07,0x4C,0x90,0xB2,0xD5,0xFD,0x19,0x5E,0xA2,0xBE,0xE1,0x03,0x25,0x47,0x64,0xAE,0xD6,0xED,0x15,0x31,0x59,0x76,0xB5,0xF9,0x1B,0x3E,0x7C,0xA4,0xC7,0xE9,0x0B,0x33,0x50,0x8E,0xB6,0xD9,0x01,0x11,0x56,0x7E,0x95,0xDF,0x9F,0x13,0x29,0x46,0x68,0x8A,0xAC,0xC9,0xEB,0x0D,0x2A,0x52,0x6E,0xAD,0xCF,0xF7,0x25,0x30,0x64,0x7B,0xA3,0xBF,0x09,0x42,0x8D,0xCB};

    #endif

And here's what I see from Serial:

    499
    499
    499
    data using same index:
    index: 0 value:1654
    index: 1 value:1654
    index: 2 value:1654
    index: 3 value:1654
    index: 4 value:1654
    index: 5 value:1654
    index: 6 value:1654
    index: 7 value:1654
    index: 8 value:1654
    index: 9 value:1654
    data using counter:
    index: 0 value:4294945024
    index: 1 value:4294962688
    index: 2 value:12806
    index: 3 value:28928
    index: 4 value:4294948096
    index: 5 value:4294964224
    index: 6 value:14337
    index: 7 value:30464
    index: 8 value:4294940928
    index: 9 value:4294951174

I see what I expect for first 3 values and also for data using same index, but no when using a variable as an index for the PROGMEM arrays.

What is going on and how can I fix this ?

**Update**
Mikael's answer is the solution, but I will post a working snippet here for reference:

    #include <avr/pgmspace.h>
    #include "flashData.h"

    void setup() {
      Serial.begin(115200);
      delay(2000);

      unsigned char c1,c2,c3;
      unsigned long value;

      Serial.println("data using counter:");
      for(int i = 0 ; i < 652; i++){
        c1 = (unsigned char) pgm_read_byte(&onsets1[i]);
        c2 = (unsigned char) pgm_read_byte(&onsets2[i]);
        c3 = (unsigned char) pgm_read_byte(&onsets3[i]);
        value = (((unsigned long) c1) << 16) | ((unsigned long)c2 << 8) | (unsigned long)c3;
        Serial.print("index: ");
        Serial.print(i);
        Serial.print("\tvalue:");
        Serial.println (value);
        delay(10);
      }

    }

    void loop() {

    }
The key is not only explicitly casting the data read, but also correctly reading the the PROGMEM data.

body:
You can try (explict unsigned long values):

    unsigned long fromValues = (0x00UL << 16) | (0x01 << 8) | 0xF3;
    Serial.println(fromValues);

or:

    value = (((unsigned long) c1) << 16) | (c2 << 8) | c3;

The issue is that the expression is implicit int and not long (as you are assuming). You need to tell the compiler about this.

An extra bonus comment: There is actually a 24 bit integer definition in AVR GCC according to the [wiki, see Extensions, Types][1].

Cheers!

  [1]: https://gcc.gnu.org/wiki/avr-gcc


body:
I got it to work by typecasting firmly and using multiplications:

      Serial.println("data using counter:");
      for (int i = 0 ; i < 10; i++) {
        c1 = onsets1[i];
        c2 = onsets2[i];
        c3 = onsets3[i];
        value = (uint8_t)c3 + (uint16_t)((uint8_t)c2*256)+(uint32_t)(c1*65536);
        Serial.print("index: ");
        Serial.print(i);
        Serial.print("\t");
        Serial.print(c1, HEX);
        Serial.print(", ");
        Serial.print(c2, HEX);
        Serial.print(", ");
        Serial.print(c3, HEX);
        Serial.print(" ");
        Serial.print("\tvalue:");
        Serial.println (value, HEX);
      }

The result:

>     data using counter:
    index: 0 A1, F6, 0  value:A1F600
    index: 1 FC, A7, 0  value:FCA700
    index: 2 B5, 7A, B8  value:B57AB8
    index: 3 EF, DB, 0  value:EFDB00
    index: 4 14, F9, 0  value:14F900
    index: 5 D7, 7F, 0  value:D77F00
    index: 6 F2, 72, 1  value:F27201
    index: 7 6F, DB, 0  value:6FDB00
    index: 8 5E, 5E, 0  value:5E5E00
    index: 9 F0, E7, B8  value:F0E7B8


message:
Controlling 2 relays with IR remote, push button and bluetooth - sort of works, need help!

I'm still very new to arduino and coding and having some difficulties trying to figure out what I am doing wrong here.

This program is to have control over 2 relays, using a combination of an      IR receiver and a ir_remotecontrol with pre-programmed buttons (ir_remote buttons 1 = relay 1 toggle, button 2 = relay 2 toggle).
A master momentary hard wired switch to override changes to the relays and toggle their states i.e if both relays are on via ir remote - toggle them off, or if only 1 relay is on toggle it off with
first click of button then toggle both back on after second click of button.
The Bluetooth module and android app is to also control relays the same as the ir_remote via integers sent through the serial port.

It all sort of works at the moment...

If I just work the relays using the ir remote and the momentary switch it all works perfectly.

if I make sure the relays are in the off position using the remote switch and then use the Bluetooth it also works perfectly.

The problem only is when I use a combination of the ir remote or switch and the Bluetooth - things get weird - the Bluetooth commands seem to reverse and the relays start making a buzzing noise and the momentary switch muddles things up so basically it's all bad news! I've stared at this code for hours and tried a few different things but I just can't see what's wrong.

Let me know if I need to give a more detailed example of the errors I am having. Just thinking it is probably obvious for you pro's out there when you see my noob code!.

Any help would be greatly appreciated!

    /*This program is to have control over 2 relays, using a cobination of   an IR reciever and remote control with pre programmed buttons    (ir_remote buttons 1 = relay 1 toggle, 2 = relay 2 toggle).
    A master momentery hard wired switch to overide changes to the relays and toggle their states i.e if both relays are on via ir remote - toggle them off, or if 1 only relay is on toggle it off with first click of button then toggle both back on after sencond click of button.
    Bluetooth module and andoid app to also control relays the same as the ir_remote.
     */
    //include libaries, and initialise variables
    #include <SoftwareSerial.h>
    #include <IRremote.h>
    #define irPin 8
    #define RxD 7
    #define TxD 6
    #define relay1 13
    #define relay2 12
    #define buttonPin 2
    SoftwareSerial blueTooth(RxD, TxD);
    IRrecv irrecv(irPin);
    decode_results results;
    int comdata;
    const int wait = 30;
    int sensorValue = 0;
    int sensorOut = 0;
    int relay1State = 0;
    int relay2State = 0;
    int masterState = 0;
    int buttonState = 0;
    int lastButtonState = 0;
    long lastDebounceTime = 0;
    long debounceDelay = 50;

    void setup()
    {
      blueTooth.begin(38400);                     //set bluetooth baud rate
      delay(500);
      irrecv.enableIRIn();                        //enable infrared recieve
      pinMode(relay1, OUTPUT);                    //setting relays 1 & 2 to output
      pinMode(relay2, OUTPUT);
      pinMode(buttonPin, INPUT);                  //setting momentery swith (overide) to inpt
      digitalWrite(relay1, relay1State);          //putting current status of relays into a variable
      digitalWrite(relay2, relay2State);

    }

    void loop()
    {
      if (blueTooth.available())                  //setting a variable for bluetooth recieved serial commands
      comdata = blueTooth.read();

      if(comdata == '1'){

      digitalWrite(relay1, relay1State);          //if bluetooth receivs "1" toggle relay1state -- essentially relay 1 ON
      }
      if(comdata == '0'){
      digitalWrite(relay1, !relay1State);         //if bluetooth receivs "0" toggle relay1state -- essentially relay 1 OFF

      }
      if(comdata == '2'){
      digitalWrite(relay2, relay2State);          //if bluetooth receivs "2" toggle relay2state -- essentially relay 2 ON

      }
      if(comdata == '3'){
      digitalWrite(relay2, !relay2State);         //if bluetooth receivs "3" toggle relay2state -- essentially relay 2 OFF
      }

      if (irrecv.decode(&results)){                     //Start listing for ir commands, if set remote button code is recvived toggle the variable relay1State or relay2state
      switch (results.value){
          case 0xFF30CF:
            relay1State = !relay1State;
            digitalWrite(relay1, relay1State);
            delay(250);
            break;
          case 0xFF18E7:
            relay2State = !relay2State;
            digitalWrite(relay2, relay2State);
            delay(250);
            break;
        }
        irrecv.resume();
        }

      int reading = digitalRead(buttonPin);          //debounce used to help with faulse readings from momentery switch
      if (reading != lastButtonState) {
       lastDebounceTime = millis();
      }
      if ((millis() - lastDebounceTime) > debounceDelay) {

      if (reading != buttonState) {
          buttonState = reading;

      if (buttonState == HIGH) {                      //if the momentery switch is pressed toggle masterstate which is both relay 1 and relay 2 state
         masterState = !masterState;
         relay1State = masterState;
         relay2State = masterState;
          }
          }
        }

      digitalWrite(relay1, relay1State);
      digitalWrite(relay2, relay2State);
      lastButtonState = reading;

    }

body:
Only the button changes `relay1State` and `relay2State`. The IR and BT only change the pin using digitalWrite. But then in the last 3 lines, the pin is changed back to the value of `relay1State` and `relay2State`.

I think for the IR and BT you need to change e.g. `digitalWrite(relay2, !relay2State);` to `relay2State=false;` etc.

PS It there a pull-up/pull-down resistor on the button pin?


body:
Looks like it could be reusing the old comdata values in the first part of loop().  Maybe make the first chunk:

       if (blueTooth.available()) {
          comdata = blueTooth.read();
          switch (comdata) {  // set state variables based on bluetooth
          case  '0':  // if bluetooth receivs "0" clear 1
              relay1State = 0;
              break;
          case  '1':  // if bluetooth receivs "1" set 1
              relay1State = 1;
              break;
          case  '2':  // if bluetooth receivs "2" set 2
              relay2State = 1;
              break;
          case  '3':  // if bluetooth receivs "1" clear2
              relay2State = 0;
              break;

          case  '4':  // if bluetooth receivs "4" toggle 1
              relay1State = !relay1State;
              break;
          case  '5':  // if bluetooth receivs "5" toggle 2
              relay2State = !relay2State;
              break;
          case  '6':  // if bluetooth receivs "6" toggle master/both
              masterState = relay1State = relay2State = !masterState;
              break;
          }  // end of switch
          // apply state variables to outputs
          // (could be left to the end of the loop() code)
          digitalWrite(relay1, relay1State);
          digitalWrite(relay2, relay2State);
       } // end of bluetooth processing

       ... /// IR processing code

       // debounce button and toggle masterstate & set state vars accordingly
       // see http://arduino.stackexchange.com/questions/17443/how-to-simulate-delay-to-debounce-mechanical-button-using-millis
       //

    // re-ensure output state matches the state variables.
    digitalWrite(relay1, relay1State);
    digitalWrite(relay2, relay2State);
    }

As it is, the if() statements trigger on the state of the last read comdata, not on the whether a new command was read.

Also, maybe check whether the toggling comments match the code or the code matches the intention properly.


message:
Arduino Variable Data Type?

Is there a variable data type available for Arduino? I have a class that should have a member that will differ in data type, in the past I have used the "variable" keyword in c++ but when I tried to use it the compiler yelled at me. I searched online and found a couple of articles that mentioned that if you are using an alternate GUI (I am using eclipse mars) that you can enable the feature but I can not find the correct settings as the examples I had found were for Juno and below.

Here is an example of what I am trying to accomplish

    class DisplayItem{

       public:
       variant *displayVar;

       void Display(){
          Serial.println(displayVar);
       }
    }

    int intDisplay;
    String strDisplay;

    DisplayItem item();
    item.displayVar = &intDisplay;
    item.Display();
    item.displayVar = &strDisplay;
    item.Display();

I realize I could create a overloaded function to display different data types but it would be allot easier if I could simply assign a reference to a variant datatype and reuse the variable.

----------

**Edit**

So after looking through the answers I think I have this figured out. I needed to keep track of which variable was being set, I put together a quick example in hopes it will help someone else out with the same question.

    class DisplayItem{

       private:
       int iVarType;

       union{
          int *i;
          float *f;
       } displayVar;

       public:
       void SetVar(int *var){
          displayVar.i = var;
          iVarType = 0;
       }

       void SetVar(float *var){
          displayVar.f = var;
          iVarType = 1;
       }

       void Display(){
          if (iVarType == 0){
             Serial.println(displayVar.i);
          }else if (iVarType == 1){
             Serial.println(displayVar.f);
          }
       }
    }

    int intDisplay = 1;
    float floatDisplay = 0.123;

    DisplayItem item();
    item.SetVar(&intDisplay);
    item.Display();
    item.SetVar(&floatDisplay);
    item.Display();

Will Display:

    1
    0.123

body:
No, there is no such thing.  The whole concept of "type" only exists during compilation, not at run-time.

However, you can "emulate" it using "setters" and keeping your own internal state information:

    class Thing {
        private:
            String *strvar;
            int intvar;
            int type;

        public:
            void set(int val) {
                intvar = val;
                type = 1;
            }
            void set(String &str) {
                strval = &str;
                type = 2;
            }
            void Display() {
                if (type == 1) {
                    Serial.print("Value: ");
                    Serial.println(intval);
                } else if (type == 2) {
                    Serial.print("String: ");
                    Serial.println(strval);
                } else {
                    Serial.println("Something went wrong");
                }
            }
    };

    Thing t;
    String s = "This is a string";
    int i = 23;
    t.set(s);
    t.Display();
    t.set(i);
    t.Display();

The multiple functions named the same but with different parameters are *overloaded*. The best match is picked at compile time.


body:
For the situation illustrated in the question – displaying data – polymorphic functions already exist, and might as well be used in this case.  Specifically, use the `Streaming.h` [contributed library](https://www.arduino.cc/en/Reference/Libraries).  It adds some “syntactic sugar” to Arduino C.  At compile time it converts C++-like `<<` Serial stream operators to `Serial.print` statements, without increasing code size.  You can install it via [`Streaming5.zip`](http://arduiniana.org/Streaming/Streaming5.zip) from [arduiniana.org](http://arduiniana.org/libraries/streaming/) .

In other cases, a `union` data structure allows treating an area of memory different ways.  Wikipedia's *[Union type](https://en.wikipedia.org/wiki/Union_type)* article explains the general idea.  See eg [tutorialspoint.com/cprogramming](http://www.tutorialspoint.com/cprogramming/c_unions.htm) for `union` syntax and usage.  For some reason, arduino.cc's [Language Reference](https://www.arduino.cc/en/Reference/HomePage) page hasn't got `union` on its list of language features.  However, mcgurrin.com has a page called *[There is Power in a Union](http://www.mcgurrin.com/robots/?p=127)* that codes a simple Arduino C example two ways (where `bearing` is an `int`):

    higherByte = compass.read();
    lowerByte = compass.read();
    bearing = ((higherByte<<8)+lowerByte)/10

-vs-

    union Data {
      byte b[2];
      int value;
    };
    ...
    union Data data;
    data.b[0] = compass.read();
    data.b[1] = compass.read();
    bearing = data.value/10;


message:
Trouble with Timer 0

I'm taking my first wobbly steps outside the Arduino IDE and I'm not having much success with timers / interrupts. I can set a pin to output and light an LED with registers fine but I cannot for the life of me get it to blink using a timer. I have tried numerous tutorials and followed the Atmel ATmega328 datasheet very closely.

Using an Arduino Uno R3 & Atmel ICE (ISP.) My dev system is Raspbian (Debian) with the GNU AVR toolchain (avr-gcc, avr-objcopy, avrdude.) Apart from not having a bootloader it's a bog standard board (including fuses.)

Here's my current code:

    #include <avr/io.h>
    #include <avr/interrupt.h>

    ISR(TIMER0_COMPA_vect)
    {
     PORTB ^= (1 << PB5); // Toggle Arduino Pin #13
    }

    int main (void)
    {
     DDRB = (1 << DDB5); // Arduino Pin #13 is Output

     cli(); // Clear Interrupts

     OCR0A = (unsigned char)0xFF; // Compare Register A = 255
     TIMSK0 = (1 << OCIE0A); // Enable Interrupt for Comp. Reg. A
     TCCR0A = (1 << WGM01); // CTC Mode

     sei(); // Set Interrupts
     TCCR0B = (1 << CS02) | (1 << CS00); // Divide by 1024 Prescaler (GO!)

     return 0;
    }

I don't know if I'm just not seeing something or if I've set registers in the wrong order but it's driving me crazy.

body: `return 0` resets the device. Use `while(1);` instead, to make it wait indefinitely.


body:
Returning from `main` does not reset the device (it would start up again and do it all over in that case). It calls `exit` which turns interrupts off and loops indefinitely.

    00000068 <__ctors_end>:
      68: 11 24        eor r1, r1
      6a: 1f be        out 0x3f, r1 ; 63
      6c: cf ef        ldi r28, 0xFF ; 255
      6e: d8 e0        ldi r29, 0x08 ; 8
      70: de bf        out 0x3e, r29 ; 62
      72: cd bf        out 0x3d, r28 ; 61
      74: 0e 94 52 00  call 0xa4 ; 0xa4 <main>
      78: 0c 94 61 00  jmp 0xc2 ; 0xc2 <_exit>

    ...

    000000a4 <main>:
      a4: 80 e2        ldi r24, 0x20 ; 32
      a6: 84 b9        out 0x04, r24 ; 4
      a8: f8 94        cli
      aa: 8f ef        ldi r24, 0xFF ; 255
      ac: 87 bd        out 0x27, r24 ; 39
      ae: 82 e0        ldi r24, 0x02 ; 2
      b0: 80 93 6e 00  sts 0x006E, r24
      b4: 84 bd        out 0x24, r24 ; 36
      b6: 78 94        sei
      b8: 85 e0        ldi r24, 0x05 ; 5
      ba: 85 bd        out 0x25, r24 ; 37
      bc: 80 e0        ldi r24, 0x00 ; 0
      be: 90 e0        ldi r25, 0x00 ; 0
      c0: 08 95        ret

    000000c2 <_exit>:
      c2: f8 94        cli

    000000c4 <__stop_program>:
      c4: ff cf        rjmp .-2       ; 0xc4 <__stop_program>

You can see at address 0x74 it calls main, and then jumps to exit. `exit` turns off interrupts.

With interrupts off your ISR will not toggle pin 13.


message:
Issue in installing Arduino unit library and running with Firmata test application

I am trying to update the Arduino library via the library manager and I tried to download it from the link given in the firmata_test program:

> WARNING: Category '' in library ArduinoUnit is not valid. Setting to
> 'Uncategorized'
> C:\Users\SAURAB~1\AppData\Local\Temp\arduino_c8217a5b56c170d64dfe4c80a1a205dc\firmata_test.ino:
> In member function 'virtual void test_beginPrintsVersion::once()':
>
> C:\Users\SAURAB~1\AppData\Local\Temp\arduino_c8217a5b56c170d64dfe4c80a1a205dc\firmata_test.ino:32:3:
> warning: narrowing conversion of '249' from 'int' to 'char' inside { }
> [-Wnarrowing]
>
>    };
>
>    ^
>
> Multiple libraries were found for "Firmata.h"  Used:
> C:\Users\saurabh2836\Documents\Arduino\libraries\Firmata  Not used:
> C:\Program Files (x86)\Arduino\libraries\Firmata

I'm getting this error. I searched but found no conclusive answer. I'm using Windows 8 64bit and Firmata downloaded from http://www.firmata.org/.

Am I doing something wrong?

body:
The compiler is giving a lot of information. The warnings can be ignored but the "multiple libraries" indicates that there is at least two copies of Firmata installed. Check (search) that you have not got several downloads of Firmata. Worst case reinstall to clean up that.

Cheers!


message:
Arduino Mega, ST7920 using COSA

I am trying to learn and understand the [COSA Library][1] using a 12864ZW (ST7920) 128X64 LCD Display. Right now I am able to use the LCD using the u8glib but also found that COSA has a library for the [ST7920 Display][2], I originally used [this tutorial][3] to get things working.

The main problem that I have now is in the [ST7920 Documentation][4] there is a schematic that shows how to hook up a ST7920 Compatible LCD. The first [tutorial][3] only uses 3 lines from the Mega and the Cosa is using what looks like 6 lines.

Looking at the header file, it looks like it is derived from the HD44780 Class and what I can gather is pins 16 and 4 are hard coded for something? I am not quite clear on how to use the Cosa version of the library. Can someone please give me a explanation and perhaps a explanation on how to get this working using Cosa?

  [1]: https://github.com/mikaelpatel/Cosa
  [2]: https://dl.dropboxusercontent.com/u/993383/Cosa/doc/html/dir_6c9b05e5d5923c236f9de149d085166d.html
  [3]: http://overskill.alexshu.com/128x64-12864-lcd-w-arduino-serial/
  [4]: https://github.com/mikaelpatel/Cosa/blob/master/libraries/ST7920/ST7920.hh

body:
The Cosa ST7920 library uses text mode only (16X4). The ST7920 class is controlled though an adapter. There are several adapters available depending on how you wish to connect to the Arduino. They range from parallel 4-bit to SPI with shift register. The adapters implement the interface [HD44780::IO][1]. There are several LCD examples. The [CosaLCDbench][2] shows the possible configurations with LCD and Adapters. Please see the file for further details.

  [1]: https://github.com/mikaelpatel/Cosa/blob/master/libraries/HD44780/HD44780.hh#L44
  [2]: https://github.com/mikaelpatel/Cosa/blob/master/libraries/LCD/CosaLCDbench/CosaLCDbench.ino


message:
Arduino Not Working as Intended when using barrel jack

I am using an Arduino to control some mechanical components in a project I have. It controls a motor, two servos, a valve, and a compressor. When plugged into the computer, everything works fine and perfectly. However, when I power it through the barrel jack using our power supply, some weird things happen. First of all, our servos, which are powered through the Arduino, stop working. All the other components work except for them. Secondly, at the end of the code we have a 5 second delay. Using the computer it works fine. When powered with our supply the delay doesn't seem to happen at all. Any ideas?

body: I believe that the problem that you are facing is lack of power. It is likely that your power source cannot supply enough current or voltage to power the equipment AND the arduino. Try to get a power supply that has more amps.


body:
i agree with majenko, maybe you know how to fix it but if you do not know here is a site with good information to make you're own  5 volt Regulated source.

http://www.rakeshmondal.info/IC-7805-Voltage-Regulator

sorry for my bad english and good luck. :D


body:
I had a similar problem recently while powering a servo with a Arduino.
It did turn out to be power, our Arduino could only supply about 500ma and with sufficient speed or torque on the servo (a lot of times just the boot sequence) we would it the 500ma at peak, the effect however was baffling at first because when we hit the peak current the Arduino would reboot, this could account for you extra delay at the end.

For us the solution was simple bypass the Arduino when supplying current to the servos, in our case it as a 5v battery, you would probably need to drop the 12v to 6v in your case.


message:
Eclipse add library

I am completely lost here, I have no idea what I am doing wrong. I am using Eclipse Mars using the Eclipse C++ Arduino extension. I am also using the COSA library, this is where the problem comes in. I can use all of the core COSA libraries but I can not figure out how to include the other libraries that are supplied with COSA specifically the ST7920.h file that is located in the libraries folder. Does anyone have any experience with this?

I have tried setting the path using the Project->C/C++ General->Preprocessor include paths and setting it there to no avail.

One thing that I am concerned about is in these separate libraries they are including files that are in other libs using only the header file, for example in the ST7920.hh file it has:

    #include "Cosa/LCD.hh"
    #include <HD44780.h>

I need to configure things so that the HD44780.h file needs to be found also. That file is located at "../HD44780/HD44780.h". How do I tell the compiler to search the "libraries" folder for files?

Also I tried to simply add the libraries folder as a linked folder in my project, that also did not work.

the only code I have is the #include <ST7920.hh> and the compiler come back with that it can't find the file.

body:
If you are using Linux I would recommend looking at the makefile based build script for Cosa (See [Cosa/build][1]). After configuration building from any IDE is more or less a simple command. No Makefile is required. The script cosa will do all the work.

    $ cosa BOARD ACTION

such as

    $ cosa uno avanti

which will build a sketch for Arduino Uno, upload and start a serial monitor. This can be used from any IDE. I use GNU Emacs, M-X compile (F2), with the command.

The way the Arduino pre-processor works each referenced library needs to be included in the sketch. For a sketch that uses ST7920:

    #include <HD44780.h>
    #include <ST7920.h>

  [1]: https://github.com/mikaelpatel/Cosa/tree/master/build


body:
I would advice to use the arduino eclipse plugin and not use the eclipse C++ arduino extension.

The eclipse C++ arduino extension is still very much in development.

The Arduino eclipse plugin has been around for years and contains far more features.

If you use V3 (that is still the nightly at the time of writing) you can use the boards manager and the cosa json file to import the cosa boards.

Importing a lib is a matter of typing

    #include "libname"

and saving.


message:
Programming addressable LED

I have `TM1812` addressable `LED` strip (1meter long 96 LED). I am looking a way to `program` it and i found this [http://www.deskontrol.net/blog/arduino-based-artnet-node-for-led-pixels/][1]
and its mentioned in article that it doens't work with `current version` of Arduino `IDE`.

Is there some other lib/api available to program it or another method?

**UPDATE**
As mentioned by @dlu FastLED support wide variety of `LEDs`. I contacted developers of `FastLED` on google + and they have updated there documentation for support of `TM1812` its similar to `TM1809`

  [1]: http://www.deskontrol.net/blog/arduino-based-artnet-node-for-led-pixels/

body:
There is a very nice library called [FastLED][1], it is also on [GitHub as FastLED/FastLED][2]. It is quite flexible and supports a huge range of addressable LEDs. I'm currently using it with 1.6.6.

The code that you linked to was developed with an older version of the Arduino IDE, so you might want to see if you can find an older version and try building with that.

[1]: http://fastled.io
[2]: https://github.com/fastled/fastled


message:
Prevent Switch case from not being complete

I got this program. It controls a refrigeration room using a ds1280 temperature probe.

The thing is, sometimes the probe reach 7.00°C then the refrigerattion cycle start (refrigeration cycle is on a switch case statment) and then the probe read 6.75. So the refrigeration don't complete its start and leaves part of the system in wrong mode.

How can I add some guard to ... once the switch case statment don't being interrupted by anything unless complete the on in this case or the off in other case.

Here are the most resembling parts of the code.

    void turnOnCompressor(){

    /*
    This subrutine is intended to stop the refrigeration cycle
    in the most ordered way, and keeping the refrigerant on
    the high side of the system.
    */

    // boolean refrigerattion = false; // var to handle ref status only once
    // byte compOn = 0;
    // byte pascomOn = 0; //to chek if the variable has updated.
    // unsigned long  comOnTime  = 0;
    // unsigend long  comOnDelay = 1500;
    // unsigend long  comOnCT    = 0;     //the current time of the compressor.

    //------for debug only
    //Serial.print("comOnCT  =             "); Serial.println(comOnCT);
    //Serial.print("comOnCT - millis()  =  "); Serial.println(millis() - comOnTime );

    // Serial.println("INICIANDO REFRIGERACION");

    if(refrigerationBegin == true )
    {

    if(refrigerattion == true && millis()- comOnTime  >= comOnDelay ){
       compOn ++;
       comOnTime = millis();
     /*
     //--------for debug only
     Serial.println("---------------------");
     Serial.print("Var compOn "); Serial.println(compOn);
     Serial.print("comoON  "); Serial.println(compOn);
     Serial.print("pascomON"); Serial.println(pascomOn);
     Serial.println("---------------------");
    */
    }

    if(compOn > pascomOn ){

      switch(compOn){

      case(1):
      lcd.setCursor(0,0);  lcd.print(F("      CICLO DE      "));
      lcd.setCursor(0,1);  lcd.print(F("    REFRIGERACION   "));
      lcd.setCursor(0,2);  lcd.print(F("                    "));
      break;

      case(2):
      lcd.setCursor(0,0);  lcd.print(F("    REFRIGERACION   "));
      lcd.setCursor(0,1);  lcd.print(F("     ENCENDIENDO    "));
      lcd.setCursor(0,2);  lcd.print(F("       VENT 1       "));
      digitalWrite(dif1, LOW);
      break;

      case(3):
      lcd.setCursor(0,0);  lcd.print(F("    REFRIGERACION   "));
      lcd.setCursor(0,1);  lcd.print(F("     ENCENDIENDO    "));
      lcd.setCursor(0,2);  lcd.print(F("       VENT 2       "));
      digitalWrite(dif2, LOW);
      break;

      case(4):
      lcd.setCursor(0,0);  lcd.print(F("    REFRIGERACION   "));
      lcd.setCursor(0,1);  lcd.print(F("     ENCENDIENDO    "));
      lcd.setCursor(0,2);  lcd.print(F("      SOLENOIDE     "));
      digitalWrite(solenoid, LOW);
      break;

      case(5):
      lcd.setCursor(0,0);  lcd.print(F("    REFRIGERACION   "));
      lcd.setCursor(0,1);  lcd.print(F("     ENCENDIENDO    "));
      lcd.setCursor(0,2);  lcd.print(F("      COMPRESOR     "));
      digitalWrite(compressor, LOW);
      break;

      case(6):
      lcd.setCursor(0,1);  lcd.print(F("                    "));
      lcd.setCursor(0,2);  lcd.print(F("                    "));
      refrigerattion = false;
      refOff = true     ;       // to cycle only once the set of the instructions per cycle.
      compOn = 0;
      cycleFansvar = false;        //bool to chek the refrigerattion has stop
      //--------------------------------
      //refrigerattion = true; add this variable at the end of the off routine to cycle the
      //operation otherwise will just start once
    }
    }
    }

    refrigerationBegin = false;
    }

    void turnOnCompressor(){

    /*
    This subrutine is intended to stop the refrigeration cycle
    in the most ordered way, and keeping the refrigerant on
    the high side of the system.
    */

    // boolean refrigerattion = false; // var to handle ref status only once
    // byte compOn = 0;
    // byte pascomOn = 0; //to chek if the variable has updated.
    // unsigned long  comOnTime  = 0;
    // unsigend long  comOnDelay = 1500;
    // unsigend long  comOnCT    = 0;     //the current time of the compressor.

    //------for debug only
    //Serial.print("comOnCT  =             "); Serial.println(comOnCT);
    //Serial.print("comOnCT - millis()  =  "); Serial.println(millis() - comOnTime );

    // Serial.println("INICIANDO REFRIGERACION");

    if(refrigerationBegin == true )
    {

    if(refrigerattion == true && millis()- comOnTime  >= comOnDelay ){
       compOn ++;
       comOnTime = millis();
     /*
     //--------for debug only
     Serial.println("---------------------");
     Serial.print("Var compOn "); Serial.println(compOn);
     Serial.print("comoON  "); Serial.println(compOn);
     Serial.print("pascomON"); Serial.println(pascomOn);
     Serial.println("---------------------");
    */
    }

    if(compOn > pascomOn ){

      switch(compOn){

      case(1):
      lcd.setCursor(0,0);  lcd.print(F("      CICLO DE      "));
      lcd.setCursor(0,1);  lcd.print(F("    REFRIGERACION   "));
      lcd.setCursor(0,2);  lcd.print(F("                    "));
      break;

      case(2):
      lcd.setCursor(0,0);  lcd.print(F("    REFRIGERACION   "));
      lcd.setCursor(0,1);  lcd.print(F("     ENCENDIENDO    "));
      lcd.setCursor(0,2);  lcd.print(F("       VENT 1       "));
      digitalWrite(dif1, LOW);
      break;

      case(3):
      lcd.setCursor(0,0);  lcd.print(F("    REFRIGERACION   "));
      lcd.setCursor(0,1);  lcd.print(F("     ENCENDIENDO    "));
      lcd.setCursor(0,2);  lcd.print(F("       VENT 2       "));
      digitalWrite(dif2, LOW);
      break;

      case(4):
      lcd.setCursor(0,0);  lcd.print(F("    REFRIGERACION   "));
      lcd.setCursor(0,1);  lcd.print(F("     ENCENDIENDO    "));
      lcd.setCursor(0,2);  lcd.print(F("      SOLENOIDE     "));
      digitalWrite(solenoid, LOW);
      break;

      case(5):
      lcd.setCursor(0,0);  lcd.print(F("    REFRIGERACION   "));
      lcd.setCursor(0,1);  lcd.print(F("     ENCENDIENDO    "));
      lcd.setCursor(0,2);  lcd.print(F("      COMPRESOR     "));
      digitalWrite(compressor, LOW);
      break;

      case(6):
      lcd.setCursor(0,1);  lcd.print(F("                    "));
      lcd.setCursor(0,2);  lcd.print(F("                    "));
      refrigerattion = false;
      refOff = true     ;       // to cycle only once the set of the instructions per cycle.
      compOn = 0;
      cycleFansvar = false;        //bool to chek the refrigerattion has stop
      //--------------------------------
      //refrigerattion = true; add this variable at the end of the off routine to cycle the
      //operation otherwise will just start once
    }
    }
    }

    refrigerationBegin = false;
    }

body:
Are you trying to control by temperature or by time?

(I'm finding the code hard to follow. There seem to be 2 copies of it, and the comments in turnOnCompressor() seem to contradict the function name. I also don't see any code that mentions temperature.)

If this is temperature controlled, you need a dead-band - a temperature range bounded by a high- and a low setpoint. If you have a single setpoint, the system will jitter as air-circulation and electrical noise make the temperature appear to alternate above and below setpoint. The turn-on setpoint needs to be higher than the turn-off setpoint. You'll need to experiment to find out how far apart they need to be for the system to be stable.