text:
Which kind of diodes I should use in buttons/keys matrix input? (Making gaming keyboard)
When making matrix input of NxM columns/rows with push buttons, there should be a diode next to each button to prevent "ghosting" and able read many keys pressed together correctly. There is a lot of pictures everywhere.
My problem is, which diodes to use and also why this type (or why it does not matter).

More details:
I would use 5 V Arduino (ATmega32U4), datasheet states for input low voltage max 0.3Vcc, which is 1.5 V and minimal high input voltage 0.7Vcc = 3.5 V and pullups at least 1.5 kΩ (Vcc-0.4 V / 3 mA)
I would like to use 74HC138 3-to-8 decoder for addressing, which makes one of 8 outputs Low (max 0.1 V), while other 7 High (min 4.5 V) and drive the Arduino inputs Low, if button is pressed.
To be on safe side, I would like also add resistors on each pin to make sure, that bad programming (make some input pin OUTPUT and HIGH and pressing key connect it to LOW output on other side) could not damage the circuits, so it looks like 5 V/20 mA = 250 Ω (and I will hope it would not hit more pins, so I would not consider total port/chip limitations).
In typical case it would be 5 V - 1.5 kΩ pullup - input - 250 Ω - wires and button - diode - 250 Ω - 0.1 V for selected line.
If the diode would be theoretical and ideal, then there is (in the worse case) promised to be max 1.2 V on Input, which is slightly less then "maximal low" voltage (1.5 V) and like 5V/2 kΩ = 2.5 mA current.
But the diode is not ideal and have some forward voltage, which make the case even worse.
So I probably cannot use simply INPUT_PULLUP (as it may work by luck, but is not guaranted by specs) but I need to use INPUT and set some higher pullup there to "burn" more volts on it to compensate for the diode.
The Input Current for each pin is 10 µA (in or out) and I heard some recommendation, that on resistor divider should be the total current 10x more, then the input current, so it would mean 100 µA = 0.1 mA
The pullup then could go as high as ((5 V - 0.1 V - Vf)/0.1 mA ) - 500 Ω If the forward voltage would be 1 V (wild guess) it would go to something like 38.5 kΩ pullup and 1.15 V on input. The maximal Vf forward voltage would be like 1.35 V (at 0.1 mA), pullup 35 kΩ and 1.5 V on input.

My problem is, that many online Arduino schemes works just because Arduino usually work good even in way out-of-spec situations, and suggested values cames from what the author just randomly had at hands and it worked by pure luck and maybe another hidden factors, as parasite capacity of breadboard or so. So I want to uderstand, why I should choose some parts and how to came to such conclusions by myself.
I want to make reliable projects, not just projects, which works most of the time and fail only occasionally.

It is the right path, how to compute it or did I some mistake?
I want use scanning frequency at least 800 Hz (8 lines and results
100x per second) or more (like 10 kHz to be done fast and to have more time to spend with other
tasks, like sending USB packets, computing macros, managing light
effects etc)
which common and cheap SMD diodes I should buy?

reverse voltage over 5 V, current over 100 mA, switch frequency over 10 kHz, forward voltage under 1.3 V at 0.1 mA (rather much less to have safe gap from limits)
really common cheap model, so everybody would know it and so I could use it everywhere in similar settings without thinking ( or even computing like in previous section)
preferably what you (and everyone else and his dog too) use for such cases
I would like to order from AliExpress, so rather higher margin for guaranteed values
preferably to fit on 0.1 inch spaced universal PCB (0805 SMD LEDs are really easy to solder there (so rather not smaller than that), but it may be twice the size too or something like that)
I would buy like some hundreds of such diodes to have them ready on hands and I will probably make more similar projects over time for me and my friends

Thanks for all comments and suggestions

Thanks for directing me to Electrical Engeneering, where the 1N4148 was so common in questions/answers, that I googled it and found, that it is ideal for nearly everything I could possibly do with  Arduino I/O pins. My problem is SOLVED

When I've used a keypad matrix I've wired it up like this:

I used 1N4148 SMD diodes which I bought cheaply. I cut the traces on my cheap board that I had purchased from Jaycar and soldered them in like this:

The dot is the cathode (there is a line etched on my diodes at the cathode end).
The 10k resistors effectively turn the columns into pull-ups, therefore there is no danger of bad code damaging the Arduino or anything else.
Example code to scan the matrix:
// Keypad_Decoder
//
// Author: Nick Gammon
// Date: 17th February 2018

// Outputs to Serial in the format: 0b1nnnnnnn for a key down and 0b0nnnnnnn for a key-up
//            nnnnnnn will be the current row/column combination
//            Also every HEARTBEAT_TIME outputs 0xFF if all keys are up (heartbeat)

#include <limits.h>     /* for CHAR_BIT */

const byte ROWS = 4;
const byte COLS = 4;
const bool ENABLE_PULLUPS = true;  // make false if you are using external pull-ups
const unsigned long DEBOUNCE_TIME = 10;     // milliseconds
const unsigned long HEARTBEAT_TIME = 2000;  // milliseconds
const bool DEBUGGING = false;               // make true for human-readable output

// define here where each row and column is connected to
const byte rowPins [ROWS] = {6, 7, 8, 9}; //connect to the row pinouts of the keypad
const byte colPins [COLS] = {2, 3, 4, 5}; //connect to the column pinouts of the keypad

// See: http://c-faq.com/misc/bitsets.html

#define BITMASK(b) (1 << ((b) % CHAR_BIT))
#define BITSLOT(b) ((b) / CHAR_BIT)
#define BITSET(a, b) ((a)[BITSLOT(b)] |= BITMASK(b))
#define BITCLEAR(a, b) ((a)[BITSLOT(b)] &= ~BITMASK(b))
#define BITTEST(a, b) ((a)[BITSLOT(b)] & BITMASK(b))

// number of items in an array
#define ARRAY_SIZE(x) (sizeof(x) / sizeof((x)[0]))

// total number of keys
const byte TOTAL_KEYS = ROWS * COLS;

// remember previous setting of each key
char lastKeySetting [(TOTAL_KEYS + CHAR_BIT - 1) / CHAR_BIT];  // one bit each, 0 = up, 1 = down
unsigned long lastKeyTime [TOTAL_KEYS];       // when that key last changed
unsigned long lastHeartbeat;                  // when we last sent the heartbeat

void setup ()
{
  Serial.begin (115200);
  while (!Serial) { }  // wait for Serial to become ready (Leonardo etc.)

  // set each column to input-pullup (optional)
  if (ENABLE_PULLUPS)
    for (byte i = 0; i < COLS; i++)
      pinMode (colPins [i], INPUT_PULLUP);

}  // end of setup

void loop ()
  {
  byte keyNumber = 0;
  unsigned long now = millis ();  // for debouncing

  // check each row
  for (byte row = 0; row < ROWS; row++)
    {
    // set that row to OUTPUT and LOW
    pinMode (rowPins [row], OUTPUT);
    digitalWrite (rowPins [row], LOW);

    // check each column to see if the switch has driven that column LOW
    for (byte col = 0; col < COLS; col++)
      {
      // debounce - ignore if not enough time has elapsed since last change
      if (now - lastKeyTime [keyNumber] >= DEBOUNCE_TIME)
        {
        bool keyState = digitalRead (colPins [col]) == LOW; // true means pressed
        if (keyState != (BITTEST (lastKeySetting, keyNumber) != 0)) // changed?
          {
          lastKeyTime [keyNumber] = now;  // remember time it changed
          // remember new state
          if (keyState)
            BITSET (lastKeySetting, keyNumber);
          else
            BITCLEAR (lastKeySetting, keyNumber);
          if (DEBUGGING)
            {
            Serial.print (F("Key "));
            Serial.print (keyNumber);
            if (keyState)
              Serial.println (F(" down."));
            else
              Serial.println (F(" up."));
            }  // if debugging
          else
            Serial.write ((keyState ? 0x80 : 0x00) | keyNumber);
          }  // if key state has changed
        }  // debounce time up
      keyNumber++;
      } // end of for each column

    // put row back to high-impedance (input)
    pinMode (rowPins [row], INPUT);
    }  // end of for each row

  // Send a heartbeat code (0xFF) every few seconds in case
  // the receiver loses an occasional keyup.
  // Only send if all keys are not pressed (presumably the normal state).
  if (now - lastHeartbeat >= HEARTBEAT_TIME)
    {
    lastHeartbeat = now;
    bool allUp = true;
    for (byte i = 0; i < ARRAY_SIZE (lastKeySetting); i++)
      if (lastKeySetting [i])
        allUp = false;
    if (allUp)
      {
      if (DEBUGGING)
        Serial.println (F("No keys pressed."));
      else
        Serial.write (0xFF);
      } // end of all keys up
    } // end if time for heartbeat
  } // end of loop

Speedwise, I measured around 300 µs for doing a scan with no keys pressed. If that time seems a bit long, you could always do a time check, and scan every 5 ms or so.
I have a post about all this on my forum. In that post I also mention a library that handles N-key rollover, so you can detect multiple keys being pressed at the same time. For example, you could use A/B/C/D on the keypad as "shift" keys, so that A+1 meant something different than just 1.

Matrix from the front:

My problem is, which diodes to use and also why this type (or why it does not matter).

I don't think the exact diode is critical in this case. If this was a very high speed application, then a diode with fast switching might be required. If it was high voltage then a higher-spec diode might be required. In some cases the reverse voltage might apply. In this particular case, since we are dealing on/off at logic levels, I don't think much of this matters, although the switching speed might to a certain extent, however I am guessing from empirical observations that the speed of the 1N4148 is fast enough.
Also see: Wikipedia - 1N4148:

The 1N4148 is useful in switching applications up to about 100 MHz with a reverse-recovery time of no more than 4 ns.

Thank you, your answer would help many readers. But my question was more which type of diede to use (as you say IN4148) and mainly WHY, as I could found lot of schemes everywhere, little states what diode uses and none discuss, why this type exactly, or why it does not matter. There are many other kind of schemes on web, where correct values are critical (like some HiFi or so) and many schemes, where the values are just what author had handy and it does not work correctly in general, but he just had luck one time with out-of-spec just randomly worked for him. I wanted uderstand this point.

About bad programming - I often use sockets on my projects and reuse the microcontroller in other projects, when one came obsolete or I do not need it just now. Later I may go back to it again and put some MC to the socket and upload the original code again. So I was afraid of putting MC programmed for other project  (where it would set the pin for COL1 to High and pin for ROW1 to Low) to the socket and press the left top key before uploading corect code inside. So effectively shortcut those two pins and lead 5V to 0V over diode. ...

... So I put the restricting 250 Ohm resistors there to limit the current to 10mA even in this kind of mistake. (Similar thing happened to me before already, I soon realized, that the project does not work, but it was already late. So I came more paranoid about "impossible" programming bugs and I try to make HW such way, that it would nothing burn even if the MC actively tries to bur it/itself)

PS: I really like your site and read it often :)

Thanks! I've added another paragraph at the end explaining the choice of diode.

Solution: 1N4148 diode
generally if you want connect diode to Arduino pin, use this one as it would be OK under nearly any normal use

75 V reverse voltage (much more than 5V allowed there)
1 V forward voltage at 10 mA (less at lower current)
10 mA recommended current (destroys at 1 A 1 sec pulse) (and you do
not want more then 10 mA anyway)
usable up to 100 MHz (so using digitalRead/digitalWrite and
some logic you are way slower anyway)
super extra common for long time (even 10 years ago was considered
"classical") and still actual (so when you get old, it would still be
here)
dirty cheap (buy few hundreds just now and you do not need care
anymore)


text:
(SOLVED) Fast HW check: (18 digital + 4 analog to I2C ) Arduino Mini Pro + MCP23017 or STM32?
Arduino Mini Pro+MCP23017 or  STM32
I want make device, which reads 17 digital buttons and 4 analog, process it somehow and send the result to I2C bus. Also there is a LED to be managed. I may want to attach some wireless too later, but I am not really sure, if I woud do it (which would need 5-6 mor digital pins). I need to update the firmware often, as it is under heavy developement just now. I should make the PCB as soon as possible, but programming can wait some time.
The PCB would have buttons and analogs on it (and MCP in the arduino case). Also lot of connectors, like I2C, programming interface and some power regulators, the LED (or maybe more of them, if there was few free pins, but it is not mandatory). The processor will be connected via wires for space reasons (and maintainability and the board may be redesined later), so only long row of soldering pads on PCB for it.
Main decision:
If I opt to Arduino, then MCP will be part of the PCB and connected to I2C bus, if I use STM32, no MPC will be present and buttons would go directly to output connector.
Making the HW is no problem for me, the logic inside is also easy (basically read all inputs, normalize analogs to some range, make some simple tests and if desired, send result over I2C. Reply to some simple I2C too.)
I have a lot of Arduino Mini Pro, but it is few legs short for the task, so I would use MCP23017 expander for 16 of that digital buttons.
I also got some these STM32
https://www.aliexpress.com/item/STM32F103C8T6-ARM-STM32-Minimum-System-Development-Board-Module-For-Arduino/32279776568.html but did not open the package yet. Anyway I want to learn to use them "sometimes soon".
Maybe it is just the kind of starter project, which I would like to do.
Now I am just not sure about the number of available pins on the STM32, on first look it have more pins, but each description I found yet states too much details about additional functions, but I got confused about the basics here. So my question is:
Can mentioned STM be easilly programed as Arduino, manage I2C communication, and still have comfortable 18+4 I/O pins free? And 23+4 I/O free?

Have you heard the word "Multiplex"?

like in http://tronixstuff.com/2011/08/26/tutorial-maximising-your-arduinos-io-ports/ with the mentioned  MCP23017 expander? Yes, I did. I am also aware about resistor dividers to read more buttons. But the question goes other way - can STM32 do it without such tricks? If so, I will start learning it today, if not, I will postpone it to next month or two.

http://playground.arduino.cc/Main/KeypadTutorial

Nice, but I am not going to use this device, and I want to be able read all combination of buttons. Also I would like to be able to use interrupts to detect change, which is not possible with scanning methods.

@gilhad Why it shouldn't be possible? You can set all columns to zero and enable pin change interrupts on all rows. And when the interrupt is detected, you can start scanning for a while (with pin change interrupts disabled). Or it can be used for waking up from the sleep mode.

Good idea. Thank you. But anyway my problem is if I can easily use STM32 and "brutal force it" with enough pins (which I would like to do), or if it is not possible this way, in which case I would use Arduino mini and some kinds of "tricks" (which is plan B).

Can mentioned STM be easilly programed as Arduino, manage I2C communication, and still have comfortable 18+4 I/O pins free? And 23+4 I/O free?

it can be programed as Arduino, manage I2C communication, and still have 18+4 I/O pins free or 23+4 I/O free.
it is only knowable to the person programming it whether it can be done easily or comfortably.

I am the person and I need to learn that. In "easily" I mean like in arduino with the usual digitalRead(pin) for pin in 2..13 and A0..A7 and analogRead(pin) for pin in A0..A7 (avoiding A4/A5 for I2C). Just link Wire library, set some callback function like void receiveEvent(int howMany) . Without going to disable reset, repurpose Xtal pins and so on to get more available pins or other black magic. I consider the whole task easy on Arduino Mini Pro with MCP23017.  So the question is like would it be on equal "easy" on STM32 ?

Putting aside the additional task of setting up too chains for STM32, yes, the tasks would be equally easy if you have the corresponding libraries.

if you don't have the corresponding libraries, the task is not difficult if you reasonably proficient in reading / understanding datasheet and coding to it.

I can for example basically write a set of code that runs across the arduino and pretty much any chips I want, by hooking in the appropriate libraries as middleware.

Thank you, so it is decided and I wil go with STM32. I will set the compile/upload chains anyway, and I just found Wire library for STM32, so everything should go reasonable well :)

source: Stack Exchange

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

sort: votes


text:
SDA and SCL problem with MEMS
I have a simple question to ask you about SDA and SCL pins.
I have a gyro and I use these 2 pins to make it work; how can I use an accelerometer combined to a Gyro if these 2 pins are used? I should need another 2 SDA and SCL pins for the accelerometer... Tell me that I don't need to buy an IMU :D
EDIT: I'm using Gyro LG3D20H from Adafruit, reading gyro values each 10 ms.

Which gyro? Which accelerometer? Giving part numbers helps get a more specific answer.

Typically it should not be a problem to share them. Note that you can also get 6-axis sensors like the MPU6050 and similar which combine both functions in a single chip.

I2C is designed to have multiple devices connected. Assuming the gyro and accelerometer have different I2C addresses they can both be connected to the same SDA and SCL pins.
For more information see http://www.gammon.com.au/i2c
Naturally you can only "talk to" one at a time. You may need pull-up resistors on both SDA and SCL, unless the hardware already has them.

For a newbie this thing is a bit complex. Do you have a "noob" guide to link me?

As I said in my answer, you can share the SDA and SCL pins for both devices. If you have more questions please give more information.

As I said, I have a Gyro that use SDA and SCL. I'd like to buy an accelerometer and use both in the same time. I know that there are analog pins that I could use for accelerometer (or gyro, depends on which I put on SDA/SCL), but I need that both are on SDA and SCL. I'm not smart in electronics so I really don't know how to use that guide that you linked.

@Kowak, to get specific answers you need to supply more-specific information.  Please edit your question and add the model numbers or chip numbers of  your gyro, and of accelerometers you are thinking of.  Also tell how frequently you need to read them, and whether you've modified their I2C addresses

I edited with my gyro name and frequency of gyro value readings. The problem is that I don't know which accelerometer I want to buy at the moment...

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


text:
LEDs instruction code does not loop
I am using Neopixel Library and a Trinket Pro 5V Microcontroller to chase first three LEDs on a strip and then burst the last 2 (could be modified based on the number of LEDs).
The LEDs chase only once. See the code below. I am not sure why, even though the logic is inside the loop function, it only executes once. Any suggestions?
#include <Adafruit_NeoPixel.h>
#include "WS2812_Definitions.h"
#ifdef __AVR__
  #include <avr/power.h>
#endif

// Which pin on the Arduino is connected to the NeoPixels?
// On a Trinket or Gemma we suggest changing this to 1
#define PIN            6

// How many NeoPixels are attached to the Arduino? How many Neopixels do you want to chase (starting from the first in address 0. How many do you want to burst at the end?
#define NUMPIXELS      5
#define NUMPIXELSCHASE 3
#define NUMPIXELSBURST 2

// When we setup the NeoPixel library, we tell it how many pixels, and which pin to use to send signals.
// Note that for older NeoPixel strips you might need to change the third parameter--see the strandtest
// example for more information on possible values.
Adafruit_NeoPixel pixels = Adafruit_NeoPixel(NUMPIXELS, PIN, NEO_GRB + NEO_KHZ800);

void setup() {
  // This is for Trinket 5V 16MHz, you can remove these three lines if you are not using a Trinket
#if defined (__AVR_ATtiny85__)
  if (F_CPU == 16000000) clock_prescale_set(clock_div_1);
#endif
  // End of trinket special code

  pixels.begin(); // This initializes the NeoPixel library.
  clearLEDs();
  pixels.show();
}

void loop() {

  // For a set of NeoPixels the first NeoPixel is 0, second is 1, all the way up to the count of pixels minus one.
  for(int i=0;i<NUMPIXELSCHASE;i++){

   pixels.setPixelColor(i, INDIGO);
   pixels.show(); // This sends the updated pixel color to the hardware.
   delay (200);
  }

  for(int i=NUMPIXELS-NUMPIXELSBURST;i<NUMPIXELS;i++){

   pixels.setPixelColor(i, AQUA);
   pixels.show(); // This sends the updated pixel color to the hardware.
   delay(0);
  }
}

// Sets all LEDs to off, but DOES NOT update the display;
// call leds.show() to actually turn them off after this.
void clearLEDs()
{
  for (int i=0; i<NUMPIXELS; i++)
  {
    pixels.setPixelColor(i, 0);
  }
}

Thank you.

Your 1st pixel should go indigo & stay there, & the other 2 very briefly show Aqua before going back to Indigo. Try a longer delay than 0 at the end, and then clear them down for the next loop.

I agree. Those NeoPixels update quickly. A delay(0) doesn't seem very sensible.


text:
Adafruit Neopixel Library- only the first 16 LEDs respond
I am using Adafruit Neopixel Library to work with a strand of 21 RGB LEDs.
AT this point only the first 16 light up. It is not a soldering problem, battery issue or a short.
This troubleshooting page suggests to

"confirm that the number of LEDs in the LPD8806() constructor match the
  number of LEDs in the strip (both will be 32 if using the strandtest
  example and a single meter of LEDs)."

But looking at the library code below, I am not certain where to modify. Adafruit_Neopixel master zip has 2 files, which contain source code. One is Adafruit_Neopixel.cpp and the other Adafruit_Neopixel.h.
Thank you.

It is not a soldering problem, battery issue or a short. You're driving this thing off a battery? How many Amps is your power supply?

@Paul 2000mAh at 3.7V Lipo battery

Do you have a link/datasheet? Or do you know the "C" rating? And do you have a voltage/multi-meter?

When something works, but not completely, it's often due to power issues.

Embedded things, microcontrollers/Arduino are fairly robust and "logical".
Hence, if your Arduino program works today, it'll work tomorrow.
Analog devices, or electricity is (in my eyes) often a bit vague. A chip can get enough power to run, but not enough to work properly.
The NeoPixel
Adafruit has an extremely elaborated tutorial/userguide.

Powering the NeoPixels

This also seems to fit your problem.

You could try powering the strip from the middle.
Since your voltage isn't stable, your amperage might not be as high and the resistance may be a little big. It's actually quite impressive that it works.

Each NeoPixel can draw up to 60 milliamps at full brightness.

2000mAh does not mean it can (always) deliver 2000mA. It depends on the "C" or discharge rating of the battery. So if your battery is rated 0.5 C it'll only be able to supply 1000mA (for 2 hours).
60*21 would be well over 1000mA, actually 60*16 is just below 1mA, so this would fit your problem.

The voltage of a battery depends on how much charge it has.

Check google for: "LiPo voltage drop"

If all else fails

There is a chance that that particular LED is broken. The signal will not continue to the other LED's and thus the light of the strip will end there.
Try to drive the LED's behind the LED that fails. (With the power supply closer).
I'm also not sure if you can supply 3.7V and then use 5V logic. Things like that would often break a microcontroller (when running on 3.3V, you usually can't receive 5V?)

This is a good answer. I have a strip of 300 NeoPixels, and sending "pure white" to them, the other end has gone yellow. And this is with a power supply that should cope with the current requirements. Your 21 pixels, at full brightness, and consuming 60 mA would need 1.26 amps. Are you powering them from a separate power supply? One with that capacity?

@NickGammon according to the comment in the main question he's powering 21 LED's  off a "2000mAh at 3.7V Lipo battery" but he hasn't yet specified the maximal discharge rate/current (which might be below 2000mA).

See my amended reply. 3.7V is a little low for the specs.

@NickGammon Good point, if you check Li-Po discharge curves, it would also mean that the battery has to have 20%> charge since the voltage drops  when you have less charge. But apart from that it should work, Adafruit itself states that it is possible for wearable projects — a 3.7 Volt lithium-polymer battery. (Adafruit Neopixel Uberguide)

@NickGammon the discharge rate for the battery is 2C. Here is the spec for the battery https://solarbotics.com/product/battr15/

@K.Nadkina That's quite a lot indeed (4 Amps) should be sufficient. But you should try driving the LED's that come after the "faulty" LED. And/or try to power the strip from the middle.

You don't modify the library at all. The page refers to the constructor which is the last line here:
#include <Adafruit_NeoPixel.h>

#define PIN 6

Adafruit_NeoPixel strip = Adafruit_NeoPixel(60, PIN, NEO_GRB + NEO_KHZ800);

So that would send to 60 NeoPixels. Change the 60 to however-many you have.
To compare, try running my library here. That doesn't use the Adafruit library. Use the minimal demo code, and change PIXELS to be 21.
#include <SPI.h>
#include <NeoPixels_SPI.h>

const unsigned int PIXELS = 8; // Number of pixels in the string

void setup ()
  {
  ledsetup();
  showColor (PIXELS, 0xB2, 0x22, 0x22);  // firebrick
  } // end of setup

void loop ()
  {
  } // end of loop

Note that you connect the NeoPixels data to pin D11 of your Uno in this case.

@Paul 2000mAh at 3.7V Lipo battery

according to the comment in the main question he's powering 21 LED's off a "2000mAh at 3.7V Lipo battery"

Yes, well let's look at the specs:

If you lose 0.2V over the first 8 LEDs you are under spec for the voltage.

I did change the num of PIXELS to 21 in every example in your library and still only 16 light up. any thoughts, suggestions?

Maybe that particular LED is broken. Try if you can power/test the LED's after LED 16.

With most led strips you can supply power from both ends if you are experiencing voltage drop.
You can do this with two separate power supply units if you don't have one unit that is capable of powering the entire strip.
I'm not sure if power is your entire problem, but if it is you could try this solution.
If it's a problem with the Neopixel library You could also try the excellent FastLED library and see if that helps you sort out your issues.

Could you expand upon your answer a little, and explain why it might help? Even though your answer may be correct, unfortunately, as it stands, your answer has been flagged for "its length and content" and may be deleted.


text:
Using more than 8 digits using the sevseg library
I am using sevseg and i can't get more than 8 digits to work.  I really need 15.  Does somebody know what I can do to get this?
Shown is the original example
This is using Gabriel Staples example in the sevseg library:
#include <SevSeg.h>

SevSeg sevseg; //Instantiate a seven segment controller object

void setup()
{
  byte numDigits = 4; //<<---I am wanting 15, but doesn't work after 8------
  byte digitPins[] = {2, 3, 4, 5}; //Digits: 1,2,3,4 <--put one resistor (ex: 220 Ohms, or 330 Ohms, etc, on each digit pin)
  byte segmentPins[] = {6, 7, 8, 9, 10, 11, 12, 13}; //Segments: A,B,C,D,E,F,G,Period

  sevseg.begin(COMMON_ANODE, numDigits, digitPins, segmentPins);
// Note: 100 brightness simply corresponds to a delay of 2000us after lighting each segment. A brightness of 0
// is a delay of 1us; it doesn't really affect brightness as much as it affects update rate (frequency).
// Therefore, for a 4-digit 7-segment + pd, COMMON_ANODE display, the max update rate for a "brightness" of 100 is 1/(2000us*8) = 62.5Hz.
// I am choosing a "brightness" of 10 because it increases the max update rate to approx. 1/(200us*8) = 625Hz.
// This is preferable, as it decreases aliasing when recording the display with a video camera....I think.
  sevseg.setBrightness(10);
}

void loop()
{
  //local vars
  static byte decPlace = 0;

  sevseg.setNumber(8888,decPlace);
  decPlace++;
  decPlace %= 4; //rollover back to 0 once variable gets to 4; To anyone wondering: the % is called the "modulo" operator; see here for explanation & example: https://www.arduino.cc/en/Reference/Modulo

  sevseg.refreshDisplay(); // Must run repeatedly; don't use blocking code (ex: delay()) in the loop() function or this won't work right
}

Using the following code, I can't get the 3rd set of 5 numbers to display.  I have changed the sevseg.h file to 15, but that shouldn't matter:
#include <SevSeg.h>

SevSeg sevseg1;//Instantiate a seven segment controller object 1
SevSeg sevseg2;//Instantiate a seven segment controller object 2
SevSeg sevseg3;//Instantiate a seven segment controller object 3

void setup()
{

  Serial.begin(9600);

byte segmentPins[] = {22, 23, 24, 25, 26, 27, 28, 34}; //Segments:     A,B,C,D,E,F,G,Period

  byte digitPins1[] = {29, 30, 31, 32, 33};
  sevseg1.begin(COMMON_CATHODE, sizeof(digitPins1), digitPins1,  segmentPins);
  sevseg1.setBrightness(10);

  byte digitPins2[] = {35, 36, 37, 38, 39};
  sevseg2.begin(COMMON_CATHODE, sizeof(digitPins2), digitPins2, segmentPins);
  sevseg2.setBrightness(10);

  byte digitPins3[] = {40, 41, 42, 43, 44};
  sevseg3.begin(COMMON_CATHODE, sizeof(digitPins2), digitPins3, segmentPins);
  sevseg3.setBrightness(10);

}

void loop()
{

static byte decPlace = 2;

  sevseg1.setNumber( 12345, decPlace );
  sevseg2.setNumber( 12345, decPlace );
  sevseg3.setNumber( 12345, decPlace );

  sevseg1.refreshDisplay();
  sevseg2.refreshDisplay();
  sevseg2.refreshDisplay();
}

As per Dean Reading (programmer of sevseg.h) Using the example above, there will be a byte overflow and it is not possible for more than 8 digits.  So to further my question, is it possible (and if so how) do I break it down to say 3 segments of 5 digits each?  This would work for me as well, but it is over my head.  Thanks for any help I can get

Answer edited to show multiple instances, one to handle 8 digits, the other to handle 7 digits.

What Arduino are you using?  15 digits + 8 segments requires 23 IO pins, so I hope you are using a Mega2560.

You can change the pre-defined maximum number of digits at the top of the SevSeg.h header file to as many as 10, if you use long or unsigned long when you call setNumber.  It is defined here, on line 27:
#define MAXNUMDIGITS 8 //Increase this number to support larger displays

This the version referenced from the Arduino Playground SevSeg.  Be sure to use the same number in your modulo, too:
void loop()
{
  //local vars
  static byte decPlace = 0;

  sevseg.setNumber(8888,decPlace);
  decPlace++;
  decPlace %= 10; //rollover back to 0 once variable gets to 10

decPlaces is mostly useful for floating-point numbers: it specifies how many digits after the decimal point should be displayed.  For integer values, it specifies how many leading zeroes will be displayed.
However (as you discovered), you cannot call setNumber with anything larger than a long, so you are limited to 10 or fewer digits for MAXNUMDIGITS.  (There is no byte overflow -- it's just limited to the number of decimal digits in 232-1.)  This is a limit of one SevSeg instance.  You could have two instances of SevSeg like this:
#include <SevSeg.h>
SevSeg sevseg1;
SevSeg sevseg2;

void setup()
{
  byte segmentPins[] = {6, 7, 8, 9, 10, 11, 12, 13}; //Segments: A,B,C,D,E,F,G,Period

  byte digitPins1[] = {2, 3, 4, 5, 22, 23, 24};
  sevseg1.begin(COMMON_ANODE, sizeof(digitPins1), digitPins1, segmentPins);
  sevseg1.setBrightness(10);

  byte digitPins2[] = {14,15,16,17,18,19,20,21};
  sevseg2.begin(COMMON_ANODE, sizeof(digitPins2), digitPins2, segmentPins);
  sevseg2.setBrightness(10);

  sevseg1.setNumber(  7654321UL, 7 );
  sevseg2.setNumber( 87654321UL, 8 );
}

void loop()
{
  sevseg1.refreshDisplay();
  sevseg2.refreshDisplay();
}

The first instance handles 7 digits, and the second instances handles 8 digits.  Note the use of "UL" to force and unsigned long call.
Update 11-DEC-2015

Using the following code, I can't get the 3rd set of 5 numbers to display. I have changed the sevseg.h file to 15, but that shouldn't matter:

First, the MAXNUMDIGITS is the maximum per instance, so you could set it to 5 to save some precious RAM.
Second, you have a copy and paste error:
sevseg1.refreshDisplay();
sevseg2.refreshDisplay();
sevseg2.refreshDisplay();   <--  Oopsies!  :)

Third, I assume the setNumber calls are placeholders for what you're really going to use.  Since they always set the same value, they could be in setup.  In your final program, there must be some input that will be used to calculate a number to display with setNumber.

Good catch on the modulo. I'd suggest using numDigits instead of a fixed value though.

Sorry, new to this forum.  See comment above.

using 3 instance of 5 digits each... The last 5 digits are blank.  Is it not possible to use 3 instances?  I am using a Mega 2560

Add new code to your question?

Added.  Thanks @slash-dev.   I am starting to get a feel for stackexchange.  Thanks for your patience

@klarson18, update added to my answer.

Looking at the sevseg README file on GitHub I find this:

If you wish to use more than 8 digits, increase MAXNUMDIGITS in SevSeg.h.

Have you done that? Seems like that might be the problem.
As @slash-dev said, be sure to also modify the loop() code as well:
void loop()
{
  //local vars
  static byte decPlace = 0;

  sevseg.setNumber(8888,decPlace);
  decPlace++;
  decPlace %= numDigits;

I think it makes more sense to use numDigits rather than a hard coded constant that you have to remember to change whenever you change the number of digits in your display. It would be worth checking the code for any other hard coded constants. If space is an issue, it might be worth checking to see if using a #define results in smaller code than using a variable – in any case do something to avoid needing to understand what "magic numbers" are doing. This is especially important when the same numeric value (e.g., 4) is being used for multiple reasons. Then it gets hard if you need to change the value as you have to understand the purpose behind each use.

See the comment I made above also.  I am actually pulling numbers in from another program and can do that without an issue.  It is a set number of numbers.  The max I can get with the above code is 8 because of variables overflow.  Is there a way to do 3 segments of 5 digits each?  That will work as well.  Thanks in advance


text:
embedXcode: Link Error using an Arduino library (Servo.h) within a header file
For various reasons, I am moving from the Arduino IDE to Xcode using the embedXcode plugin. The code in question compiles and uploads fine from the Arduino IDE, so I think the issue is related to library definitions in embedXcode. The board I am using is an Arduino Mega 2560 (actually it is a Freetronics EtherMega).
The error thrown is:
Command /Applications/Xcode.app/Contents/Developer/usr/bin/make failed with exit code 2

More specifically:
    5.3-LINK                    Builds/embeddedcomputing.elf

/Applications/Arduino.app/Contents/Java/hardware/tools/avr/bin/avr-g++ -o Builds/embeddedcomputing.elf Builds/main.cpp.o Builds/embeddedcomputing.a -Os -w -mmcu=atmega2560 -Wl,--gc-sections  -LBuilds -lm
Builds/main.cpp.o: In function `Robot::Robot()':
main.cpp:(.text._ZN5RobotC2Ev[Robot::Robot()]+0x5e): undefined reference to `Servo::Servo()'
Builds/main.cpp.o: In function `Robot::begin()':
main.cpp:(.text._ZN5Robot5beginEv[Robot::begin()]+0x5a): undefined reference to `Servo::attach(int)'
main.cpp:(.text._ZN5Robot5beginEv[Robot::begin()]+0x64): undefined reference to `Servo::write(int)'
main.cpp:(.text._ZN5Robot5beginEv[Robot::begin()]+0xea): undefined reference to `Servo::write(int)'
main.cpp:(.text._ZN5Robot5beginEv[Robot::begin()]+0x112): undefined reference to `Servo::write(int)'
main.cpp:(.text._ZN5Robot5beginEv[Robot::begin()]+0x132): undefined reference to `Servo::write(int)'
Builds/embeddedcomputing.a(HB25MotorControl.cpp.o): In function `HB25MotorControl::HB25MotorControl(unsigned char)':
HB25MotorControl.cpp:(.text._ZN16HB25MotorControlC2Eh+0x14): undefined reference to `Servo::Servo()'
Builds/embeddedcomputing.a(HB25MotorControl.cpp.o): In function `HB25MotorControl::begin()':
HB25MotorControl.cpp:(.text._ZN16HB25MotorControl5beginEv+0x42): undefined reference to `Servo::attach(int, int, int)'
HB25MotorControl.cpp:(.text._ZN16HB25MotorControl5beginEv+0x58): undefined reference to `Servo::writeMicroseconds(int)'
Builds/embeddedcomputing.a(HB25MotorControl.cpp.o): In function `HB25MotorControl::stop()':
HB25MotorControl.cpp:(.text._ZN16HB25MotorControl4stopEv+0x12): undefined reference to `Servo::writeMicroseconds(int)'
Builds/embeddedcomputing.a(HB25MotorControl.cpp.o): In function `HB25MotorControl::moveAtSpeed(int)':
HB25MotorControl.cpp:(.text._ZN16HB25MotorControl11moveAtSpeedEi+0x44): undefined reference to `Servo::writeMicroseconds(int)'
collect2: error: ld returned 1 exit status
make: *** [Builds/embeddedcomputing.elf] Error 1
Command /Applications/Xcode.app/Contents/Developer/usr/bin/make failed with exit code 2

Robot.h contains a robot class which defines a Servo (for a turret) and two HB-25 MotorControl objects (which control the drive motors). The HB25MotorControl is a custom library that I have written for the Parallax HB-25 Motor Controller. It also uses the Servo library.
To answer the obvious questions:

Yes I have #include <Servo.h> in my HB25MotorControl library. You
can see the library code by following the link above. It is also
included in the main sketch.
I have compiled, linked and uploaded other sketches which use Arduino and custom libraries in Xcode using the embedXcode plugin.
My embedXcode Makefile definitions include
    the Servo library and the HB25MotorControl library. See extract
    below.

APP_LIBS_LIST = Wire Servo SoftwareSerial
USER_LIBS_LIST = NewPing Time DS3232RTC HB25MotorControl
Any suggestions on how to fix this error and get my code to build in Xcode would be greatly appreciated.

Did you add the Servo library to the set of files to compile?

I tried including Servo.h everywhere it might be needed. I'm aware of the Arduino IDE issue with libraries within libraries, but that isn't the case here. The code compiles ok within the Arduino IDE. Thanks for the suggestion though, I do think the issue is related to having a library within nested header files.

The header file is not the library. Get the files that have the actual code in them and compile and link them.

I used to use embedXcode, and I remember that if it asks you for donations and you decline, it deletes some files in your project that are needed to build.  I got around this by deleting the file called embedXcode_check or something like that.

I ended up contacting the developer of the embedXcode plugin. He was very helpful and provided the fix within a day. The cause of the issue is apparently the Arduino IDE has changed its library structure in the latest release.
The next version of embedXcode (release 4.1.4.) will include a fix for this, however if you can't wait until then you need to open ArduinoAVR_165.mk (located in the Makefiles group in Xcode) in your project and add the following line:
avr165_20 += $(foreach dir,$(APP_LIB_PATH),$(patsubst %,$(dir)/%/src/$(BUILD_CORE),$(APP_LIBS_LIST)))

After you add this line, the file should look like this:
# Two locations for Arduino libraries
#
APP_LIB_PATH = $(APPLICATION_PATH)/libraries
APP_LIB_PATH += $(APPLICATION_PATH)/hardware/arduino/$(BUILD_CORE)/libraries

avr165_20 = $(foreach dir,$(APP_LIB_PATH),$(patsubst %,$(dir)/%,$(APP_LIBS_LIST)))
avr165_20 += $(foreach dir,$(APP_LIB_PATH),$(patsubst %,$(dir)/%/utility,$(APP_LIBS_LIST)))
avr165_20 += $(foreach dir,$(APP_LIB_PATH),$(patsubst %,$(dir)/%/src,$(APP_LIBS_LIST)))
avr165_20 += $(foreach dir,$(APP_LIB_PATH),$(patsubst %,$(dir)/%/src/utility,$(APP_LIBS_LIST)))
avr165_20 += $(foreach dir,$(APP_LIB_PATH),$(patsubst %,$(dir)/%/src/$(BUILD_CORE),$(APP_LIBS_LIST)))
avr165_20 += $(foreach dir,$(APP_LIB_PATH),$(patsubst %,$(dir)/%/src/arch/$(BUILD_CORE),$(APP_LIBS_LIST)))

Note that each project has its own ArduinoAVR_165.mk file, so you will have to make this change in each project until you update to the new release.


text:
Arduino Uno R3 (with Atmega 16u2) and MAC OSX 10.11 (El capitan) not working
I have Chinese copy of arduino which uses ATmega16u2 (at least that's what is written on the chip itself). When connected, it is visible in system information under USB section:

Communication Device:
Product ID:   0x0043
  Vendor ID:    0x2341
  Version:  0.01
  Serial Number:    75237333636351600270
  Speed:    Up to 12 Mb/sec
  Manufacturer: Arduino (www.arduino.cc)
  Location ID:  0x1a140000 / 6
  Current Available (mA):   1000
  Current Required (mA):    100
  Extra Operating Current (mA): 0
  Built-In: Yes

But it doesn't show up in arduino program ports.
I've searched a lot, and it seems that people mostly had problems with arduinos on CH340 chips. I also have one such arduino, but it works properly after installing signed drivers as described here.
Are there any solutions for atmega 16u2 chips?
My system:

OS X El Capitan 10.11.2 (15C50) (hackintosh if it changes anything).
Arduino Uno R3 (chinese copy)
Arduino soft version 1.6.7

Additional info:
I've tried connecting Arduino Mega 2560 with Atmega16u2 chip and it also doesn't work
Info I've got using Nick's awesome program:
Atmega chip detector.
Written by Nick Gammon.
Version 1.17
Compiled on Jan  8 2016 at 21:35:08 with Arduino IDE 10607.
Attempting to enter ICSP programming mode ...
Entered programming mode OK.
Signature = 0x1E 0x94 0x89
Processor = ATmega16U2
Flash memory size = 16384 bytes.
LFuse = 0xFF
HFuse = 0xD9
EFuse = 0xF4
Lock byte = 0xFF
Clock calibration = 0x56
Bootloader in use: No
EEPROM preserved through erase: No
Watchdog timer always on: No
Bootloader is 4096 bytes starting at 3000

Bootloader:

3000: 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF
3010: 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF
3020: 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF
...

MD5 sum of bootloader = 0x6A 0xE5 0x9E 0x64 0x85 0x03 0x77 0xEE 0x54 0x70 0xC8 0x54 0x76 0x15 0x51 0xEA
No bootloader (all 0xFF)

First 256 bytes of program memory:

0: 0x90 0xC0 0x00 0x00 0xA9 0xC0 0x00 0x00 0xA7 0xC0 0x00 0x00 0xA5 0xC0 0x00 0x00
10: 0xA3 0xC0 0x00 0x00 0xA1 0xC0 0x00 0x00 0x9F 0xC0 0x00 0x00 0x9D 0xC0 0x00 0x00
20: 0x9B 0xC0 0x00 0x00 0x99 0xC0 0x00 0x00 0x97 0xC0 0x00 0x00 0x48 0xC4 0x00 0x00
30: 0x0C 0xC4 0x00 0x00 0x91 0xC0 0x00 0x00 0x8F 0xC0 0x00 0x00 0x8D 0xC0 0x00 0x00
40: 0x8B 0xC0 0x00 0x00 0x89 0xC0 0x00 0x00 0x87 0xC0 0x00 0x00 0x85 0xC0 0x00 0x00
50: 0x83 0xC0 0x00 0x00 0x81 0xC0 0x00 0x00 0x7F 0xC0 0x00 0x00 0x02 0xC1 0x00 0x00
60: 0x7B 0xC0 0x00 0x00 0x79 0xC0 0x00 0x00 0x77 0xC0 0x00 0x00 0x75 0xC0 0x00 0x00
70: 0x73 0xC0 0x00 0x00 0x71 0xC0 0x00 0x00 0x6F 0xC0 0x00 0x00 0x6D 0xC0 0x00 0x00
80: 0x6B 0xC0 0x00 0x00 0x69 0xC0 0x00 0x00 0x67 0xC0 0x00 0x00 0x65 0xC0 0x00 0x00
90: 0x63 0xC0 0x00 0x00 0x61 0xC0 0x00 0x00 0x12 0x01 0x10 0x01 0x02 0x00 0x00 0x08
A0: 0x41 0x23 0x43 0x00 0x01 0x00 0x01 0x02 0xDC 0x01 0x09 0x02 0x3E 0x00 0x02 0x01
B0: 0x00 0xC0 0x32 0x09 0x04 0x00 0x00 0x01 0x02 0x02 0x01 0x00 0x05 0x24 0x00 0x01
C0: 0x10 0x04 0x24 0x02 0x06 0x05 0x24 0x06 0x00 0x01 0x07 0x05 0x82 0x03 0x08 0x00
D0: 0xFF 0x09 0x04 0x01 0x00 0x02 0x0A 0x00 0x00 0x00 0x07 0x05 0x04 0x02 0x40 0x00
E0: 0x01 0x07 0x05 0x83 0x02 0x40 0x00 0x01 0x04 0x03 0x09 0x04 0x32 0x03 0x41 0x00
F0: 0x72 0x00 0x64 0x00 0x75 0x00 0x69 0x00 0x6E 0x00 0x6F 0x00 0x20 0x00 0x28 0x00

Programming mode off.

Fuses info:
Atmega fuse calculator.
Written by Nick Gammon.
Version 1.10
Compiled on Jan  8 2016 at 22:19:34 with Arduino IDE 10607.
Attempting to enter programming mode ...
Entered programming mode OK.
Signature = 0x1E 0x94 0x89
Processor = ATmega16U2
Flash memory size = 16384
LFuse = 0xFF
HFuse = 0xD9
EFuse = 0xF4
Lock byte = 0xFF
Clock calibration = 0x56
Hardare Boot Enable..................... [X]
Debug Wire Enable....................... [ ]
External Reset Disable.................. [ ]
Enable Serial (ICSP) Programming........ [X]
Watchdog Timer Always On................ [ ]
Preserve EEPROM through chip erase...... [ ]
Boot into bootloader.................... [ ]
Divide clock by 8....................... [ ]
Clock output............................ [ ]
Bootloader size: 4096 bytes.
Start-up time: SUT0: [ ]  SUT1: [ ] (see datasheet)
Clock source: low-power crystal.
Brownout detection at: 3.0V.

Do any other USB devices appear on this machine? Have you tried either Arduino on another machine (unlikely that both are faulty, but...) Do the Arduinos also fail to show up in the /dev/ directory?

Yep, USB is working fine. At the moment, I'm developing with another arduino, that has CH340 usb chip, which works great. Device is not appearing in /dev: ls tty.* tty.Bluetooth-Incoming-Port tty.serial1

The CH340 has a custom driver, while the ATmega16u2 runs off the standard USB stack. It's possible that this is an incompatibility with your hackintosh, so it would be interesting if you could try this on a genuine Mac. (I'm not sure whether an Apple store or dealer would permit you to plug an Arduino into their store Macs, but it can't hurt to ask).

@microtherion I'm working with arduino on my macbook, but it has yosemite, yet, and I'm afraid to update it, because then I will not have the possibility to program my arduinos. PS. It worked on this same hackintosh until it was using yosemite (with chimera), now I installed el capitan (and switched to clover) and this is when problems started :(

After two months I finally found a solution. The problem was with USB drivers for my hackintosh. Few days ago new Multibeast 8.1 was released with new USB drivers. After installing El Capitan 10.11.4 update and then installing USB drivers from Multibeast my Arduinos magically starter working again!

You can use my Chip detector sketch to confirm (using another Arduino to run the sketch) if the target chip is a Atmega16u2 or not, and if so, what fuses etc. are set.
Wiring would be like this:

Close-up:

ICSP header (from above):

You should see something like this:
Atmega chip detector.
Written by Nick Gammon.
Version 1.17
Compiled on Jan  3 2016 at 07:34:08 with Arduino IDE 10605.
Attempting to enter ICSP programming mode ...
Entered programming mode OK.
Signature = 0x1E 0x94 0x89
Processor = ATmega16U2
Flash memory size = 16384 bytes.
LFuse = 0xEF
HFuse = 0xD9
EFuse = 0xF4
Lock byte = 0xCF
Clock calibration = 0x96
Bootloader in use: No
EEPROM preserved through erase: No
Watchdog timer always on: No
Bootloader is 4096 bytes starting at 3000

Bootloader:

3000: 0x4B 0xC0 0x00 0x00 0x64 0xC0 0x00 0x00 0x62 0xC0 0x00 0x00 0x60 0xC0 0x00 0x00
3010: 0x5E 0xC0 0x00 0x00 0x5C 0xC0 0x00 0x00 0x5A 0xC0 0x00 0x00 0x58 0xC0 0x00 0x00
3020: 0x56 0xC0 0x00 0x00 0x54 0xC0 0x00 0x00 0x52 0xC0 0x00 0x00 0xEE 0xC4 0x00 0x00

...

MD5 sum of bootloader = 0xD8 0x8C 0x70 0x6D 0xFE 0x1F 0xDC 0x38 0x82 0x1E 0xCE 0xAE 0x23 0xB2 0xE6 0xE7
Bootloader name: Arduino-dfu-usbserial-atmega16u2-Uno-Rev3

First 256 bytes of program memory:

0: 0x90 0xC0 0x00 0x00 0xA9 0xC0 0x00 0x00 0xA7 0xC0 0x00 0x00 0xA5 0xC0 0x00 0x00
10: 0xA3 0xC0 0x00 0x00 0xA1 0xC0 0x00 0x00 0x9F 0xC0 0x00 0x00 0x9D 0xC0 0x00 0x00
20: 0x9B 0xC0 0x00 0x00 0x99 0xC0 0x00 0x00 0x97 0xC0 0x00 0x00 0x48 0xC4 0x00 0x00
30: 0x0C 0xC4 0x00 0x00 0x91 0xC0 0x00 0x00 0x8F 0xC0 0x00 0x00 0x8D 0xC0 0x00 0x00
40: 0x8B 0xC0 0x00 0x00 0x89 0xC0 0x00 0x00 0x87 0xC0 0x00 0x00 0x85 0xC0 0x00 0x00
50: 0x83 0xC0 0x00 0x00 0x81 0xC0 0x00 0x00 0x7F 0xC0 0x00 0x00 0x02 0xC1 0x00 0x00
60: 0x7B 0xC0 0x00 0x00 0x79 0xC0 0x00 0x00 0x77 0xC0 0x00 0x00 0x75 0xC0 0x00 0x00
70: 0x73 0xC0 0x00 0x00 0x71 0xC0 0x00 0x00 0x6F 0xC0 0x00 0x00 0x6D 0xC0 0x00 0x00
80: 0x6B 0xC0 0x00 0x00 0x69 0xC0 0x00 0x00 0x67 0xC0 0x00 0x00 0x65 0xC0 0x00 0x00
90: 0x63 0xC0 0x00 0x00 0x61 0xC0 0x00 0x00 0x12 0x01 0x10 0x01 0x02 0x00 0x00 0x08
A0: 0x41 0x23 0x43 0x00 0x01 0x00 0x01 0x02 0xDC 0x01 0x09 0x02 0x3E 0x00 0x02 0x01
B0: 0x00 0xC0 0x32 0x09 0x04 0x00 0x00 0x01 0x02 0x02 0x01 0x00 0x05 0x24 0x00 0x01
C0: 0x10 0x04 0x24 0x02 0x06 0x05 0x24 0x06 0x00 0x01 0x07 0x05 0x82 0x03 0x08 0x00
D0: 0xFF 0x09 0x04 0x01 0x00 0x02 0x0A 0x00 0x00 0x00 0x07 0x05 0x04 0x02 0x40 0x00
E0: 0x01 0x07 0x05 0x83 0x02 0x40 0x00 0x01 0x04 0x03 0x09 0x04 0x32 0x03 0x41 0x00
F0: 0x72 0x00 0x64 0x00 0x75 0x00 0x69 0x00 0x6E 0x00 0x6F 0x00 0x20 0x00 0x28 0x00

Programming mode off.

On my genuine Uno I get these settings from OS/X:
  Product ID:   0x0043
  Vendor ID:    0x2341
  Version:   0.01
  Serial Number:    74134373733351300000
  Speed:    Up to 12 Mb/sec
  Manufacturer: Arduino (www.arduino.cc)
  Location ID:  0xfd130000 / 8
  Current Available (mA):   500
  Current Required (mA):    100

I haven't had any problems using the Uno with OS/X however I don't remember whether or not I had to install a device driver for it.

Info I've got using Nick's awesome program:

...
Signature = 0x1E 0x94 0x89
Processor = ATmega16U2
Flash memory size = 16384 bytes.
LFuse = 0xFF
HFuse = 0xD9
EFuse = 0xF4
...
Bootloader:

3000: 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF
....

MD5 sum of bootloader = 0x6A 0xE5 0x9E 0x64 0x85 0x03 0x77 0xEE 0x54 0x70 0xC8 0x54 0x76 0x15 0x51 0xEA
No bootloader (all 0xFF)

It is interesting that they are shipping without a bootloader on the ATmega16U2. Whilst that chip doesn't need one (and it is disabled by the fuses in mine) clearly there are some differences. I checked the "first 256 bytes" of the code between your board and mine and they are the same, so possibly the main code is identical.
I would try to plug your Arduino into another Mac, if possible. It may be that your "hackintosh" has enough differences in its loaded software that it doesn't recognize that USB interface.

Thanks for the answer. I have checked your link, and as far as I understood, if I'll connect it like shown on the pictures, I'll get info about Atmega328p chip. How should I connect it to get info from the chip for working with usb (Atmega16u2)? PS. On older Mac OS X versions, it worked flawlessly and without any drivers,

See images in amended reply.

I've made a cable today, and here is what I found out: the chip is ATmega16U2, but it's configured slightly different. Here is what I got. Maybe You can say something from the log? I've added in my question.

See amended reply.

It works on my macbook, but it's using Yosemite (10.10), and not El capitan. And now I can't upgrade it, because if the problem is in El capitan, then I'll be left without the possibility to program my arduinos :(

There is complete documentation on Arduino website, I followed the steps and I was able to install driver
https://support.arduino.cc/hc/en-us/articles/4408887452434-Flash-USB-to-serial-firmware-in-DFU-mode

While this link may answer the question, it is better to include the essential parts of the answer here and provide the link for reference. Link-only answers can become invalid if the linked page changes.

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


text:
Can I use a GPS from old Garmin with an Arduino?
I'm working on an Arduino project, and I'd like to add GPS functionality. I could buy a GPS module, but those are expensive. I had an old Garmin Forerunner 305 lying around, so I took it apart and took a peek inside. There are two PCBs - one connected to a screen and one to the GPS. In addition, there was a battery and a small part for charging.
I'd like to know if it is possible to connect this GPS to my Arduino, and if so, how?
Edited:
To make my question more precise,
-I see the pins in the top right of the picture. How do I connect those to my Arduino? Is there any specific kind of wire? Because the pins are too small for standard wires.
-Once I connect it, how do I figure out the voltage requirements and pin layout? I tried googling the  GPS model, but nothing helpful came up. What kind of scope should I put on it?
The two pictures below show only the GPS part of the inside of the watch.

http://www.instructables.com/id/Connecting-GPS-module-to-Arduino/ this could be the exact thing you want.

Yes, unless it is a gps that requires software to function, this is probably not one of those.  Also you have to deal with voltage levels, 1.8, 3.3, 5.0 and match that to your arduino.  ideally put a scope on this one while running to see what the pinout is, or find markings on it (remove the antenna if possible) and search for that.

But reverse engineering it could be fun…

The short answer is NO, unless you have solid experience with microelectronics.
Finding documentation for a module you take out of a commercial device is hard to impossible. Chances are, that module is specific to Garmin, and even if it isn't, it's certainly EOL by now, with no support whatsoever.
Even if you do find the spec, there is a high chance that you'll have to write a software library to support it on Arduino. Don't expect the supplier to share the code they gave to Garmin.
Finally, to put together and debug this project, you will need quite some equipment:

oscilloscope to debug the electrical interface
soldering station to solder small pins properly

Like people said in comments, this equipment alone will cost much more than a brand-new GPS receiver.

Yes, interfacing with arduino, PC, ESP8266, whatever, easy peasy.  Simple to breakout the serial comms off the Garmin, and whether or not you want to use a logic level shifter (Depending on your RS-232 logic requirements), easy too implement.
I've got a whole bunch of old Garmins (and some new ones) interfaced with some cheapy ESP8266's so I can share the GPS output (All of it.  Not just the x,y,z position data), with multiple devices.
I'd be willing to share the code, wiring if you wish.


text:
ESP8266 (connected to Arduino) only works when plugged into USB power
The Wi-Fi connects when the Arduino is powered by my computer and a serial console is connected, but not if I plug into an outlet.
UPDATE
It seems this is a power issue. I am powering the esp8266 from the Redboard 3.3v line that is only rated for 150mA. I will be switching to the 5v line with a 1A regulator.
I also switched to 9600 baud for communicating with the esp8266, added retries around all of esp8266 commands, and added reconnect logic in case the esp8266 reboots. With the changes, it works okay even with the underpowered 150mA line.
It's still a mystery to me why it works so well when connected to my Macbook.

Another thing to note is that you are likely to run into issues using SoftwareSerial at 115200.  If you need to use SoftwareSerial, best to drop the baud rate.  Depending on your firmware, the AT+IPR=9600 command should work.  If you're getting garbage responses coming through from the ESP8266, this is the likely culprit.

It sounds like your power supply is inadequate to the task.
The ESP8266 is notoriously finicky about having a noise free power supply capable of delivering a lot of instantaneous power. If you are using a wallwart style supply it should promise at least 1A and more is better. Even though the actual use is more like 250 mA.


text:
Advice for checking integrity of serial char strings?
I'm trying to create a flexible but reliable system for arduinos to interact using serial ascii strings.
I'm using a message structure comprised of Command[10] + (optional) Params[20] + (optional) Header[30] + '\0' ( terminator).
Each arduino node looks for incoming serial Commands (plus any appropriate optional Parameters) that it must respond to.
During development and debugging it's sufficient to send Commands and Parameters using the IDE serial monitor without optional Header block or error-checking.
But for interactive node-to-node communications, an optional 'Header' (technically a Footer) block is automatically added to the end of the message.
If an incoming serial message includes a header block, it means that the message was sent automatically from another node (rather than manually from the IDE serial monitor), and consequently the message integrity should be checked against any relevent accompanying header contents, then an acknowledgement returned to the sender if the message was received ok.
Header contents can optionally contain any of the following, and in any order:- s(source)=nnn, d(destination)=nnn, i(id)=nnn, l(msg length)=nnn, and non-critical mixtures of commas and/or spaces can be used as delimters.
To test for message length, the transmitted l=nnn value (text representation) is padded to 3 digits with leading zeros, so the length stays the same whatever the value (eg:.anything from 000 to 999 still requires 3 digits).
So far so good. But although a length test is better than nothing, it doesn't trap for corrupt characters, and the plan is for nodes to communicate via UDP broadcasts, so some form of error-checking and acknowledgement is essential.
So the plan was to (also, or instead) use an optional c(checksum)=nnn in the header, whose value would be the mod sum of everything EXCEPT itself in the header entry. This is easily enough achieved for transmission by taking the mod sum of everything else when assembling the message, then adding the c=modsum on the end (or anywhere in the Header for that matter).
In theory, the receiving end just needs to remove the c=nnn entry (plus any preceding delimter) from wherever it is in the Header, then compare the remaining message's calculated mod sum value against the transmitted c=nnn value.
In practice, I don't know how to exclude the c=nnn entry from the header in order to calculate the remaining modsum, without being forced to accept and pander to unwelcome restrictive assumptions, such as the c=nnn value having to be the final entry, and having to use very strict delimiting.
I'm trying to keep things as flexible and informal as possible, so that other x=nnn type instruction options may be added anywhere to the header if needed without risk of breaking existing rigidity.
Perhaps I should add that this time a year ago I hadn't touched an arduino or C, and that this project has long ago changed from my original automation/security needs to become a goal for providing a simple-to-use interactive arduino distributed functionality cluster system suitable for anyone to use.
The end finally seems to be in sight, which is thanks to the help and advice from you guys (a quick look through my questions shows how far you've brought me), so hopefully your greater experience and wisdom may also be able to offer a more satisfactory integrity-test solution if it is possible.
I would also welcome any other comments that might help me improve on what I'm trying to do.
ADDITIONAL INFO
New incoming serial messages are received in char Buffer[64].
This gets split by delimiters into Command[10], Params[20] and Header[30], but these sizes are only arbitrary first guestimates which may change.
Commands and Parameters can be whatever the node has been programmed to respond to. A trivial 'Blink' example might be a couple of nodes, one looking for incoming "PING" Commands and responding by returning "PONG" Commands, and the other node vice- versa.
A more useful example could be an IR receiver node issuing instructions to a remote IR blaster node, so the "Command+Param+Header" string might be:-
"IRSEND 'NEC 0xFFEEAB99, 32', s=1, d=2, l=044"
The Command/Params parser accepts comma or space as delimiter except if they are contained within quotes. Quotes may be sent inside of quotes of the other type (single or double). Mr T's invaluable Header parser is slightly modified to also accept comma's or spaces as delimiters in the Header, therefore " ,  s=nnn,d=nnn, i=nnn    l=nnn , " all extracts ok.
All of the above is working ok in a very messy and disjointed proof-of-concept form.
    static char buffer[64];
    int msgpos = 0;
    int msglength;
    int quotes=0;
    int parseMode=0;
    bool echo=false;
    bool ack=false;
    byte chksum=0;
    int modchk = 0;

    char command[10];
    char param[20];
    char header[30];
    int snum=0, dnum=0, inum=0, lnum=0, cnum=0;

  void setup()
  {
    Serial.begin(9600);
    Serial.println("Ready");
  }

  int readline(int readch, char *buffer, int len) { //  If a CR terminated ascii string is received, returns string length, else returns -1
    static int pos = 0;
    int rpos;
    if (readch >0) {                               // if a valid ascii character
      msgpos++;
      if (msgpos == 1) resetBuffer();              // First chr, so reset everything to make a new start
      if (!(pos < len-1)) Serial.println("Error: Msg too big for buffer");
      else if ((readch !=10) && (readch != 13)) {
        buffer[pos++] = readch;
        modchk += readch;
        modchk %= 100;
    //  Serial.print("modsum%='"); Serial.print(modchk); Serial.println("'");
        buffer[pos] = 0;
      }  // end if (pos < len-1)
      switch(readch) {
      case 10: break;                                                                             // Ignore new-lines
      case 39: if (quotes==0) quotes=1; else if (quotes==1) quotes=0; else addChr(readch); break; // Turn on or off single-quotes
      case 34: if (quotes==0) quotes=2; else if (quotes==2) quotes=0; else addChr(readch); break; // Turn on or off double-quotes
      case 33: if (quotes==0) parseMode=-1; else addChr(readch); break;                           // ! Header info
      case 32: if ((quotes>0) || (parseMode==-1)) addChr(readch); else parseModeBump(); break;    // space delimiter
      case 44: if ((quotes>0) || (parseMode==-1)) addChr(readch); else parseModeBump(); break;    // comma delim
      case 13:                                                                                // CR stop char
        if (parseMode==0) {Serial.println("Error: blank or corrupt message"); pos=0;  return 0; }
        else if(quotes>0) {Serial.println("Error: open quotes not closed"); pos=0;  return 0; }
        else {// new msg recvd ready for processing. TODO: check if msglength and/or checksum sent, if so and if correct, return ack to sender
          rpos = pos;
          pos = 0;    // Reset position index ready for next time
          return rpos;
        }
        break;
      default:
        addChr(readch);
        break;
      }  // end case
    } // end if (readch >0);
    return -1;        // No end of line CR yet, so return -1.
  }

  void resetBuffer() {
    modchk=0; quotes=0; parseMode=0; command[0]='\0'; param[0]='\0'; header[0]='\0';
    snum=0; dnum=0; inum=0; lnum=0; cnum=0;
  }

  bool parseModeBump() {
    switch (parseMode) {
    case  0: parseMode=1; break;
    case  1: parseMode=2; break;
    case  2: parseMode=-1; break;
    case -1: Serial.println("Error: too many delimited parameters"); return false;
    }
    return true;
  }

  bool addChr(char readch)  {                  //
    char addch[2];
    bool ret=true;
    addch[0]=readch; addch[1]='\0';
    if (parseMode==0) parseMode=1;
    switch (parseMode) {
    case  1: strcat(command,addch); break;
    case  2: strcat(param,addch); break;
    case -1: strcat(header,addch); break;
    default:
      Serial.println("addChr Error: too many delimited parameters"); ret = false;
    }
    return ret;
  }

  void show() {
    Serial.print("SHOW: Command='"); Serial.print(command); Serial.print("'");
    Serial.print(" Parameter='"); Serial.print(param); Serial.print("' ");
    Serial.print(" Header='"); Serial.print(header); Serial.println("'"); Serial.println();
    Serial.print("Msg Length='"); Serial.print(msglength); Serial.println("'");
    if (snum) { Serial.print("snum="); Serial.println(snum); }
    if (dnum) { Serial.print("dnum="); Serial.println(dnum); }
    if (inum) { Serial.print("inum="); Serial.println(inum); }
    if (lnum) { Serial.print("lnum="); Serial.println(lnum); }
    if (cnum) { Serial.print("cnum="); Serial.println(cnum); }
  }

  /*
  bool padzeros() {  // Flawed - redo from scratch using 2 for loop passes
    char lengthstr[4]="7";
    Serial.print("lengthstr='"); Serial.print(lengthstr); Serial.println("'");
    int maxsize=sizeof(lengthstr);  // size of lengthstr array
    int steps=strlen(leng)+1;       // number of chars to be moved
    int hop=maxsize-steps;          // number of steps to be jumped over each move
    if((steps>1)&&(maxsize>steps)) {
      for (int pos=steps-1; pos >= 0; pos--) {
        lengthstr[pos+hop] = lengthstr[pos];
        lengthstr[pos]='0';
      }
    }
    Serial.print("lengthstr='"); Serial.print(lengthstr); Serial.println("'");
  }
  */

  unsigned int calcmodsum(char* s){
    unsigned int i = 0;
    int m=0;
    byte b;
    do { b = s[i]; m += s[i]; i++; }
    while (b != 0); //keep going until null terminator found at end of string
    m %= 100;                   //
    return m;
  }

  int getheader() {      // extract values from header
  //  char header[] = "s=123 d=789 c=463";
    ack=false; echo=false;
    char * ptr = header; // header string pointer
    char * eq = NULL;    // search char (=)
    int * num = NULL;    // empty at start
    int c = 0;
    while (1){
      eq = strchr(ptr, '=');
      ptr = eq;          // update the pointer
      if (ptr == NULL)  break;  // found no '=' chars
      switch (*(ptr - 1)){
        case 'd': num = &dnum; break;
        case 's': num = &snum; break;
        case 'i': num = &inum; break;
        case 'l': num = &lnum; break;
        case 'c': num = &cnum; c=3; break;
        default:  num = NULL;
      }
      ptr++;
      if (num == NULL) //unrecognized var
        continue;      // locate next = char
      *num = 0;
      while (*ptr && (*ptr != ' ') && (*ptr != ',') && isdigit(*ptr)) {  // while valid digit and end of string not yet reached
        *num *= 10;    // extract each int
        *num += *ptr - '0';
        c++;
        ptr++;
      }
    }                  // Now Process any extracted header values
    if (lnum) {
      Serial.print("Msg length="); Serial.print(strlen(buffer)); Serial.println();
      Serial.print("lnum="); Serial.print(lnum); Serial.println();
      if (lnum==strlen(buffer)) Serial.println("* Msg length OK"); else Serial.println("* Incorrect msg length");
    }
    if (cnum) {
      Serial.print("calcmodsum='"); Serial.println(calcmodsum(buffer));
      Serial.print("cnum='"); Serial.print(cnum); Serial.println("'");
      Serial.print("count='"); Serial.print(c); Serial.println("'");
      if (modchk==cnum) Serial.println("* Checksum OK"); else Serial.println("* Incorrect checksum");
    }
  }

  void loop() {
    //  Check for new received serial string
    msglength = readline(Serial.read(), buffer, 64);  // Returns length of new ascii string, or -1 while receiving, or 0 if received msg is corrupt
    if(msglength==0  ) { Serial.println("ERROR: received serial message was invalid and discarded");show(); resetBuffer();}
    else if(msglength > 0) {  // New msg to deal with
      if (header) getheader();
      show();

      msgpos=0;  // reset ready for new msg after finished with last msg
    }
  }

Once I can finalise a satisfactory c=nnn validity test, I shall tidy up this working 'receiver' part and move on to doing the 'sender' part, which I'm hoping should be quite trival in comparison.
I suppose it would be 'proper' to assemble the outgoing message into something like a  char outmsg[64] string, but I'm trying to keep resources minimal to maximise the resources available for the arduino's 'real' functionality, so perhaps it may be better just to send the outgoing msg as consecutive serial chunks, ie:-
Serial.print(Command); Serial.print(Params); Serial.println(Header);
The header will be built up as required. If s=nnn (source) was received it will be assumed that an acknowledgement response is required by the source to prevent it repeating failed transmissions, so the received s=nnn would be used as the outgoing d=nnn destination to respond to - outgoing msgs need only include a source s=nnn if they requires a response back. The i=nnn (msg id) isn't yet used, but could eventually be for re-assembling individual chunks of larger msgs, or keeping track of msg order if multiple msgs are expected.
The l=nnn is a zero-padded count of all transmitted characters (excluding the terminating ), so can be anywhere within the Header string.
It would be preferable if the zero-padded c=nnn checksum could also be anywhere in the Header, but this will require a checksum() calculator function to be able to apply its calculation to all Header characters except the nnn data characters of c=nnn.
As things are, I can jump straight to "c=" wearing blinkers, but that offers no relative position info, so leaves me oblivious of everthing before it.
And I'd prefer not having to split Header[] into seperate Left[] and Right[] chunks which would unnecessarily wastes at least [30+30] chars of memory.
So I think I must sequentially step through all Header characters looking for "=" while applying the mod sum calc to each, except for the 3 following chars when the preceeding char is "c", but I can't quite get my head around how to do that yet.
If the C string functions could return relative string positions instead of absolute * pointers it could all be so much more straightforward.
Does anyone know of any alternative string-relative functions that might be available?

NEW INFO 2 *

Most "Hello world" examples (eg: IRlib) demonstrate functionality using the IDE serial monitor for user interaction. Whatever the functionality, they can all be considered as just a black box capable of recognising a few incoming serial plain-text commands and actioning as appropriate, possibly by also issuing serial text command responses of their own.
The aim of my project is for a user to easily turn that existing and already-proven serial user interaction into an automatic arduino to arduino serial interaction if wished. The headers are just an optional bolt-on for arduino to arduino reliability, but during dev and debugging the various optional header contents will still need to be read and written by users with the IDE serial monitor, which only allows ascii text interaction.
Although this sort of system would not be the preferred solution for experts, it offers much advantage for non-experts. Un-skilled hackers could create effective working solutions without needing to aquire any rocket science first, and without needing to worry too much about resource limitations, or the problems and complexity of trying to consolidate incompatable or conflicting functionality onto any single device.
If they have an arduino that can serially interact, they can use it as an interactive node. If two can interact over serial, then more can serially interact using RS485, or using serial Ethernet UDP slaves (ESP8266's are small and cheap).
Only nodes that 'recognise' an incoming command would respond to it.
A Triggers node could send ascii Alerts such as 'Mailbox Opened', 'Gate1 Visitor', Shed Door Opened' etc.  A Responder node could parse such incoming Alerts to match against entries in a config file, then parse the corresponding config entry for appropriate Response commands to be issued to other cluster nodes, such as 'Mailbox: Announce Mailbox Delivery', or 'Zone2: Announce Zone 2 Activity, CCTV: Select Zone2'.
This would allow new node functionality to be added easily just by updating the Responders appropriate config file entry to include any additional Response commands that become available from any new nodes. So adding an X10 node for instance might offer a new Response command such as 'X10, A12 ON', which only the newly added X10 node would be looking for and respond to.
A cluster system could be evolved into whatever sophisticated functionality was required, with minimal software skills and knowledge. Commands and parameters could be any plain-text names that the user prefers, which when matched during input parsing would branch to any required local function.
Despite any resulting complexity, all individual nodes could still just be considered as relatively simple black boxes capable of recognising a few incoming serial plain-text trigger commands and replying with plain-text responses.
Cluster nodes aren't even limited to being arduinos, because they could include ANY devices capable of receiving and responding to simple ascii command strings. This offers easy gradual progression to other platforms if wished without needing to abandon all existing efforts and start over again from scratch.
I knew I was biting off more than I could chew, but each time I play devils advocate trying to avoid wasting my time going up a dead-end, the more benefits become apparent to make the effort seem worthwhile. The forums are littered with questions and libraries aiming in a similar direction, but I haven't yet found anything which offers that simple black-box plain-text interaction capability, hence my continued struggle. I'm not a programmer so I'll never be able to offer an efficient library solution, but I must try to keep going until I've got something that is usable, and if others find it useful then maybe eventually it might offer incentive for someone to wish to optimise and improve on it.
Hopefully the following should do what I want as far as ignoring "c=nnn" from the mod checksum wherever it finds it.
unsigned int calcmodsum(char* passedstr){     // calculates the mod sum of passedstr excluding the 3 "c=nnn" value digits
  int pos = 0;
  int modsum=0;
  byte b;
  do {
    b = passedstr[pos];
    if ((passedstr[pos]=='c')&&(passedstr[pos+1]=='=')&&(pos>2)) pos=pos+4; else modsum += passedstr[pos]; // skip next 3 digits after finding c=
    pos++;
  }
  while (b != 0); // keep going until null terminator found at end of string
  modsum %= 100;
  return modsum;
}

I dont see any problem with your approach. Checksum values are usually last (or close to last) and this doesnt restrict anything. Provide a sample of a command with parameters and a header. How are the commands and parameters stored in your program? You should also post the part of your code concerned with assembling the commands in a buffer.

I wrote a library for helping with RS485 communications that seems to have most of what you are describing. Variable length messages, and check sums for integrity.

@TisteAndii, I've replied in the ADDITIONAL INFO which has beed added after the original msg.

Would you be willing to try a different approach to sending commands parameters and header values? What if you send numbers instead of strings? It would make TX, RX, and processing easier and also allow for expansion in future. Also reduce size of payload and reduce chances of UDP losses, not to mention more straightforward code.

Thanks @TisteAndii, I've replied again at end of original msg with more info.

Hmm... the length of your question makes it difficult to focus an answer. I'll try by stating my interpretation, then I'll provide a longer answer ;-)

Is there a way to wrap a text message between two Arduinos
    (to increase reliability), but would still
      allow me to do testing without the wrapper?

If I assume that's what you're asking, then the above comments have touched on various aspects of an answer: "Yes."
Let's progress through my interpretation:

"Text" means ASCII values between 32 and 126 (SP and '~', the printable characters).
"Wrapping a message" means sending some bytes before and possibly after the text.
"Increasing reliability" means detecting and/or correcting characters that get corrupted.
"Testing without the wrapper" means that you would like to use the Serial Monitor to send example commands while you're in a noise-free environment, testing the logic of the command execution, not the mechanism of communicating reliably.

Wrapping
You're on the right path by prefixing the text with a binary header, and Nick's library shows how to use a "special" start and end byte to delimit the messages.  (This is also called message "framing".)  If the START byte can appear inside the message elsewhere, you will need to either (1) "escape" the START byte when it appears inside the message, (2) provide a second method of verifying that the message is framed correctly (e.g., an END byte and/or a length), or (3) decrease the odds of a false start by using a multiple-byte START sequence.
You appear to have chosen (2).  You are free to chose the bytes that follow the START byte.  Addressing, sequence number and message type are common.  Of course, the message length is in there somewhere.
Reliability.
If you're happy to simply detect an error at the receiving end, a checksum is sufficient.  I'd like to suggest the Fletcher checksum, as it is simple, quick and fairly robust.  CRCs are more robust, but a little more expensive to compute.
But because they are calculated over the rest of the message (the "payload"), they almost always appear at the end, before any END sequence.  This also makes it easier for the receiver, because it can accumulate the checksum as the bytes are received, and reject the message if the received checksum does not match the calculated checksum.
You can also use error detection to help with acknowledgements, if you decide to implement them.  An alternative to ACK/NAK messages is to request the current state (a poll command), expecting that it should reflect the previous (unacknowledged) command.  If the state doesn't match, send the command again.
If you also want to perform error correction, there are numerous ways to add that.  All of them will increase the size of the message, as well as the CPU time.  (Sorry, Nick, but sending complemented nybbles is not a very robust detection scheme, and it doubles the message size without adding correction capability.)
Testing without the wrapper
You could use CR/LF as your message framing and assume that anything after CR/LF is the start of an unwrapped message.  If it starts unwrapped, set a bool flag that skips the checksum part and END byte.
Final notes
Your current program is structured to hold the complete message in RAM for processing (sent or received).  This is not always feasible in the Arduino environment.  You don't put all the print chars in a buffer, then do one big Serial.print( buffer ), do you?
Just like breaking a Serial.print into several smaller prints, reception can be performed the same way.  You can watch for keywords, or accumulate parameter values without buffering the entire message.  While it saves a lot of RAM, it also saves CPU time because each received character is handled once.  With a buffered approach, each character is handled multiple times: read() into a buffer, then compared during a search, and maybe parsed.
One of my recent posts has some general structure information, snipped a little for here:

Reading data on the Arduino is different from most PC applications.  Calling Serial.read() does not always return data.  Well, it returns -1 (or 0xFF) if no characters are available.  In a PC app, calling read will usually wait until a data has been received: the PC app is "blocked" until a character comes in.  That's not very noticeable because the PC has a nice multitasking OS so your pointer keeps moving and other windows respond, even though the one app is waiting for a character.
On the Arduino, you can make it block the same way, but there's no OS that will let you do something else while you're waiting for data (yes, there are multitasking solutions, but let's avoid that for now).  So blocking on the Arduino can keep you from doing other things you may need to do, like blinking an LED or catching a button press.
There are a few common ways to write an Arduino sketch that can cope with this speed disparity:
1) Force the Arduino to wait for each character (i.e., block), and write the sketch in a very linear, top-to-bottom fashion:
while (Serial1.available() == 0)
  ; // wait
  inByte1 = Serial1.read();

  if (inByte1 == 0x3E){ // START byte
    buffer[0] = inByte1;

    while (Serial1.available() == 0)
      ; // wait
    inByte1 = Serial1.read();

    if (inByte1 == 0x03){

2) Save each character in a buffer as it arrives until you have received an entire packet.  Then parse the packet all at once with similar linear code:
static uint8_t count = 0; // keeps its value across calls to loop

if (Serial1.available()) {
  inByte1 = Serial1.read();

  if (inByte1 == 0x3E) { // START character

    // Next packet starting, process the current one we've been saving,
    //   if we have saved enough bytes (skips small/bad packets).

    if ((count > 6) && (buffer[0] == 0x3E)) {

      // SNIP: handle previous packet

    }

    // Reset the count to start a new packet with the 0x3E we just received.
    count = 0;
  }

  // Save the current byte
  if (count < sizeof(buffer))
    buffer[ count ] = inByte1;
  count++;
}

3) Parse each character as it arrives, picking up where you left off after doing other things.
void loop()
    {
        // statics keep values across calls to loop
        static uint8_t count         = 0;
        static bool    skipping      = true;
        static uint8_t messageLength = 0;
  if (Serial1.available()) { // or 'while'

      uint8_t inByte = Serial1.read();

      if (inByte == 0x3E) { // START  byte

          // Starting a new packet!

          buffer[0] = inByte;
          count    = 1;
          skipping = false;

      } else if (!skipping) {

          // Saving a packet, store the current byte

          if (count < sizeof(buffer))
            buffer[ count ] = inByte;

          // Use the current byte, depending on 'count'
          switch (count) {
            case 1:
              if (inByte != 0x03)
                skipping = true; // ignore other packet selector values
              break;

            case 2:
              messageLength = inByte;
              // Error check?
              if (messageLength != 40)
                skipping = true;
              break;

            case 3:
              // packetID = inByte; ?
              buffer[3] = inByte;
              break;

            case SNIPPED: other header information fields
            case SNIPPED: accumulate/parse payload
            case SNIPPED: verify checksum (ignore packet or execute packet)
         }

         count++;
     }
 }

 // Do other things, too?

}
Choice 1 is very linear.  The disadvantage is that it blocks and does not recover from data errors very well.
Choice 2 is pretty easy to understand and it doesn't block; other tasks can do things while waiting for a complete packet.  The disadvantage is that all the packet processing happens when the last byte is received (actually, the first byte of the next packet in that code).
Choice 3 is more difficult to understand, because the entire section is executed for each character, either starting a new packet or using the switch statement to handle each char.  Different cases do a little work, depending on the count.  The advantage is that the processing is spread out over each character, and you can decide to skip the rest of a packet at any point.

This is actually a Finite-State machine approach, and Nick Gammon has a great description, too.

Thanks for some good info and links @slash-dev, it has helped clarify some previously vaque suspicions and intuitions.   I may even try implementing a swapout f=oxAABBCCDD fletcher checksum version for increased reliability once everything else is working.

@Electroguard, I was nervous that I didn't understand your question.  That Fletcher code is dead simple.  Slip me some o' that green checkmark by my answer?  Thanks!


text:
Combining 2 State Machines?
I want to gain from recent advice from this forum by re-doing my project using 'state machine' logic if possible, in an effort to reduce wasted processor time and variables usage.
I'm starting from Nick Gammons 'state machine to process input from the serial port' example http://www.gammon.com.au/statemachine, which shows all the different possible combinations for all the special control character 'events' against all the possible machine states - essentially a 2-dimensional grid.
I've refined my goal to the processing of serial input in a format of "command  [parameters]  [options]", similar to a DOS command-line format, eg:  DIR  "c:\program files"  /w /s. This would free me from needing large Buffer[] and Header[] string, and avoides any parsing,
Therefore my event control characters are space, comma, single-quote, double-quote, forward-slash, Carraige Return, and my 'states' are NULL, COMMAND, PARAMETER, OPTIONS
The OPTIONS state adds characters to a temporary option[] string until a comma or space delimiter or Carraige Return causes that option to be processed as appropriate, perhaps saving its value to a recognised variable.
The COMMAND and PARAMETER 'states' add characters to their corresponding command[] and parameters[] strings, including the special control characters if they are contained within either single or double quotes (thereby allowing quotes as part of a string if used within a pair of the other type).
So there appears to be a second state machine needed for NoQuotes, SingleQuotes and DoubleQuotes to modify the operation of the COMMAND, PARAMETER and OPTIONS states.
This is where I run out of neurons, because all I see is an impossibly complex 2-machine-state 3-dimensional grid with too many possible permutations.
But I suspect there must be a very practical way to implement this, because it lies at the heart of almost all command-line utilities dating back to a time when processor power and memory availability were scarcer than hens teeth, and those old DOS command-line utilities needed to be as mimimal as was possible, including their command-line parsing.
So can anybody suggest a feasible model (machine-state or otherwise) for getting command-line type format from input?
UPDATE
Oh dear... I've just seen another complication I hadn't spotted before, which is that '/' options are not necessarily always at the end, which means that except if the options state changes by carraige-return, options state change by delimiter have to return to the state prior to the options state change (phew, I hope that makes some sense).  Anyway, I think it's back to drawing board because this approach seems likely to be too complicated, as the 2 answers already suggest.

The common way of handing interacting states is to expand the interactions into their own state.  i.e. PARAMETER vs SingleQuotes_PARAMETER DoubleQuotes_PARAMETER, where their processing could share much the same code.    See https://github.com/Traumflug/Teacup_Firmware/blob/master/gcode_parse.c for an big example.   Also, this is too broad (you don't have a syntax for us to use) and is really off topic for an Arduino-focused forum.

Another way to think of it as a state  machine is that your state space is a many-dimensional vector of state variables, with a {COMMAND, PARAMETER[],OPTIONS[],etc...)

The question is very much Arduino because I wish to read incoming serial and 'sort' it into command plus optional parameter plus optional control-options, therefore mention of DOS command-line was merely giving a syntax example of the required serial format.

Some sort of general DOS syntax, or the much more limited syntax for a particular command?  With a particular command, there are only a limited number of parameters and options, and your /parser/ state machine can sort them out into their /process/ state variables somewhat like Teacup does.

It's for whatever local 'commands' and 'parameters the arduino is programmed tolook for in  incoming serial, eg: 'LED1 ON', or 'IRSEND "NEC 0xFFEE9123 32".
The options are for optional arduino-to-arduino sending of control info, such as /c(hecksum)=nnn,  /l(ength)=nnn, /s(ource)=nnn etc.     The idea is to read incoming serial a byte at a time and send to command or params or options on the fly, rather than needing to parse an additional large buffer string after.

I would think you can't dispatch the command until the last character of the last option is parsed--so the COMMAND, PARAMETERS, and OPTIONS must all be merely a vector of parameters for the next stage of processing.  You need to collect them all before moving on.  Is the 'LED1' in 'LED1 ON' a command?  ///  For your updated Q, the '\n' changes the state of the system from parsing bytes into the cleaning up the parameter state and executing a command state/oneshot, for example https://github.com/Traumflug/Teacup_Firmware/blob/master/gcode_parse.c#L362 to #390.

Personally I don't think Nick advised to do command line pattern parsing with a state machine. His example is about changing a state machine based on command line input.
I have written some command line parsers and I never used a state machine to do so. I would not advice to use a state machine to do so.
Simple string parsing is far easier.
Edit To answer the remark below:
I would not advice to go byte by byte. I'd advice to go the line by line way.
I have written a library to do read line by line and an article on how that one works. http://blog.baeyens.it/#post16
Here a link to the lib https://github.com/jantje/libraries/tree/master/SerialCommunicator.
Here is a parcing code example. It is not so interesting for you as I have it done in a stage by stage way in a very high level way of coding.
https://github.com/jantje/libraries/blob/master/SerialBridgeCommunicator/SerialBridgeCommunicator.cpp#L21
Basically the algorithm is=
1 Take the first word;
2 identify the word.
3 If the command is complete ->do it
 else Send the rest of the string to a specialized piece of code. (which has the same algorithm)

I thought my needs were the same as Nicks example - to read incoming serial a byte at a time and send to command or params or options on the fly then action them as appropriate after reading a carraige-return, rather than then needing to parse an additional large buffer string after.  But no point me shooting for the moon - you mentioned doing command line parser previously... would you happen to have a suitable flowchart or algorithm?

I would not advice to go byte by byte. I'd advice to go the line by line way.

Suggestion: - don't try to "moosh" (that's a technical-term!) the state-machine heirarchy down into one large, flat state-machine. That way lies madness. Keep your { NULL, COMMAND, PARAMETER, OPTIONS } state machine, for instance, and, wherever you need something more than simple string collection in one of those states, call a parser SM appropriate to the kind(s) of input you expect at that point - a number, a quoted string, an option specifier, etc.

I think I understand (probably too late to avoid madness though cos I think the state machine may have already 'mooshed' my head).  As you say, use NULL, COMMAND, PARAMETER as the states to change through. And even though NoQuotes, SingleQuotes, Double-Quotes and possibly Options might justify a state machine themselves, best just to treat them as separate processes within the main state machine.

You might also consider as a mid-point, a universal parser that can handle various input types, but separate from the main SM. You'll know best, once you quick sketch up a couple of SM hierarchies (that's 'sketch' as in 'circles and arrows', not as in 'coding').