text:
How can I seriously calibrate ADC voltage readings with Arduino Nano?
I have been using Arduino Nano Analog input to measure voltages, in the range between 22-30 Volts.
I want to measure it down to a tenth of a volt.
Following the instructions found here:
Read Analog Voltage (www.arduino.cc)
Which basically states that all I need is this code:
int sensorValue = analogRead(A0);
float voltage= sensorValue * (5.0 / 1023.0);

5.0/1023 = 0.004888 volts per increment in analog readings.  Turning that around, voltage input divided by this value should give me the sensor value.
Clearly they are presuming an input of 0-5 Volts.
My voltage divider is 1 Mohm (R1) between the voltage input and A2, then 200K (R2) from A2 to ground
30 Volts measures as 4.2 Volts.  22 Volts measures as 3.1 Volts.
I think the range between 22 volts and 30 Volts doesn't present enough variation to the ADC - every single-digit change in the analogRead really make a big difference.
The result is that it is giving me some crazy readings.  It is definitely nonlinear, so I am having real trouble trying to get it to be accurate at both ends of my measurement range.  Each slight ADC increment makes too much of a difference in the measured voltage because I am not using the full 0-5V input range.
So I have been taking 10 readings in a row, at 500 ms intervals, then averaging.
And yet it is not working well enough.
(The biggest problem was the reference voltage and resolution were assumed to be 5/1024 which is completely incorrect.  Unless, as someone pointed out, I fed the Nanos directly at the 5V pin - which is still on the table - then it would be 5/1023)
I changed my resistor network to be 147K/23.5K
(Parts list:  1x 100K, 3x 47K)
R1 = 47K / 47K = 23.5K
R2 = 100K + 47K = 147K
Also added a 100uF 50V electrolytic across the input from the battery bank I am monitoring.
I am feeding 5V to Vin.  And have figured out that the reference is measurable on the 5V pin, after the regulator, as 4.6V.
Knowing that
Resolution/Vref = ADC/Vin
I turned that around to be
Vin = ADC * (Vref/Resolution)
Or, Vin = A2 * (4.6/1023)
Using a laboratory power supply I was able to confirm that with those settings 22 Volts came in at 3 Volts, and 29.98 came in right at 4 Volts.
So
Vbat = A2 * (4.6/1023) / (R2/(R1+R2))
Vbat = A2 * (4.6/1023.0)/(147000/170500)
It is now operating reasonably well.

(Yellow means the inverter is on)
--UPDATE--
  Changed resistors to 100K/20K for the divider and brought power to the 5V pin, bypassing the regulator for a reference.  It measures at 5.02 and is stable.
Results:
Charge controller meter says I am at 24.5 Volts.
Program says 24.64  (in the serial monitor).

--ADDENDUM:  I want to pursue the Op-Amp setup.  But if 741 won't work will need a suggestion.

Similarly, I went to 147K/47K for the 11-15 Volt circuit, and moved a higher-quality P/S over to the 5V pin, where it measures 5.03V; the results are better there, too. Just very slightly high.

So anyway, I'll put this to rest until I can figure out an op-amp circuit.
Thank you all for your help

You asked the question twice without a link to the other one, now we are answering to both without knowing each other answers. https://electronics.stackexchange.com/questions/307586/need-help-calibrating-adc-input-using-a-voltage-divider

If your power supply is 5volt you should connect it to Vcc directly, instead of Vin. If you connect to vin it first goes through the regulator, lowering the voltage.

Hello @Gerben.  By Vcc I assume you mean the 5V terminal.  I thought about that but since the Nano connects to a Pi I didn't feel safe having it unregulated.  The power supply is at least 5V, and no more than 5.1, and is regulated well enough for the Nano, for sure.  But I don't think it would be useful as the reference since it might wander some.  I am more comfortable trusting the regulator, especially since there have been Pi meltdowns at 5.15.

The nano can handle up to 6V. Giving a regulator too low a voltage makes it unable to regulate, and the voltage will flunctiate bases once the load. This fluctuation will also affect the ADC.

In my opinion, this is a very Arduino specific question.
First of all, you can't map 22-30V to 0-4.4V with a voltage divider (unless you have a negative voltage available). A opamp introduces a little more inaccuracy but can map the voltage which increases the accuracy. I suggest to first get the maximum out of the voltage divider. If that is not enough, then you can try a opamp.
The impedance of the circuit at a analog pin should be 10k or less for a accurate ADC conversion. You can add a small capacitor (1nF to 100nF) from the analog pin to GND, to keep the value stable during the ADC conversion.
The 5V VCC as a reference is a pain. The best option is to use an external voltage reference, for example a LM4040. The second best option is the internal voltage reference of 1.1V. That voltage is never 1.1V, and you have to determine the actual voltage. That 1.1V also depends on the temperature and a little on VCC.
Only 10 readings for an average is a small number. Sometimes I use 5, sometimes I use thousands.
Is the Arduino Nano used indoors, with only a small variation in temperature ? Then select the analogReference(INTERNAL). Use for example 10k and 270k for the voltage divider and 10nF parallel with the 10k. Use the average of 100 samples. An accuracy to measure the 24-30V with 0.1V resolution should be easy to achieve and 50mV resolution should be possible.
If you prefer the 1M to measure the voltage, you can also use 1M and 33k. With the 10nF parallel to the 33k, the ADC conversion is probably still accurate enough.
[ADDED] You have not told us yet how accurate you want to read the battery voltage. Is ±500mV okay, or must you have ±20mV ? I say it again: 0.1V resolution is easy. But it all depends on a good reference. A bad reference means even worse results. Dit you take a look at analogReference to see what the INTERNAL reference is about ?

The internal reference may even have better stability. Similar products using (I assume) the same or similar reference have temperature coefficients of 90 ppm or less.

Yes, you are right. The LM4040 that I mentioned is not the best. I prefer a good overall absolute accuracy, so it can be used right out of the box. The bandgap voltage of the reference of the ATmega328p can be 1.0 to 1.2 volts. With a lot of tuning and averaging it is still very useful.

You are right that it turned out to be a very specific-to-Arduino question after all.  It is inside.  Resolution can be within a tenth of a volt, or so.  Yes I looked at the reference and like the DEFAULT - 5V pin is a great touch point to verify it.  You said you sometimes take thousands - what interval can I use for the ADC to settle down in between readings if I wanted to take 100?

For normal noise reduction I don't use a delay at all. Just a for-loop with analogRead. Only when trying to eliminate the 50Hz or 60Hz mains noise, a delay might be needed.

I have .1uF in both ceramic and electrolytic. Also can build a 1147000/47000 divider with 1% parts to get 1.81 volts from 30.  Building it now.

Well I'll be a monkey's uncle.  Ref is measuring 1.04, and the capacitor is 0.1uF electrolytic.  Taking readings every second and they are as close as they can be.  24.8V is feeding 0.92 volts into A2.    After the math I am getting mostly 24.77, with some wandering - like from 24.5-24.9.  I think if I take 10 samples and average it will work.

So tomorrow we'll see how it does when the sun is out and it goes up to 29.2 - If it keeps working this well I'll duplicate this on the production system (which  is a lot more elaborate:  It includes undervolt protection relays and battery disconnects for inverter shutoff and automatic power switching back to house power from inverter)  Thank you VERY much, @Jot.

I just caught @Edgar's comment that the output resistance should be under 10K.  That probably explains the wandering.  Right now it only takes a single reading every minute so we'll just see how it goes.  Making that happen would require a two-stage voltage divider.

Rather than mapping to a range of 0 to 4.4 V, map to the range 0 to 1.1 V and use analogReference(INTERNAL) to select the internal band-gap 1.1 V reference source.  This reference voltage might vary a small amount as Vcc varies, but the variation is likely to be just a few millivolts.
To get your input voltage into the range  0 to 1.1 V, use a voltage divider and a voltage subtractor.  The voltage divider ratio should map the 8-volt range of 22 to 30 V to a 1.1 V range, ie, should have a ratio of 8:1.1, and should map 30 V to 4.125 V and 22 V to 3.025 V.
If you use a Unity Gain Differential Amplifier as described at electronics-tutorials.ws, the divider can use large resistors, ie, need not provide the under-10 KΩ resistance needed for ADC input; instead, the UGDA's low output impedance will meet that requirement when used as ADC input.  For example, you could have 1 MΩ in series with 160 KΩ for the main divider.
Feed that divided voltage into V1 in the diagram below.  Use a pot or another voltage divider to create a 3.025 V reference to feed into V2, perhaps based on the board's 3.3 V regulator output.
Note, use R1 = R2 = R3 = R4, with all of them some value like 10 KΩ or 20 KΩ.

Similar products using (I assume) a similar band-gap voltage reference have temperature coefficients of less than 90 ppm so the band-gap reference is probably the most accurate reference at hand.

I hadnt heard of that.

Changed resistors to 100K/20K for the divider

you probably want to read the datasheet about the impedance requirement on the source and potential solutions there.

Thank you for your answers and there is a lot of collective knowledge there.  It helped me find the way to stabilize and calibrate this system with what I had on hand.  The biggest problem was that the reference voltage and resolution were 5/1024, which is completely incorrect.
I changed my resistor network to be 147K/23.5K  (Parts list:  1x 100K, 3x 47K)
Also added a 100uF 50V electrolytic across the input from the battery bank I am monitoring.
I am feeding 5V to Vin.  And have figured out that the reference it is using is measurable on the 5V pin.
Knowing that Resolution / Vref = ADC reading / Vin, I turned that around to be Vin = ADC * Vref / Resolution.
(Can someone please edit that previous line so the equations look right?
I found out that the proper resolution is 1023, not 1024
Then by measuring the 5V pin I found 4.6 from the 12v-to-5v converter going through the regulator.  The 12 Volts is battery-backed and is very stable.
Vin = A2 * (4.6 / 1023)
Using a laboratory power supply I was able to confirm that with those settings 22 Volts came in at 3 Volts, and 29.98 came in right at 4 Volts.
Then I divided the Vin by (R2/R1+R2) to get the Vbat reading
Vbat = A2 * (4.6/1023) / (R2/(R1+R2))
Vbat = A2 * (4.6/1023.0)/(147000/170500)
You can see it better at
https://electronics.stackexchange.com/questions/307586/need-help-calibrating-adc-input-using-a-voltage-divider/307643#307643
It is now operating reasonably well.

(Yellow means the inverter is on)
Next step is to try 100K/20K for the divider and bring in 5V to the 5V pin, bypassing the regulator.
I want to pursue the Op-Amp setup.  But if 741 won't work will need a suggestion.  This setup I have been asking for measures a 500Ah 24 Volt deep-cycle Marine battery bank being charged by 6x 100W poly PV panels with a single-axis positioning system.
I now also need to measure exactly half the voltage, 11-15, for the positioning circuitry that has its own battery and dedicated 50 Watt panel to run the computer and motors.  The regulated 5V out there is el-cheapo but I now have the parts on hand to give it better 5V just like I have in here with the storage bank.  Should be able to finish that part today after church.   I expect the ADC will see half the voltage.  Instead of 3-4 Volts it should see 1.5-2 Volts.
Terrible loss of precision.  I really want both systems to see 0-4 Volts at the ADC.
So my question is still the same.  I think the answer is here.

Note that your resistance network has an equivalent output resistance of 20.3 kΩ, which is above the maximum recommended at an ADC input (10 kΩ). Note also that the ADC gain is 1024/Vref according to the manufacturer's datasheet. I measured it recently on an ATmega328P and found it to be more like 1026.1/Vref.

The 4.6V can not be a good reference voltage. Use the internal 1.1V.

https://meta.stackexchange.com/questions/216606/which-stack-exchange-sites-use-mathjax/216607#216607

OK, @Jot.  I am still getting nonlinear readings.  Up near 29.2 volts Boost charge it is OK, but it reads a bit high at 27.6 Float, then low near 25 Dark.  I am using a meter to calibrate the 5V terminal in the V/1023 part of the equation.  The supply voltage is stable, with about 50 Ah of battery behind it - it is not load-dependant.  The main battery bank being measured is  500 Ah of battery plus 600W solar (degraded by temps, of course)  and an MPPT controller.  I see how to set it to INTERNAL but do not know how to code for it.  Do I just use 5/1023 if I set it to INTERNAL?

Also, I am asking myself why I am using the 5V pin instead of AREF and EXTERNAL.  While I would love to use an op-amp to spread out the range, right now I am stuck with 3-4 Volts to represent 20-30 Volts, using 100K/20K as my divider.

I already had a link in my answer: https://www.arduino.cc/en/Reference/AnalogReference Select the INTERNAL and adjust the voltage divider for the lower voltage. You have to measure the actual voltage for each Arduino board that uses it, since it can be between 1.0 and 1.2 volt. Select INTERNAL and measure the AREF pin with a multimeter. Put that voltage in the calculation. The calculation uses 1.1V instead of 5V: float voltageAtPin = float( analogRead(A0)) * 1.1 / 1024.0 Keep in mind that trying to get a full range with many components might be less accurate then settling with a lower range.

Turns out @Jot was absolutely correct.  See the comments under his answer for the right way to do this.  analogReference(INTERNAL) and a voltage divider that brings 30 Volts down to 0-1.2 volts (1147000/47000)  with a .1uF Electrolytic across the input.  Run it once to set it up, then  measure REF for use in the Vref/1024 portion of the equation.  It works great.  The only glitch is that the very first reading is wrong, so I put three analogReads into setup, since my Rpi program resets the Nano as it begins recording readings.

Use a ceramic capacitor. A electrolytic or tantalum capacitor leaks, and make the voltage divider useless.


text:
Can I upload with avrdude 2 hexes with 2 usbasp connected to computer, one hex with one usbasp ? If yes, how?
If I have connected 2 usbasps in the same time to ubuntu, can I upload 2 hexes one after the other(using avrdude) on each usbasp without disconnecting a usbasp ? If yes, how do I select each port for each hex ?

Can you please edit your question and add a little background on what you are trying to achieve. Also, how is this related to Arduino??

https://electronics.stackexchange.com/questions/130984/can-avrdude-address-individual-usbtiny-programmers

source: Stack Exchange

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

sort: votes


text:
Stepper motor control
I'm using Arduino to control a stepper motor. I need it to make one revolution and then stop. I'm new to this and haven't ran it yet. Will this do for me?
#include <Stepper.h>

const int stepsPerRevolution = 200;

Stepper myStepper(stepsPerRevolution, 8, 9, 10, 11);

void setup() {
  myStepper.setSpeed(60);
}

void loop() {
  myStepper.step(stepsPerRevolution);
}

No, that will not do what you want. That will continuously rotate the stepper round and round and round.
The clue as to why is in the name of the function you put the myStepper.step call: "loop". That function repeatedly loops around over and over again, so your step function will be called over and over again.
There is one piece of information lacking from your thinking at the moment, and that is when do you want the stepper to rotate? If it's just once when you turn the power on then it's as simple as doing everything (including calling myStepper.step) in setup() and leaving loop() empty. If not, then you will need to add appropriate logic to only run the step function when the required conditions are met.

what if I want it to make just 10 revolutions and then stop.

The same way as for 1 revolution but with 10x the steps?

Yes, though another option is to put a for loop around the step command.  For a few rotations just multiplying the count works, but the count argument appears to be limited to +32767 or -32768 (on an ATmega)

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


text:
How many and fast interrupt pin can handle in Uno?
So I am using Arduino UNO to do phase cutting and read Fan RPM.
For phase cutting, every half frequency it will triggers interrupts and then arduino will triggers TRIAC. Half frequency(50Hz) is 20ms. And for reading rpm, my fan running at 950rpm or 15.83rps, or doing a revolution for 63ms.
I think both of that works is doing a fast work, and I am afraid if I do it simultaneously the arduino will get an error(like a skip on one half wave, or a skip on reading one revolution), or will it not? Thanks.

You are talking about tens of milliseconds, ages at the scale of the MCU. Unless you do silly things in the ISR, your Arduino should have no problem keeping with that pace.

If you are having problems (which is unlikely), you could use the RPM output as a clock input for timer1. That way the hardware wil count the revolutions for you. You can than add an interrupt for when the counter get to a certain value, and do some calculations based on that. That way you'd have a lot fewer interrupts.

Let's do some math here.
UNO works at a 16 MHz clock rate. That's a clock cycle every 62.5 nanoseconds, or 16.000 cycles every millisecond. That means plenty of processing power within 20 millisecond, if used wisely (i.e., avoiding processing-intensive functions).
Conclusion: you shouldn't find any major problem if you do a good work with your code. Just keep things simple and don't go through the roof with what you intend to do each 20 ms.

If two interrupts happen at the same time they will both execute in the numerical order of their INT number (INT 0 will trigger before INT 1). But they will both execute - just one will be a little delayed.
If one interrupt occurs whilst the other is executing the second interrupt will trigger once the first has finished.
As long as both your interrupt routines combined take less than the time than the time between triggerings of the most rapid interrupt you won't get any issues.

You can find the number of external interrupt and pcint pins from the data sheet.
If you use interrupts, the overhead is about 20 or so ticks, or just over 1us. That gives you the minimum.
If polling, and you are lucky, 1 tick is all it takes. 1 /16th of a us.


text:
Odd RGB matrix behavior while using shift registers
so I'm playing around with an 8x8 RGB matrix using a 74HC595 shift register for each of the colors. I've done this before with single color matrices and everything worked fine, but here I'm getting some weir behavior that I can't really understand.
All 3 74HC595's are wired identically:
MR - 5v,
OE - Ground,
VCC - 5v,
GND - Ground
Latch and clock are shared between the registers.
The result:

This is not how it should look, do I have a timing issue somewhere? Thanks in advance!
The code:
int clock_pin = 3; // SH_CP
int latch_pin = 4; // ST_CP

int r_data_pin = 2;  // DS
int g_data_pin = A0;
int b_data_pin = A1;

int row1 = 5;
int row2 = 6;
int row3 = 7;
int row4 = 8;
int row5 = 9;
int row6 = 10;
int row7 = 11;
int row8 = 12;

const int row_count = 8;
const int col_count = 8;

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

  pinMode(row1, OUTPUT);
  pinMode(row2, OUTPUT);
  pinMode(row3, OUTPUT);
  pinMode(row4, OUTPUT);
  pinMode(row5, OUTPUT);
  pinMode(row6, OUTPUT);
  pinMode(row7, OUTPUT);
  pinMode(row8, OUTPUT);

  pinMode(clock_pin, OUTPUT);
  pinMode(latch_pin, OUTPUT);

  pinMode(r_data_pin, OUTPUT);
  pinMode(g_data_pin, OUTPUT);
  pinMode(b_data_pin, OUTPUT);

  digitalWrite(latch_pin, HIGH);
  digitalWrite(clock_pin, HIGH);

  digitalWrite(r_data_pin, HIGH);
  digitalWrite(g_data_pin, HIGH);
  digitalWrite(b_data_pin, HIGH);
}

namespace RGB {

typedef struct pixel {
  byte r;
  byte g;
  byte b;
};

}

int r_data[8][8] = {
  {0, 1, 1, 0, 0, 1, 1, 0},
  {1, 1, 1, 1, 1, 1, 1, 1},
  {1, 1, 1, 1, 1, 1, 1, 1},
  {0, 1, 1, 0, 0, 1, 1, 0},
  {0, 1, 1, 0, 0, 1, 1, 0},
  {1, 1, 1, 1, 1, 1, 1, 1},
  {1, 1, 1, 1, 1, 1, 1, 1},
  {0, 1, 1, 0, 0, 1, 1, 0}
};

int g_data[8][8] = {
  {0, 1, 1, 0, 0, 1, 1, 0},
  {1, 1, 1, 1, 1, 1, 1, 1},
  {1, 1, 1, 1, 1, 1, 1, 1},
  {0, 1, 1, 0, 0, 1, 1, 0},
  {0, 1, 1, 0, 0, 1, 1, 0},
  {1, 1, 1, 1, 1, 1, 1, 1},
  {1, 1, 1, 1, 1, 1, 1, 1},
  {0, 1, 1, 0, 0, 1, 1, 0}
};

int b_data[8][8] = {
  {0, 1, 1, 0, 0, 1, 1, 0},
  {1, 1, 1, 1, 1, 1, 1, 1},
  {1, 1, 1, 1, 1, 1, 1, 1},
  {0, 1, 1, 0, 0, 1, 1, 0},
  {0, 1, 1, 0, 0, 1, 1, 0},
  {1, 1, 1, 1, 1, 1, 1, 1},
  {1, 1, 1, 1, 1, 1, 1, 1},
  {0, 1, 1, 0, 0, 1, 1, 0}
};

void loop() {
  for (int row = 0; row < 8; row++) {
    digitalWrite(latch_pin, LOW);

    if (row == 0) digitalWrite(row1, HIGH);
    if (row == 1) digitalWrite(row2, HIGH);
    if (row == 2) digitalWrite(row3, HIGH);
    if (row == 3) digitalWrite(row4, HIGH);
    if (row == 4) digitalWrite(row5, HIGH);
    if (row == 5) digitalWrite(row6, HIGH);
    if (row == 6) digitalWrite(row7, HIGH);
    if (row == 7) digitalWrite(row8, HIGH);

    for (int i = 0; i < 8; i++) {
      digitalWrite(clock_pin, LOW);

      digitalWrite(r_data_pin, r_data[row][i]);
      digitalWrite(g_data_pin, g_data[row][i]);
      digitalWrite(b_data_pin, b_data[row][i]);

      digitalWrite(clock_pin, HIGH);
    }
    delay(1);
    if (row == 0) digitalWrite(row1, LOW);
    if (row == 1) digitalWrite(row2, LOW);
    if (row == 2) digitalWrite(row3, LOW);
    if (row == 3) digitalWrite(row4, LOW);
    if (row == 4) digitalWrite(row5, LOW);
    if (row == 5) digitalWrite(row6, LOW);
    if (row == 6) digitalWrite(row7, LOW);
    if (row == 7) digitalWrite(row8, LOW);
    digitalWrite(latch_pin, HIGH);
  }
}

Same hardware & software as before when it worked?  Just different display using 3 times the number of LEDs (Red, Green & Blue) to make white colored light?  I would first check the power supply to see if it can handle the new load with out dropping the voltage and causing all kinds of problems with the processor and peripheral logic.

@st2000 The arduino is powering everything, how can I use a separate power supply?

You should be able to power the Arduino separately from the 74HC595 (which are assumed to be driving the LEDs) if you connect the grounds of the two power sources together and the two power sources are of the same voltage.  However, it would be simpler to use a single power source with about twice the current capacity that you would expect to draw.  Other considerations: If you are using the Arduino's on board 5 volt regulator you need to stay under the upper current capacity of that regulator.  Again, this is assuming the problems you are having are related to a weak power source.

With out changing any hardware, consider changing the software to only light 1 or 2 LEDs to see if the Arduino acts as expected when using a smaller amount of current to light less LEDs.

@st2000 Figured out how to use an external power supply, sadly it's only 3.3V, tried to use it but I still get an incorrect "image". I have not added no resistors for the LED's, maybe I should? I get some minor flicker in LED's which should not light up.


text:
Drawing bitmap on TFT
So, my .ino file is like this (do not worry about TftDisplay library, it totally works fine and myDrawPixel function just calls the adafruit drawPixel function):
#include "TftDisplay.h"
#include <avr/pgmspace.h>

TftDisplay tft;

const uint8_t myBitmapBitmap [] = {
  0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
  0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
  0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
  0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
  0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
  0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
  0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
  0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
  0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
  0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
  0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
  0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
  0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
  0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
  0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
  0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
  0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
  0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
  0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
  0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
  0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
  0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
  0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
  0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
  0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
  0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
  0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
  0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
  0x0, 0x0, 0x80, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
  0x0, 0x1, 0xc0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
  0x0, 0x3, 0x60, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
  0x0, 0x6, 0x30, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
  0x0, 0xc, 0x18, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
  0x0, 0x18, 0xc, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
  0x0, 0x30, 0x6, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
  0x0, 0x20, 0x2, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
  0x0, 0x60, 0x3, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
  0x0, 0x40, 0x1, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
  0x0, 0xc0, 0x1, 0x80, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
  0x1, 0x80, 0x0, 0xc0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
  0x3, 0x0, 0x0, 0x60, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
  0x6, 0x0, 0x0, 0x30, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
  0xc, 0x0, 0x0, 0x18, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
  0x18, 0x26, 0x72, 0x8, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
  0x10, 0x36, 0xe6, 0x8, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
  0x10, 0x62, 0x63, 0x8, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
  0x10, 0x63, 0x63, 0x8, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
  0x10, 0x1f, 0xfc, 0x8, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
  0x0, 0x1b, 0xec, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
  0xf, 0xc, 0x18, 0x78, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
  0x9, 0x3, 0xe0, 0x48, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
  0x9, 0xec, 0x1b, 0xc8, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
  0xf, 0x7, 0xf0, 0x78, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
  0x0, 0x20, 0x2, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
  0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
  0x1f, 0x16, 0x34, 0x7c, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
  0x1f, 0x3, 0xe0, 0x7c, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
  0x1f, 0x0, 0x0, 0x7c, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
  0x40, 0x38, 0xe, 0x1, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
  0x40, 0x3f, 0x7e, 0x1, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
  0x44, 0x1, 0xc0, 0x11, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
  0x44, 0x0, 0x0, 0x11, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
  0x44, 0x0, 0x0, 0x11, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
  0x44, 0x0, 0x0, 0x11, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
  0x7c, 0x0, 0x0, 0x1f, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
  0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
  0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
  0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
  0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
  0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
  0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
  0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
  0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
  0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
  0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
  0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
  0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
  0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
  0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
  0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
  0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
  0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
  0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
  0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
  0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
  0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
  0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
  0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
  0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
  0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
  0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
  0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
  0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
  0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
  0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
  0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
  0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
  0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
  0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
  0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
  0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
  0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
  0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
  0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
  0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
  0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
  0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
  0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
  0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
  0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
  0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
  0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
  0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
  0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
  0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
  0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
  0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
  0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
  0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
  0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
  0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
  0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
  0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
  0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
  0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
  0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
  0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
  0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
  0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
  0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
  0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
  0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0
};

void setup() {
  Serial.begin(9600);
  Serial.print("Starting...");
  tft.init();
}

void loop() {
  mdrawBitmap(0, 0, myBitmapBitmap, 100, 146, GREEN);
  delay(2000);
  mdrawBitmap(0, 0, myBitmapBitmap, 100, 146, RED);
  delay(2000);
  mdrawBitmap(0, 0, myBitmapBitmap, 100, 146, BLUE);
  delay(2000);
}

void mdrawBitmap(int16_t x, int16_t y, const uint8_t *bitmap, int16_t w, int16_t h, uint16_t color) {
  int16_t i, j, byteWidth = (w + 7) / 8;
  uint8_t byte;
  for (j = 0; j < h; j++) {
    for (i = 0; i < w; i++) {
      if (i & 7) byte <<= 1;
      else byte   = pgm_read_byte(bitmap + j * byteWidth + i / 8);
      if (byte & 0x80) tft.myDrawPixel(x + i, y + j, color);
    }
  }
}

So, I get some really weird things on my TFT. I have no idea what is going on...
As I said, the TftDisplay library is OK, but if you really wonder here is the code:
TftDisplay.h:
#ifndef _TFTDISPLAY_h
#define _TFTDISPLAY_h

#include <Adafruit_GFX.h>    // Core graphics library
#include <Adafruit_ST7735.h> // Hardware-specific library
#include <SPI.h>

//#define TFT_CS     15
//#define TFT_RST    5
//#define TFT_DC     2
//#define TFT_SCLK 14
//#define TFT_MOSI 13

#define TFT_CS 26
#define TFT_RST 24
#define TFT_DC 25
#define TFT_SCLK 22
#define TFT_MOSI 23

//#define TFT_CS 10
//#define TFT_RST 8
//#define TFT_DC 9
//#define TFT_SCLK 22
//#define TFT_MOSI 23

/*#define TFT_CS   10
#define TFT_DC   9
#define TFT_RST  8
#define TFT_SCLK 13   // set these to be whatever pins you like!
#define TFT_MOSI 11*/   // set these to be whatever pins you like!

#define BLACK           0x0000
#define BLUE            0x001F
#define RED             0xF800
#define ORANGE          0xe5f442
#define GREEN           0x07E0
#define CYAN            0x07FF
#define MAGENTA         0xF81F
#define YELLOW          0xFFE0
#define WHITE           0xFFFF

/* TFT Dimensions */
#define TFTHEIGHT 160
#define TFTWIDTH 128

class TftDisplay
{
  public:
    TftDisplay();
    ~TftDisplay();

    void init();

    void setDefaultTextSize(int textSize);
    void setDefaultTextColor(uint16_t color);
    void setTextWrap(int status);

    void text(String text, int x, int y, uint16_t color, int textSize);
    void text(String text, int x, int y, uint16_t color);

    void clearPart(uint16_t x, uint16_t y, uint16_t w, uint16_t h);
    void clearScreen();
    void myDrawLine(uint16_t x0, uint16_t y0, uint16_t x1, uint16_t y1, uint16_t color);
    void myDrawPixel(uint16_t x, uint16_t y, uint16_t color);
    void myDrawRectangle(uint16_t x0, uint16_t y0, uint16_t w, uint16_t h, uint16_t color);
    void myDrawBitmap(int16_t x, int16_t y, const uint8_t *bitmap, int16_t w, int16_t h, uint16_t color);
    uint16_t ConvertRGB( byte R, byte G, byte B);
  protected:
    Adafruit_ST7735 *tft;

    int default_textSize;
    uint16_t default_color;
};

#endif

TftDisplay.cpp:
#include "TftDisplay.h"

TftDisplay::TftDisplay()
{

  //init cannot be here as TFT must be inited in arduino setup routine otherwise
  //it crashes everything
}
TftDisplay::~TftDisplay ()
{
  delete tft;
}

void TftDisplay::init()
{

  tft = new Adafruit_ST7735(TFT_CS, TFT_DC, TFT_MOSI, TFT_SCLK, TFT_RST);
  //tft = new Adafruit_ST7735(TFT_CS, TFT_DC, TFT_MOSI, TFT_SCLK, TFT_RST);
  tft->initR(INITR_BLACKTAB);   // initialize a ST7735S chip, black tab
  tft->fillScreen(ST7735_BLACK);
}

void TftDisplay::setDefaultTextSize(int textSize){
    default_textSize = textSize;
    tft->setTextSize(textSize);
}

void TftDisplay::setDefaultTextColor(uint16_t color){
    default_color = color;
    tft->setTextColor(color, BLACK);
}

void TftDisplay::setTextWrap(int status){
    tft->setTextWrap(status);
}

void TftDisplay::text(String text, int x, int y, uint16_t color, int textSize)
{
    tft->setCursor(x, y);
    tft->setTextColor(color, BLACK);
    tft->setTextSize(textSize);
    tft->print(text);
    setDefaultTextSize(default_textSize);
    setDefaultTextSize(default_color);
}

void TftDisplay::text(String text, int x, int y, uint16_t color)
{
  tft->setCursor(x, y);
  tft->setTextColor(color, BLACK);
  tft->print(text);
  setDefaultTextColor(default_color);
}

void TftDisplay::clearPart(uint16_t x, uint16_t y, uint16_t w, uint16_t h) {
  tft->fillRect(x, y, w, h, BLACK);
}

void TftDisplay::myDrawLine(uint16_t x0, uint16_t y0, uint16_t x1, uint16_t y1, uint16_t color) {
  tft->drawLine(x0, y0, x1, y1, color);
}

void TftDisplay::myDrawPixel(uint16_t x, uint16_t y, uint16_t color) {
  tft->drawPixel(x, y, color);
}

void TftDisplay::myDrawRectangle(uint16_t x0, uint16_t y0, uint16_t w, uint16_t h, uint16_t color) {
  tft->drawRect(x0, y0, w, h, color);
}

void TftDisplay::clearScreen(){
  tft->fillRect(0, 0, TFTWIDTH, TFTHEIGHT, BLACK);
}

void TftDisplay::myDrawBitmap(int16_t x, int16_t y, const uint8_t *bitmap, int16_t w, int16_t h, uint16_t color){
  tft->drawBitmap(x, y, bitmap, w, h, color);
}

uint16_t TftDisplay::ConvertRGB( byte R, byte G, byte B)
{
  return ( ((R & 0xF8) << 8) | ((G & 0xFC) << 3) | (B >> 3) );
}

You have duplicate instances on the tftDisplay.h.
///////#define TFT_CS 26
#define TFT_RST 24
#define TFT_DC 25
#define TFT_SCLK 22
#define TFT_MOSI 23

//#define TFT_CS 10
//#define TFT_RST 8
//#define TFT_DC 9
//#define TFT_SCLK 22
//#define TFT_MOSI 23

/*#define TFT_CS   10   --->comment this correctly
#define TFT_DC   9
#define TFT_RST  8
#define TFT_SCLK 13   // set these to be whatever pins you like!
#define TFT_MOSI 11*/   // set these to be whatever pins you like!

And if you're using a Mega, it has different pins for SPI as compared to Uno.

As you can see it is commented code... And I use proper ones for Mega. I said dont worry about TftDisplay. Its ok... You are talking like you dont know what commented code is...

My bad, you should've just deleted those lines.


text:
Cannot correctly access element in array when given index
I have the following strings which are stored in the program memory. They are basically just morse code definitions, with another array of characters where each character in the array has the same index as the morse code definitions:
const char a[] PROGMEM = ".-";
const char b[] PROGMEM = "-...";
const char c[] PROGMEM = "-.-.";
const char d[] PROGMEM = "-..";
const char e[] PROGMEM = ".";
const char f[] PROGMEM = "..-.";
const char g[] PROGMEM = "--.";
const char h[] PROGMEM = "....";
const char i[] PROGMEM = "..";
const char j[] PROGMEM = ".---";
const char k[] PROGMEM = "-.-";
const char l[] PROGMEM = ".-..";
const char m[] PROGMEM = "--";
const char n[] PROGMEM = "-.";
const char o[] PROGMEM = "---";
const char p[] PROGMEM = ".--.";
const char q[] PROGMEM = "--.-";
const char r[] PROGMEM = ".-.";
const char s[] PROGMEM = "...";
const char t[] PROGMEM = "-";
const char u[] PROGMEM = "..-";
const char v[] PROGMEM = "...-";
const char w[] PROGMEM = ".--";
const char x[] PROGMEM = "-..-";
const char y[] PROGMEM = "-.--";
const char z[] PROGMEM = "--..";
const char one[] PROGMEM = ".----";
const char two[] PROGMEM = "..---";
const char three[] PROGMEM = "...--";
const char four[] PROGMEM = "....-";
const char five[] PROGMEM = ".....";
const char six[] PROGMEM = "-....";
const char seven[] PROGMEM = "--...";
const char eight[] PROGMEM = "---..";
const char nine[] PROGMEM = "----.";
const char zero[] PROGMEM = "-----";

const char* const morse_table[] PROGMEM = {a, b, c, d, e, f, g, h, i, j, k, l, m,
    n, o, p, q, r, s, t, u, v, x, y, z, one, two, three, four, five, six,
    seven, eight, nine, zero};

const char alphabet[] PROGMEM = {'a','b','c','d','e','f','g','h','i','j','k','l','m','n','o','p','q','r','s','t','u','v','w','x','y','z','1','2','3','4','5','6','7','8','9','0'};

I am then creating a function which is supposed to be able to take in the morse code definition and spit out a character. This function is below:
void checkString(char * compare) {
  //Unwrap the pointer to the array into a "real" array
  char buf[7];
  for (int i = 0; i < 6; i++) {
    buf[i] = compare[i];
  }

  int correctIndex = -1;

  for (int iterator = 0; iterator < 35; iterator++) {

    char buf2[7];
    strcpy_P(buf2, (char*)pgm_read_word(&(morse_table[iterator])));

    if ((buf[0] == buf2[0]) && (buf[1] == buf2[1]) && (buf[2] == buf2[2]) && (buf[3] == buf2[3]) && (buf[4] == buf2[4])) {
      correctIndex = iterator;
    }
  }

  if (correctIndex == -1) {
    Serial.println("Failed!");
  }

  else {
    Serial.print("Success! Index: ");
    Serial.println(correctIndex);
  }

  char characterBuffer = alphabet[correctIndex];
  Serial.println(alphabet[correctIndex]);
}

The strcpy_p line of code was essentially copied from the PROGMEM reference for Arduino. I don't understand much about it, but from my tests it appears to work in getting an actual string object out of the pointer.
If I input any of the morse code definitions given, the correctIndex integer does contain the correct location of that definition in the morse_table 2d array. However, when I pass this integer into the alphabet array hoping to get out the character at that location I am given a seemingly random character. Is there something that I'm doing wrong with this code to produce such a result? Thanks for your help.

This code cries for optimization... 1. Using binary code, letters could be stored as single byte instead of 2-5 bytes (+1 zero byte for string termination). 2. Comparisons could be as simple as comparing two bytes instead of multiple "&&" on string characters. 3. There is no need to store whole alphabet as string, just use ASCII table: numbers are codes 48-57, small letters are bytes 97-122 (https://en.wikipedia.org/wiki/ASCII)

@madneon thanks for the feedback - I'm new to c++. By letters, do you mean the morse code definitions? How is it possible to store multiple characters as one byte? I thought that each character had to be stored as one byte. I do see how storing them as null-terminated strings essentially wastes a byte though. That is helpful.

Sorry for late response. You can store Morse chars in bytes assuming eg. dashes are "ones" and dots are "zeroes", storing in lower bits, this way letter "a" would be 01, "b" would be "100" and so on. Im not sure if its needed, but you can also store the length of Morse code in eg. 3 higest bits.

You can't access arrays that are in PROGMEM as if they were normal variables. The compiler can't tell the difference and just interprets it as a RAM address, which is wrong.
Instead you have to use pgm_read_byte to get the data:
char characterBuffer = pgm_read_byte(alphabet + correctIndex);

Thanks, it appears that doing this solved my problem! Also removing PROGMEM and leaving my original code seemed to work as well. So by adding the location of the alphabet array to the offset the microcontroller is accessing the specific character at that location?

pgm_read_byte just reads a byte from a given address in flash. An array is just an address - usually a RAM address. Adding a number to a number yields a bigger number, which is the address that your requested byte lies at.


text:
Will the Arduino's low clock speed limit wireless transmission frequencies that are higher than the clock speed of the Arduino?
I've recently used 2.4GHz and 433MHz wireless communication modules, and I was wondering if the Arduino can only process at 16MHz(Arduino UNO's clock speed), then won't the communication modules also be limited to a maximum 16MHz?

The frequency of a (wireless) radio is its carrier frequency. The data stream is carried on it by modulating that carrier wave in some way: by frequency-shifting, for example. A given processor could not provide data at a rate faster than its clock frequency (at least as a steady-state rate), but a packet of data, once supplied to and buffered in the radio, could then be streamed out at a speed unrelated to the physical specs of the supplier (the MCU). If the MCU had to drive the transmitter, bit-by-bit, then that would indeed limit the transmission speed.

You need like 22kHz for "telephone quality" transfer of speech, but you can hardly articulate more than 4-5 syllables per second. The first is the carrier frequency, the other is data transfer speed. (And you usually need some time to think about what you want to say).
The wireless frequency is modulated by the transmitted signal, which must be lower than the frequency itself, to be able modulate it successfully and then be separated from it. There is also some overhead like headers stating who is transmitting, to who, how much, control sum and so. A lot of it is managed in hardware, without direct processor control. (You also do not generate the frequencies and tone in you head as values of sinus wave, you just send the modulation - talk - and the body makes its parts vibrate so fast with your breath).


text:
Help with my DHT22 sensor and using GET request
For some reason using my DHT22 sensor I keep getting "NaN". I have tried using older versions of the DHT22 sensor library as suggested by a few of my searches, but it still doesn't fix the issue.
Also I can't get it to work with the GET request portion. Any help would be greatly appreciated.
#include <Adafruit_Sensor.h>
#include <DHT.h>
#include <ESP8266WiFi.h>
#include <Phant.h>
#include <ESP.h>

#define DHTPIN 2
#define DHTTYPE DHT22

DHT dht(DHTPIN, DHTTYPE);
const char* ssid = "Myyyyyyh";
const char* password = "Ixxxxx1";
const char* host = "script.google.com";

//*****example address
//https://script.google.com/macros/s/AKfycbyNsFc87GQmRP3GnWoTzK6/exec?tag=test&value=8
const String gardenchart = "/macros/s/AKfycbyNnWoTzK6/exec?";
const byte sleeptime = 1;
const byte NUM_FIELDS = 5;
const String fieldNames[NUM_FIELDS] = {"ghumidity", "gtemp", "light", "otemp", "wtemp"};
String fieldData[NUM_FIELDS];

void setup() {
  Serial.begin(115200);
  delay(10);
  WiFi.begin(ssid, password);
  while (WiFi.status() != WL_CONNECTED) {
    delay(500);
  }
  fieldData[0] = 1;
  postdata();
  ESP.deepSleep(sleeptime * 60 * 1000000, WAKE_RF_DEFAULT);
}

void loop() {
  delay(50);
}

void postdata() {
  fieldData[0] = dht.readHumidity();
  fieldData[1] = dht.readTemperature(true);
  WiFiClient client;
  const int httpPort = 80;
  if (!client.connect (host, httpPort)) {
    return;
  }
  for (int i=0; i<NUM_FIELDS; i++) {
    client.print("GET ");
    client.print(fieldNames[i]); client.print("&value=");
    client.print(fieldData[i]); client.print(" HTTP/1.1");
    client.println("Host:"); client.print(host);
    Serial.print(fieldNames[i] + fieldData[i]); delay(500);
  }
  client.println("Connection: close");
}

The Adafruit DHT library causes a shortcut on the signal line. That can be a problem for Arduino boards, but it is a big problem for the ESP8266.
Issue: DHT init sequence wrong #48
I don't know what is a bigger problem, the shortcut in the code or Adafruit not fixing it.
Why do you mention the Arduino Uno with a label ?
For the "GET" you should find a good working example.
The DHT22 is not very good. There are better sensors with a normal I2C interface, for example the HTU21D-F or the BME-280. This is about a great test: Hackaday: Humidity Sensor Shootout. The BME-280 is the undisputed winner.

I'll look for a BMW, for the GET request it was working when I was using sparkfun's data hosting.  I am switching to posting to my Google sheet and that's when something isn't working quite right.


text:
Sleep mode Arduino Due through IR receiver control
I need to put my Arduino Due into sleep mode in order to consume less power. My Arduino Due receives IR data and does some work with it, but I need to make it sleep until there is no data. If data appears it should wake up and do something with data and go back to sleep mode.
Is there any way to do this? I would be grateful for any help.

you can't watch for data if the thing is off. you need another low-power thing to monitor the ir sensor and wake up the MCU if needed; i don't think the mcu itself can do that.

Connect the IR receiver to one of the interrupt pins, and set it so the mcu wakes up in the event of an interrupt.


text:
Is an Arduino Uno made in the USA compatible with SunFounder shields?
I bought an Arduino Uno from Radio Shack. I was under the impression it was the authentic model made in Italy. I read on Arduino.cc that the USA version is licensed and essentially the same. I then went to Amazon and ordered an RBG shield, and what I thought was the starter kit that is used with the examples on the IDE. I received the package and it is from SunFounder. Will this work with the IDE on the website and the Arduino I have from Radio Shack?

Generally if the boards are individually functional and the two mechanically fit together, they will probably work.  The exception might be some 3.3v non-ATmega boards.   Mechanical issues can include different version of the shield interface with fewer or more pins, special function pin assignments that differ between a normal Arduino vs. a Mega, and the full-size USB connector on official-style boards shorting against the underside of some shields.

Use the latest official Arduino IDE : Arduino IDE
Every Arduino Uno and all the clones are compatible. Some clones have the CH340G usb-serial chip and require an extra driver. If you look very hard, you might find an Arduino Uno board that is not version 'R3' and does not have SDA and SCL near the USB connector, or does not have the polyfuse for USB 5V, or uses an ATmega328 instead of a ATmega328P. There is a chance of maybe 1 in 10,000 that you find a wrong Uno board, and in most cases those are still compatible.
Do you mean the SunFounder RGB Matrix Driver Shield? That should be no problem.

Yes the RGB Matrix Driver Shield, and thanks for the response.


text:
Arduino Uno unable to detect usb port on Mac OS Sierra 10.12.5
Few weeks ago my Arduino Uno (IDE version 1.8.2) detected the USB port and I was able to do some small IOT projects. I updated my OS to Sierra 10.12.5 and now suddenly the usb serial option has disappeared.

I followed this link : https://learn.sparkfun.com/tutorials/how-to-install-ftdi-drivers/mac  where it tells us to download and install the FTDI drivers separately. I tried that but it did not help.
Then I came across this post: https://forum.arduino.cc/index.php?topic=427825.0 where the user is having this same problem with MacOS Sierra. He suggested we remove the FTDI drivers and rely on Apple's drivers. So I removed the FTDI drivers from my Mac so it will use Apple's drivers.
Now even after doing all this when I connect my Arduino Uno to my Mac via the USB it does not get detected.
I removed the kext and pkg files for the FTDI drivers and deleted them completely, still when I open the System Report I still see the FTDI USB Serial Driver entry.

When I go to System Report > Hardware > USB I see this:

What is happening? Did the FTDI drivers got removed? If they did then why wont the serial usb port get detected on Arduino? If they are not removed completely then what did I miss?

If you have a genuine Arduino you don't want the FTDI drivers. There hasn't been an FTDI on an Arduino for many years. If you have a cheap Chinese clone then you probably want the CG340G drivers (and good luck with those). Genuine Arduino boards use a CDC/ACM interface, and all modern operating systems have those drivers built in.

I am not sure if my Arduino is genuine or cheap chinese knockoff. I got it off from Amazon as a part of IOT starter kit. It worked properly in the beginning and as I mentioned I did some projects on it.

Unless you went through the rigmarole of installing the CG340G drivers (and you'd remember doing that, trust me) then it's probably like a genuine Arduino (with an ATMega16U2 chip as the USB interface) - however, is it actually genuine? Only a picture of the board could tell us that (there's telltale signs you can see if you know what you're looking for). If it's not genuine then it could be that the USB interface chip is dead (it may be a cloned chip or a factory reject).

Found this on youtube: https://www.youtube.com/watch?v=wyocdvAKo64&t=0s   what do you think?

That's for cheap chinese clones only - CH340G. Post a picture of your board please.

Here it is: https://drive.google.com/file/d/0B43t-lgy1BmXUHZ2cWJFdHZpSWc/view?usp=sharing

That's what we in the trade call counterfeit: it's pretending to be a genuine Arduino but isn't. Clues: there's no TM on the Arduino logo. They misspelled "RESET EN" calling it "RESET CN" instead. The silk screen isn't of a high enough quality. There's no "WWW.ARDUINO.CC - MADE IN ITALY" on the front. The font isn't quite right (too angular). So there is a chance the ATMega16U2 chip has died. I don't use a mac though so can't offer diagnostic suggestions.

So does this mean that the complete Arduino is useless? I have to buy a new one?

Not necessarily. As I say I don't use mac, so I can't help you diagnose it. There may be some other cause. If it is the ATMega16U2 though you can bypass it with a cheap USB to UART TTL adaptor connected to pins 0/1 and DTR to RESET through a 100nF capacitor. Just as if it were an ATMega328P on a breadboard.

Ok. Nevermind it worked. I followed the YouTube video I shared above and now the board is detected. Thanks for your help, I appreciate it :)

Strange that, since it doesn't use that driver. However it may kick the USB subsystem into action I guess as a side-effect.

I followed this you Tube Vedieo : https://www.youtube.com/watch?v=wyocdvAKo64&t=0s and I installed the CH340 driver but I do not found the more than ports in port option  but I still did't get my serial port

For me Peba's answer here helped me https://www.silabs.com/community/interface/forum.topic.topic.15.15.html/cp120x_vcp_driverno-G1Bu

I installed the CH340 Driver and the board now shows the USB serial as port option: https://github.com/adrianmihalko/ch340g-ch34g-ch34x-mac-os-x-driver

This cannot be an answer to the question asked, as the Uno does not have a CH340.   Either the question or the answer is incorrect.

@ChrisStratton I am fairly new to IOT and electronics in general. I did what I could to find a solution to my problem and it worked. If you are so enlightened in this matter then please feel free to give a "correct" solution to my problem or "correct" the questions.

I had the same problem w/ an Arduino Uno after upgrading to Sierra--no issue with USB port detection before upgrade and issue afterwards. I downloaded and installed the driver from the said github repo and then after reboot, it worked! Thanks for offering this solution.

Hi, You have to install CoolTerm for mac. http://freeware.the-meiers.org/


text:
Is Fastled.io library suitable for SMD50500 led strip?
I was looking for a ready to use library to control my SMD5050 color led strip, and I stumbled across FASTLED.IO library , but after reading trough their website I didn't find anywhere the support for SMD5050 color LED strip. Does anyone knows another "ready to use" animation library? Are FASTLED.IO suitable anyway?
Thanks

SMD5050 is just a shape of LED. It's a surface mount 5mm x 5mm package. What actual LED strip do you have?

@Majenko actually I forgot..I bought it one year ago...I looked on the strip but there's nothing writed on it...how can I understand it?

Do you have 4 connections at the end: +12V/R/G/B ? Or do you have 3 connections:  +5V/DAT/GND?

@Majenko yep...four connections

Then you can't animate it. You can just set the colour of the strip.

You'd wire it somewhat like this: https://arduino.stackexchange.com/questions/3535/rgb-led-strips-with-arduino

@Majenko I know they are not addressable but I thought to use FASTLED to make just simple color fade animation.. pulsing..buoncing..easing functions and so on..

FastLED is for addressable LEDs.

@Majenko They are wired in the way you showed me

You don't need a library to set the colours - just set the PWM outputs to the levels you want. It's up to you to "animate" it by changing those values.

@Majenko I was thinking there were other library with already made function like those http://easings.net/it

Not that I have ever come across. Arduino LED animation libraries are aimed at animating large numbers of individual LEDs.

No. FastLED is for addressable LEDs (like the WS2812B). Yours aren't addressable. You just need to set the colour you want with the PWM outputs of your Arduino. Changing the PWM values is not hard and you don't need a library to do it for you.

you are right...changing PWM value is not hardthe hard..will be achieving some of this fade functions http://easings.net/it

I am sure you are up to the task of writing the ones you want. If you have a mathematical formula you can easily calculate the colour to use at any one point in time. Otherwise simple CLUTs would be easy to implement.


text:
Galileo Positioning System signal receiving
I want to determine my arduino's position. However, I want to use the European Galileo system instead of the US-American GPS.
Therefore, I searched for any possibilities receiving the Galileo signals. I figured out, that u-blox has some receivers: NEO 8 or the LEA 6 (firmware update required). However I did not find any arduino breakout board (, etc.) that uses these u-blox sensors or other Galileo-compatible hardware.
Does anyone know, how I could use the Galileo Position System?

First check that there is coverage in the area you want to use it. Currently coverage is mainly Europe. They are still in the process of putting more satellites into orbit.

but why using a system starting in 2020?

You need the hardware and a library. Most GPS modules use a serial communication, and I think that also the Galileo compatible boards use serial communication. That makes them compatible with most microcontrollers and also with Arduino boards.
I could find a few shields that can be attached to an Arduino board.
This one is in development at the moment: Kickstarter shield with Galileo
This one is compatible via the serial pins: GA-001 Multi GNSS Ublox
There is a "NEO-M8N" shield and maybe one or two others.
All those boards are very new, and I don't know if they come with a library for an Arduino. Perhaps you have to wait a few months and then it should be a lot easier to buy a complete functioning module with a library.
Before buying a module, confirm that there is a library for Arduino or good documentation to write your own library.

NeoGPS is the only Arduino library that will work with the newest GPS devices, like the NEO-M8.


text:
How can Arduino know Wire.available() is true or false?
In this part of code
void readFrom(byte device, byte fromAddress, int num, byte result[]) {
  Wire.beginTransmission(device);
  Wire.write(fromAddress);
  Wire.endTransmission();
  Wire.requestFrom((int)device, num);
  int i = 0;
  while(Wire.available()) {
    result[i] = Wire.read();
    i++;
  }
}

How can Arduino know that Wire.availble() is true or false?
I thought that when the microcontroller "reads" the value from the sensor, in pieces of 8 bits, he reads from 0 (n) to 5 (n+5) at the I2C address of the MPU-6050, and when he increments 6 it finds nothing, but this is my conclusion, i am not sure about it.

I am studying how Serial.available works and how the circular buffer works for the data comunication, because available() inherits from the Stream utility class.
The entire code is the following taken from  this question
  #include <Wire.h> //The I2C library

int gyroResult[3], accelResult[3];

//Function for writing a byte to an address on an I2C device
void writeTo(byte device, byte toAddress, byte val) {
  Wire.beginTransmission(device);
  Wire.write(toAddress);
  Wire.write(val);
  Wire.endTransmission();
}

//Function for reading num bytes from addresses on an I2C device
void readFrom(byte device, byte fromAddress, int num, byte result[]) {
  Wire.beginTransmission(device);
  Wire.write(fromAddress);
  Wire.endTransmission();
  Wire.requestFrom((int)device, num);
  int i = 0;
  while(Wire.available()) {
    result[i] = Wire.read();
    i++;
  }
}

//Function for reading the gyros.
void getGyroscopeReadings(int gyroResult[]) {
  byte buffer[6];
  readFrom(0x68,0x1D,6,buffer);
  gyroResult[0] = (((int)buffer[0]) << 8 ) | buffer[1]; //Combine two bytes into one int
  gyroResult[1] = (((int)buffer[2]) << 8 ) | buffer[3];
  gyroResult[2] = (((int)buffer[4]) << 8 ) | buffer[5];
}

//Function for reading the accelerometers
void getAccelerometerReadings(int accelResult[]) {
  byte buffer[6];
  readFrom(0x53,0x32,6,buffer);
  accelResult[0] = (((int)buffer[1]) << 8 ) | buffer[0]; //Yes, byte order different from gyros'
  accelResult[1] = (((int)buffer[3]) << 8 ) | buffer[2];
  accelResult[2] = (((int)buffer[5]) << 8 ) | buffer[4];
}

void setup() {
  Wire.begin();            //Open I2C communications as master
  Serial.begin(9600);    //Open serial communications to the PC to see what's happening

  writeTo(0x53,0x31,0x09); //Set accelerometer to 11bit, +/-4g
  writeTo(0x53,0x2D,0x08); //Set accelerometer to measure mode
  writeTo(0x68,0x16,0x1A); //Set gyro to +/-2000deg/sec and 98Hz low pass filter
  writeTo(0x68,0x15,0x09); //Set gyro to 100Hz sample rate
}

void loop() {
  getGyroscopeReadings(gyroResult);
  getAccelerometerReadings(accelResult);

  Serial.print(gyroResult[0]);
  Serial.print("\t");
  Serial.print(gyroResult[1]);
  Serial.print("\t");
  Serial.print(gyroResult[2]);
  Serial.print("\t\t");
  Serial.print(accelResult[0]);
  Serial.print("\t");
  Serial.print(accelResult[1]);
  Serial.print("\t");
  Serial.print(accelResult[2]);
  Serial.print("\n");

  delay(50);
}

Minor Question
I am trying to undestand the difference between the register and the device address, but i did find anything on my book.

You've used lots of words, but I don't actually understand what it is you think you are asking.

Sorry, i think my bad english is  a problem to explain my question. The while statement end when Wire.available() is false. This happen when there is nothig to read (?). How can arduino know that there is nothing nothing more to be read? Thank you :)

Because the Wire library software coupled with the I2C hardware interface has determined that is the case? You should read the datasheet and the Wire library source code.

If you request 5 bytes you have 5 bytes in the buffer, and when you have read all 5 there will be nothing available.

Ok, i think, now is little bit clearer, i will read the Wire library source code . I have read the mpu6050 datasheet yet, your blog post on buffer, but it was still not clear and hard for a self-taught like me :)

I2C is one of the harder protocols to understand. It has nothing in common (other than the fact that one bit follows another) with Serial, so reading Serial in the hope of understanding I2C is not going to help.

Ok so is very normal to have this difficulties :)

When the Wire.requestFrom is used, the receive buffer inside the Wire library is cleared and the received data is stored in that buffer. The Wire.available tells how many bytes are in that buffer. That means you start with a fresh cleared buffer every time before reading data from a sensor. The I2C only defines that the first byte is the address of the sensor. How the sensor selects its internal register or how it handles commands is up to the sensor. Often a byte is written to set the register-address inside the sensor and after that a number of data bytes is read from the sensor.

The simple answer is that the Arduino Wire library has an internal buffer, and it can bring in characters and have them sitting there ready for you to pick them up.
It can also sense a total disconnect because of the way it uses both data pins to establish communications.  It is more like a current loop than a simple one-is-transmit-and-the-other-is-receive.  If it disconnects the Arduino knows it is not available.
Kudos on going to the documentation, by the way.


text:
Expected unqualified ID before numeric constant
After debugging and having some conflicting declarations about analog pins, I finally thought it was done, after compiling I got this error:
32:0,
1:
31:12: error: expected unqualified-id before numeric constant

2:5: note: in expansion of macro 'B1'

I can't understand what this means. What's wrong with my code down here?
// don't judge me if it's too long and overcomplicated :P I'm still new xD
int AA1 = 0;
int B1 = 1;
int C1 = 2;
int D1 = 3;
int AA2 = 4;
int B2 = 5;
int C2 = 6;
int AA3 = 8;
int B3 = 9;
int C3 = 10;
int D3 = 11;
int B4 = 12;
int C4 = 13;
int sec = 0;
int min1 = 0;
int min2 = 0;
int hour1 = 8;
bool hour2 = 0;

void setup() {
  pinMode(AA1, OUTPUT);
  pinMode(B1, OUTPUT);
  pinMode(C1, OUTPUT);
  pinMode(D1, OUTPUT);
  pinMode(AA2, OUTPUT);
  pinMode(B2, OUTPUT);
  pinMode(C2, OUTPUT);
  pinMode(AA3, OUTPUT);
  pinMode(B3, OUTPUT);
  pinMode(C3, OUTPUT);
  pinMode(D3, OUTPUT);
  pinMode(B4, OUTPUT);
  pinMode(C4, OUTPUT);
}

void loop() {
  OutputOn();
  delay(1000);
  sec++;
  if(sec == 60) {
    sec = 0;
    min1++;
      if(min1 == 10) {
      min1 = 0;
      min2++;
        if(min2 == 6) {
        min2 = 0;
        hour1++;
          if(hour1 == 10) {
          hour1 = 0;
          hour2 = 1;
        }
        if(hour2 == 1, hour1 == 3) {
          hour1 = 1;
          hour2 = 0;
        }
      }
    }
  }
}

void OutputOn() {
  digitalWrite(B1, LOW);
  digitalWrite(C1, LOW);
  digitalWrite(D1, LOW);
  digitalWrite(A2, LOW);
  digitalWrite(B2, LOW);
  digitalWrite(C2, LOW);
  digitalWrite(A3, LOW);
  digitalWrite(B3, LOW);
  digitalWrite(C3, LOW);
  digitalWrite(D3, LOW);
  digitalWrite(B4, LOW);
  digitalWrite(C4, LOW);
  if(min1 == 1) { digitalWrite(AA1, HIGH); }
  if(min1 == 2) { digitalWrite(B1, HIGH); }
  if(min1 == 3) { digitalWrite(B1, HIGH); digitalWrite(AA1, HIGH); }
  if(min1 == 4) { digitalWrite(C1, HIGH); }
  if(min1 == 5) { digitalWrite(C1, HIGH); digitalWrite(AA1, HIGH); }
  if(min1 == 6) { digitalWrite(D1, HIGH); digitalWrite(B1, HIGH); }
  if(min1 == 7) { digitalWrite(D1, HIGH); digitalWrite(AA1, HIGH); digitalWrite(B1, HIGH); }
  if(min1 == 8) { digitalWrite(D1, HIGH); }
  if(min1 == 9) { digitalWrite(D1, HIGH); digitalWrite(AA1, HIGH); }
  if(min2 == 1) { digitalWrite(AA2, HIGH); }
  if(min2 == 2) { digitalWrite(B2, HIGH); }
  if(min2 == 3) { digitalWrite(B2, HIGH); digitalWrite(AA1, HIGH); }
  if(min2 == 4) { digitalWrite(C2, HIGH); }
  if(min2 == 5) { digitalWrite(C2, HIGH); digitalWrite(A2, HIGH); }
  if(min2 == 6) { digitalWrite(C2, HIGH); digitalWrite(B2, HIGH); }
  if(hour1 == 1) { digitalWrite(AA3, HIGH); }
  if(hour1 == 2) { digitalWrite(B3, HIGH); }
  if(hour1 == 3) { digitalWrite(B3, HIGH); digitalWrite(AA3, HIGH); }
  if(hour1 == 4) { digitalWrite(C3, HIGH); }
  if(hour1 == 5) { digitalWrite(C3, HIGH); digitalWrite(AA3, HIGH); }
  if(hour1 == 6) { digitalWrite(C3, HIGH); digitalWrite(B3, HIGH); }
  if(hour1 == 7) { digitalWrite(C3, HIGH); digitalWrite(AA3, HIGH); digitalWrite(B3, HIGH); }
  if(hour1 == 8) { digitalWrite(D3, HIGH); }
  if(hour1 == 9) { digitalWrite(D3, HIGH); digitalWrite(C3, HIGH); }
  if(hour2 == 1) { digitalWrite(B4, HIGH); digitalWrite(C4, HIGH); }
}

It's supposed to be code for a clock (if it wasn't obvious enough) hooked up to 4 7-segment decoders, also connected to 4 7-segment LED displays.

In general when writing in C,  “macro” should be a big hint that you have a problem involving #define.  Bizzare errors saying things that are not what you wrote: problem involving #define.

Bad luck. There is a file within Arduino called "binary.h", and it contains a define called "B1". Which means you may not use "B1" as a variable. In my opinion, that file "binary.h" is totally unnecessary.
In the preferences you can turn on extra output for the compiler and turn on line numbers. The compiler will tell what is wrong, but you have to know how the compiler does that. The first compiler error is the most important.
".../hardware/arduino/avr/cores/arduino/binary.h:31:12: error: expected unqualified-id before numeric constant #define B1 1" means that the compiler was reading the file "binary.h" and at line 31 it noticed something it did not understand and it has to do with "B1".

So I just have to not use B1?

Correct. The leading B with 0's and 1's is used for binary constants: https://www.arduino.cc/en/Reference/IntegerConstants Since it is a pin number, you can call the variable "const B1Pin = 1;" or even "const TheyToldMeAtStackExchangeNotToCallThisB1 = 1;"

I ment: "const int B1Pin = 1;". Sorry, I forgot the 'int'. The 'const' keyword is not needed, it tells the compiler that it is a constant number and does not change.


text:
How do I use an ATMega 328 (not P) chip with an Arduino board?
I just burned the bootloader on an ATMega328 chip and then I put in on the Arduino board. But when I try to upload a program to it, it says programmer not in sync and programmer not responding.
For burning the bootloader I changed the address in the avrconfig file and reset it back to the original one. Do I need to keep changing the address of the board?
How do I use this as a normal Arduino board, as I fried my original chip? Do I need to get an ATMega328P chip?

Did you set the right fuses for the clock source?

i used an external 16mhz clock but didnt change any code for it.

If you don't set the right fuses it will be running from the internal clock and everything will be the wrong speed. Check your fuse settings.

@Majenko could you help me with this i am a bit new to this.

So I found the solution:
Here is the link to the method that worked for me. I think the reason my previous method didn't work was because of fuses for the clock as mentioned by Majenko in the comments.

thank you for showing me how i am supposed to answer (i am new here).

You can force the 'P' bootloader into it and use it as an Arduino board. The extra possibilities of the 'P' are not used by the standard Arduino libraries and when uploading it does check the bootloader but it does not check the chip signature.
I think you have already done this. Perhaps something else is wrong.


text:
Custom boards list
Is there a simple way to create or modify my boards list? I find having a full library listing confusing. I have about 6 boards I program regularly, but using the listings from the board manager gives me about 60 things to look through, which gets tedious fast.
Here is a list of MCUs I frequently use:

Teensy2.0
Adafruit Trinket 16Mhz
Adafruit Trinket Pro 16MHz
Adafruit Circuit Playground
Adafruit feather Huzzah
Arduino Uno R3

How can I make a boards list that only includes the boards I own?

Throwing out the unneeded boards from the boards.txt files will do what you want.

where is that? in the arduino directory?  Im on linux, I will look for it.

Avr boards are in arduino install/hardware. Boardmanager installs are at  ~/.arduino15/packages on linux.


text:
GSM SIM900A SMS content not displaying
I am trying to read messages sent from my mobile to a GSM SIM900A module on my Arduino Serial monitor. Neither does the AT+CMGR command nor does the AT+CMGL command display SMS content. I also tried increasing the receiver buffer size in the SoftwareSerial Library but to no avail. I am simply trying to read 'check123'. I want to further store the SMS received as a string for further processing. But I am stuck with no display of SMS content on the serial monitor.
My code is:
#include <SoftwareSerial.h>
SoftwareSerial mySerial(9, 10);
String content = "";
char character;
int i;

void setup() {
  mySerial.begin(9600);
  Serial.begin(9600);
  delay(100);
}

void loop() {
  ReceiveSMS();
  delay(2000);
}

void ReceiveSMS() {
  mySerial.println("AT+CMGF=1");
  delay(2000);
  toSerial();
  mySerial.println("AT+CPMS=\"SM\",\"SM\",\"SM\"");
  delay(2000);
  toSerial();
  mySerial.println("AT+CMGL=\"ALL\"\r");
  delay(5000);
  toSerial();
  mySerial.println("AT+CMGD=1,4");
  delay(2000);
  toSerial();
}

void toSerial() {
  while (mySerial.available() != 0) {
    Serial.write(mySerial.read());
  }
}

Output is:

Edit:
SoftwareSerial.cpp file. I have marked the area where I have changed the value from 64 to 256 according to some previous help post.

It is typically a buffer overflow issue. what is your current rx buffer size now?

I have changed it to 256 from 64

you mean you have changed softwareserial rx buffer or hardware serial rx buffer?

I have added the image of SoftwareSerial.cpp file and the change I made in it.

Your code is absolutely correct. As I tested it with my Mega with Serial3 connected to GSM SIM900. I think there is something fishy about SoftwareSerial. Double-check the location of SoftwareSerial.

C:\Program Files (x86)\Arduino\hardware\arduino\avr\libraries\SoftwareSerial\src

Maybe you can see if RAM usage is exceeding the safe limit. Here is my output:


text:
HX711 sporadic wrong values
Am interfacing HX711 with arduino to measure the load of something. However, in my project, I need to continuously monitor the load.
I get fairly accurate values most of the time however, at times I suddenly get a junk value. For example, I call the weight function every 3 seconds and I have placed a 10kg weight, this is what I get. 17.25 is the concern.
10.04, 10.03, 17.25, 10.04, 10.03, 10.03
Am using HX711 library and my process function is a simple call as shown below.
float Processweight()
{
  Serial.print(scale.get_units(40), 2);

  scale.power_down();              // put the ADC in sleep mode
  delay(500);
  scale.power_up();
}

is there something that am missing? What could cause the wrong values?

Actually debugging that would require examining the code and circuitry in detail.  If you don't need answers quickly, you could try a filter; not something that averages but something that rejects rapid change.  Also be aware in your application of the load cell behavior called "creep".

Thanks chris, I will try writing a correlation to reject sudden changes. However, I was curious to understand if HX 711 itself has such issues. I will sure use filtering if I get confident that I have done everything else right.

I get fairly accurate values most of the time however, at times I suddenly get a junk value.

if you use the ebay board, it has the incorrect grounding, which may contribute to the sporadic values you saw.

For example, I call the weight function every 3 seconds

poor quality libraries could be another possibility.
I have used the board quite extensively and aside from its tempco, it is fairly reliable. you can see here: https://dannyelectronics.wordpress.com/2015/10/25/a-hx711-based-milliohm-meter/
when everything is done right (and in a constant temperature environment), it has very good consistency.

Thanks a lot danny for the input. I will check the same.

Finally I got this right by adding a code to check if 5 consecutive values are fairly close enough and only then respond. That way I was able to flush out sudden changes. However, I still am not sure as to what is causing that jump.

The power down and power up could be an issue.  Probably you should add some delay between the power up and reading attempt.  Also, you may want to examine the wrong values and see if there is any pattern to them.

Thanks for the leads chris, the wrong values had no recognizable pattern. I have tried adding delay, in fact I fully removed the power up and power down cycle (always kept it powered up) and I still saw the issue.


text:
Arduino 101 I/O voltage levels
As per the Arduino 101 schematic.
The Arduino 101 has level shifters (TI make LSF0108) connected to the I/O ports I guess these are to make them Arduino compatible(5V) since the Intel Curie Module is 3.3V rated.
I have 2 doubts regarding this

The level shifters are also connected to the analog pins so I was wondering how do these shifters pass through analog signals?
I have some 3.3V sensors that I want to interface to the Arduino 101 via I2C. My question is can I use 3.3V levels at the I/O ports or am I restricted to 5V?

TIA

@Majenko that's a 4 page document, agreed that 1st page is a block diagram.. but the schematic is from pages 2 onwards..

Do you have a cloth I can wipe the egg off my face with? ;)

Even with the schematic I can't see how that can possibly provide any analog inputs at all. The Ax pins go straight into an LSF0108 digital logic level translator, so how it can claim there are analog inputs I don't know. You're right to be confused. Also if the schematic is to be believed the LSF0108 isn't being used according to the datasheet's recommendations. Not sure quite how/why they are doing it...

@Majenko yes I had the same thoughts... even the LSF0108 datasheet doesn't shed any light on analog levels.

Nexperia's appnote AN90033 explains how it works.

An Exploring the I/O Performance of the Arduino 101 webpage by Dan Watson has a number of relevant comments:

The board uses three Texas Instruments LSF0108 level translators to accommodate all of the I/O lines (including the analog inputs). This is an interesting part. It's not really a level "shifter", and it's not a buffer. The Curie is still sourcing and sinking current to the pins, but the voltage levels are clamped at 3.3V on the Curie's side of the chip. In this regard it's kind of like a fancy analog switch. The on resistance of each signal path is in the neighborhood of 10 ohms.

Somewhat later in the article:

Analog Input Linearity:  Next I tested the analog inputs. I was curious if the level translators affect the accuracy of the readings. I applied a DC voltage on pin A5, starting at 0V and increasing to 3.3V in 100 mV steps. At each step, I recorded the 10-bit analog-to-digital (ADC) readings reported by the Arduino 101. I then created a graph of the data, which is shown [on the webpage]. As you can see, the results are pretty linear across the entire input range. Spot-checking a few values, I found that there might have been a +20mV bias on the readings at the top end of the scale.

To summarize:  As a consequence of being like an analog switch, the LSF0108 allows the Curie's analog input pins to accept analog inputs, and apparently it works ok.
Regarding the second question, whether 3.3 V levels are ok at the I/O ports, I think they are.  See the article mentioned above for more comments.  Here is one that may be relevant:

Digital Input Logic Transitions:
  I applied a DC voltage to pin D7 and varied it up and down while the Arduino 101 reported the logic state in the serial monitor. This was done in order to discover the logic transition levels. Going from high to low, it returned a low state after crossing 1.26V. Going from low to high, however, the transition occurred at 1.55V.

Edit 1:  Regarding two questions in a comment...

What is the function of the level translators.. do they actually map the 0 to 5V levels to 0 to 3.3V on the curie side. ?

See the LSF0108 datasheet.  The LSF0108 has eight A, B pairs: (A1,B1);  (A2,B2); ... (A8,B8).  If you drive Ai low, Bi goes low too; and vice versa, if you drive Bi low, Ai goes low too.  That translates low to low. If neither side is driven low, connected inputs can pull up to an individual-pullup level but not higher than a reference level (VREFA or VREFB).  This translates high to high.

If I give a 0 to 5V analog voltage at the headers will the 3.3V to 5V level part of the signal be lost, I mean does the board only take care of the 0 to 3.3V part of the signal and the adc will give max counts at 3.3V?

It should be 'lost', because as noted in the Curie datasheet's Table 2-5. ADC - DC I/O specifications, the AIN Full-scale input range is ≤ ADC_3P3_VCC and ≤ AON_IO_VCC.  (The latter voltage is 1.8 or 3.3 V.)  I'm not clear on why the LSF0108 doesn't interfere with ADC measurements.  Maybe the switches operate in a linear mode when pullups are turned off?

thanks for digging that link out... for the analog input linearity test what did the autthor increase it to a max of 3.3V why not 5V?

I'll try and get in touch with the author to learn what his experiences were...

I still have a few questions... 1. What is the function of the level translators.. do they actually map the 0 to 5V levels to 0 to 3.3V on the curie side. ? 2. If I give a 0 to 5V analog voltage at the headers will the 3.3V to 5V level part of the signal be lost, I mean does the board only take care of the 0 to 3.3V part of the signal and the adc will give max counts at 3.3V?

@MiguelSanchez, see edit 1

I have a feeling the LSF0108, internally, is just an N channel MOSFET per channel. Your classic bidirectional MOSFET level translator. As such it will be fairly transparent to analogue voltages.


text:
Reading pulse train with DC offset
One of the analog inputs to Arduino is a pulse train with DC something like 1.5V to 3.9V pulse. This of course changes by time and Im only interested in the difference voltage (peak-to-valley). Like I want Arduino to measure (3.9V-1.5V) in the loop. I can use two analog inputs if there's no other way.
How to code this kind of measurement?
Does anybody have experience with this?
duty cycle is 50% freq 3.3kHz.

Please edit your question (click the edit button) to include some waveform and performance specs  – how long the voltage stays high or low; required accuracy; what you want to measure.  A solution that works if the input is audio frequency might not be adequate to handle RF inputs.  Regarding what you want to measure, do you want to know the frequency, or risetimes, or pulse lengths, or voltages, or what?

just an incoming pulse train to ADC with  duty cycle is 50% freq 3.3kHz. with dc offset. i even gave an example in my question about what i need. i want to roughly measure peak to valley voltage of this type of pulse.

The proper method to use depends in part on what the data is for, and on what other processing your loop needs to do.  The following example assumes there is nothing to do except compute the difference between the highest and lowest readings from among the most recent 8.
enum { nReads = 8 }; // # of readings = 2**3
enum { rMask = 7 };  // index-mask of 3 bits
enum { aIn = A3 };   // analog input pin #
int reads[nReads];
byte rindex=0;

void loop() {
  int vhi, vlo, vdiff, r;
  r = reads[rindex] = analogRead(aIn); // Analog read takes about .1 ms
  vhi=0; vlo=1024;
  for (byte i=0; i<nReads; ++i) {
    if (r > vhi) vhi = r;
    if (r < vlo) vlo = r;
  }
  rindex = (rindex+1) & rMask;
  vdiff = vhi - vlo;
  //
  // In this section, scale or use or report vdiff
  //   ...
}

An analog read takes about 104 μs.  That, plus any time taken to scale, use, or report vdiff, will be the major determinant of how rapidly loop() runs, because the for loop that calculates vhi and vlo should take less than 10 or 15 μs.
For example, if loop() takes 125 μs per pass, the code will get about one reading per half cycle of input.  (3.3 KHz is 303 μs per full cycle.)  This will produce a steady precession of where the analog readings are taken within the input waveform's cycle.  If that phenomenon is undesirable, you may need to use interrupt-triggered ADC reads.
If you don't need new differences as frequently as the above code produces them, you could instead on demand take several readings in a row and produce a result.  For example:
int getDiff() {
  enum { nReads = 6 };
  enum { aIn = A3 };   // analog input pin #
  int vhi=0, vlo=1024, r;
  for (byte i=0; i<nReads; ++i) {
    r = analogRead(aIn); // Analog read takes about .1 ms
    if (r > vhi) vhi = r;
    if (r < vlo) vlo = r;
  }
  return vhi - vlo;
}

void loop() {
  int vdiff;
  if (readingIsNeededNow) {
    vdiff = getDiff();
    // do stuff with voltage difference
  }
  // etc
}


text:
Renaming folders in Arduino Uno' SD card
I want to rename folders through the SD shield but it does not rename them, because It renames It in another default name
How Can i rename it using the name that I want?

According to this post (https://forum.arduino.cc/index.php?topic=73265.0) this library should be able to rename the folders (https://github.com/greiman?tab=repositories) but there are a lot of posts out there saying they are having problems.
It might be worth checking you can rename them on a PC, there may be problems with name lengths etc that will just complicate matters.

It looks like all of the problems mentioned in the forum.arduino.cc post are due to the obtuse asker insisting on keeping duplicative calls to the obsolete SD.h wrapper alongside using SdFAT for renaming.  In other words, all self-inflicted problems.


text:
Switch case inside a switch case with serial input
I'm trying to build a test program for some hardware. Basically I want to select the piece of hardware with the outer switch case then select the test with the inner switch case. I'm trying to accomplish this by using serial input in the Arduino IDE monitor.
I can't make it work whatever I do. I either end up stuck in the outer switch case or I never enter the inner switch case where I want to select the test.
I've got a bit of code below:
char select_addon;
char select_test;

void setup() {
  Serial.begin(9600);
  Serial.println("(1) PB1");
  Serial.println("(2) PB2");
  Serial.println("(3) PB3");
}

void loop() {
  if (Serial.available() > 0) {
    select_addon = Serial.read();
    switch (select_addon) {
      case '1':
        Serial.println("Test");
        if (Serial.available() > 0 ) {
          select_test = Serial.read();
          switch (select_test) {
            case '4':
              Serial.println(" Test 1.1");
              break;
            case '5':
              Serial.println(" Test 1.2");
              break;
            case '6':
              Serial.println(" Test 1.3");
              break;
          }
        }
        break;
      case '2':
        Serial.println("TEST 2");
        break;
      case '3':
        Serial.println("TEST 3");
        break;
    }
  }
}

Obviously this isn't the finished code, but it's the switch case structure I've been trying to implement. Any suggestions on how I can enter the inner switch case?

switch on ardunio seems to want numbers. your chars might be being compared as char-codes. try something like   int select_addon = String(Serial.read()).toInt(); and case 3, instead  case '3'

What happens of the if (Serial.available() > 0) call fails?  That's the problem, because when there isn't anything available it's skipping the second switch statement.
On a point of style it actually might be better to implement the inner switch as a separate function. Imagine what your code will look like with 5 cases in the outer switch, each with 5 cases in the inner switches.
Also it might be worth, for debugging purposes, to always have a default statement, at least then you will know what key it was that you pressed.

At 9600 baud the data comes in a byte per millisecond. The inner Serial.available does not see the next byte yet. Three solutions: (A) add a delay of about 5ms as soon as the outer Serial.available sees data. This is a bad solution, dont' do it. (B) Use the Arduino 'parse' functions https://www.arduino.cc/en/Reference/ParseInt . (C) Describe the serial data en describe that a linefeed at the end is mandatory. Read the data in a buffer until the linefeed is read or until the buffer is full, and then process the buffer. This is the best solution.

Yeah, I was going to put the inner switch case into functions as soon as I got them to work.
Is there anything I can do to get the program to wait for another input once I've chosen the outer function? Lets say I type '1' in serial input, can I get it stuck somehow in that case and wait for 4,5 or 6? Because when I do select '1' all it does is print "Test" and goes back to the outer case.

As I said in the answer the cause of you problem is if (Serial.available() > 0), if there is data in the serial buffer then execute the inner switch otherwise (i.e. there is no data in the couple of ms since you pressed one) do nothing.  The problem is you aren't typing fast enough for you  code.  You need to press 4 within 1000th of a second of releasing 1.  OR you could change you if statement to while (Serial.available() < 1);

Oh I understand now, that actually makes perfect sense. Thanks bud.


text:
Arduino Uno R3 stuck in DFU mode/Port not recognized
I have an Arduino Uno R3 that is simultaneously stuck in DFU mode and won't be recognized as a port in the Arduino IDE on my Macbook Pro (El Capitan). Upon receiving power, the Arduino is automatically in DFU mode (I can use dfu-programmer via Terminal to access it, even though the Arduino is not 'recognized'), and by using the process normally reserved for entering DFU mode (connecting the two pins on the left side of the ICSP) the Arduino actually exits DFU mode. However, by neither entering or exiting DFU mode, the Arduino is still not 'recognized' as a port by the Arduino IDE. Prior to this happening, I had been attempting to flash files to the bootloader with success (I got this same predicament in that process previously once, but I do not know what happened differently).
Thanks,
wblegoboy

And have you tried using DFU to reinstall the default CDC/ACM firmware for the ATMega16U2?

I just tried your suggestion, @Majenko, flashed Arduino-usbserial-atmega16u2-Uno-Rev3.hex and it worked beautifully! My DFU mode is now working properly and my Arduino port is now showing after a restart on my Macbook. Thanks!

Great, I'll put it as an answer then.

It sounds like your ATMega16U2 has lost its CDC/ACM firmware and is entering DFU mode by default to allow you to install firmware.
Installing the CDC/ACM firmware using dfu-programmer would get it working again.


text:
Bluetooth communication not working with DC power but works with USB power?
I am running an HM-10 Bluetooth Low Energy (BLE) module to transmit serial data (using SoftwareSerial) from an analog sensor onboard my Arduino Uno to a serial terminal app on my Android phone. When I power the Arduino with a USB power bank, the data transmits flawlessly.
When I tried to power the Arduino with a 9V battery through the DC power jack instead of USB power, the BLE module connects to my phone, but no data is transmitted when a serial connection is established.
Any ideas why this would be?

"9V battery" as in little wimpy PP3 that can't power ****?

@Majenko yes, correct. Is the implication of your reply that the (brand new) battery is not powerful enough? If so I could try to source a battery box to attempt to get it running on AA batteries as a test.

PP3 batteries are the laughing stock of the battery world. You want at least 6V of AA batteries  for what you are doing - and if you value your battery life you want to bypass the Arduino's on-board regulators and use switching regulators instead.

@Majenko thanks! I am putting the Arduino onboard a drone and it'll only need to work for 10 mins at a time; the biggest concern is weight and not battery time. But I will give it a try.

In that case you would be better using Li-Ion batteries since they have a higher energy density for their size/weight.

@Majenko Thanks - so there is no practical reason other than a lack of power being supplied to the unit that the 9V PP3 would not cause the SoftwareSerial data to be sent?

Transmitting takes a lot of power. The Duracell datasheets consider 250mA to be a heavy load (it's the heaviest they characterise it for). Transmitting typically takes hundreds of mA, and needs it delivering rapidly - something a PP3 is not good at due to the massive (comparatively) internal resistance.

@Majenko - BLE transmit power is a brief pulse at a few tens of milliamps.  It's within the capability of a CR2032 coin cell.  Advertising fairly frequently mine drew an average of around 200 uA.  Likely the Arduino draws more, at least on average.

@ChrisStratton A well designed one is, yes. A cheap HM-10 from China? Who knows what that might draw. I wouldn't trust it to be less than a few hundred milliamps.

What I measured was an HM-10.  Running essentially the TI example.  Not sure if there's any software in them by default.

@ChrisStratton Also a CR2032 isn't crippled by the linear regulators of the Arduino throwing away about 50% of the power of the battery.

@ChrisStratton As a general rule of thumb though - PP3 + LDO + Transmitter (of any kind) = a bad mix. Change the PP3 for something with more grunt and less voltage, or swap the LDO for an efficient switcher, and things improve massively.

As a "quick fix" you could try "buffering" the power to the HM-10 with a large electrolytic capacitor (in the order of hundreds or thousands of µF).

Your whole line of reasoning here is based on a grossly erroneous guess at what these things draw.  Check the TI data sheet  if you don't want to believe me.

No it isn't. I don't give a damn what they draw. A PP3 on an Arduino with the wildly inefficient LDO can barely power itself and maybe an LED. Add even a low power transmitter and you're asking for trouble.

There are exactly two scenarios that account for "it works on usb but not battery". One is they forgot to connect the grounds between two parts of their circuit, and ground is making its way through a convoluted route via the computer. That is not the case here, since it works with a nice powerful USB powerbank. So it must be the second scenario, which is attempting to use a PP3 battery, instantly confirmed by the OP. Ergo, improve the battery and/or the regulation, and fix the problem.

It may be that the BLE is actually functioning fine but some other unspecified part of the setup is failing. It's impossible to tell from here. Suffice it to say, though, the battery is the cause of the problem, and has been many times before on Arduinos.

Take two 9 volt batteries with same specifications and connect it into the parallel by using this efficiency of current increases and it full fill the current requirement at the time of data transmission and for others modules u r using with the arduino.

While this likely wouldn't meet the OP's design requirements, it's a perfectly reasonable benchtop test to confirm that the 9v batter is (or isn't) the problem.

A PP3 battery is not a suitable power source for an Arduino.
For battery powered operations I would recommend a set of AA batteries with between 6 and 8 volts (if you don't care about bulk) or a Li-Ion battery (or two) and a suitable buck or boost (depending on number of cells) regulator to bypass the inefficient linear regulators on the Arduino.

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