Consider taking on this project in sever steps.  Some you might do now and other later if necessary
First, accelerometers do not usually need alignment.  But if accuracy and reproducibility is important, a project may benefit from finding any offset a single accelerometer may need and finding any magnitude adjustments between the three accelerometers.  Using gravity rotate each accelerometer through their maximum negative and positive values.  Use these values to find an offset such that the absolute values are equal for each individual accelerometer.  Then select one accelerometer as the bases and find the appropriate coefficients to normalize the other two accelerometers such that the absolute values of all maximums and minimum are equal.  As hinted, this is one of the step you can skip until later if necessary.  If you need a more thorough explanation you can find it in section 2 of this STMicro document.
To find angles it would be best to consider the classic airplane example where pitch (nose up or down) and roll (rotation around the axis passing through the nose and tail).  Here is a good submersible Arduino project to consider. In this project the accelerometer Z axis is pointed down and the X to the side.  To find ROLL the author calculates the inverse tangent of the negative of the ratio of acceleration in the X direction over the acceleration in the Z direction.

The pitch calculation is a bit more involved.  This can be found by taking the inverse tangent of the acceleration in the Y direction over the square root of the sum of the square of the X plus Y acceleration.

That out of the way, now consider how to zero the angles out.  First decide on if you will adjust the roll or the pitch.  Let's consider the roll case.  Record the current roll angle and subtract it from the current calculated roll angle before displaying it as zero.  Now rotate your accelerometer such that you do it around the Y axis (remember, we are only considering the roll case and do not want to change the Y accelerometer's reading!).  If you have done the math correctly, the displayed angle will be the difference between when you started and finished your rotation.
All that out of the way, now consider what would happen if you rotated your accelerometer through a roll position where the acceleration in the Z direction falls to zero.  Your trigonometric inverse tangent function for roll would go to infinity!  In the physical world, where gimbals are used for air and space navigation, this is referred to as Gimbal lock!
What to do about Gimbal lock?!  Well, it's a story that starts in 1843 (yeah, that does sound odd doesn't it WRT air and space navigation).  In short, if you stop using classical trigonometry to convert acceleration to angle an start using Quaternions you avoid Gimbal lock entirely.  Quaternions use complex numbers to describe rotation in 3D space.  People who write 3D gaming programs absolutely love how Quaternions simplify their efforts.  This is another of those steps you don't have to do.  But doing so will make your project all the more robust.
(BTW, this is the STMicro LIS3DH data sheet.)


What is the purpose of the howMany integer in the wire.onReceive() function from the example code?

It tells you how many bytes have been received, and consequently how many you can read with Wire.read().

Before you have read anything with Wire.read() Wire.available() will return the same value.  As you read from the buffer Wire.available() will decrease, but howMany will stay the same.


Finally i found the solution .

Send AT+CWMODE=1 first , then all other commands working fine.


Is there a way to reuse an old robot using arduino?

As to your question can I program in ArduinIDE - Yes.

The main chip is from AVR ATMEGA16,
the LCD is a 16x2 (pinout for use with the LCD library is enclosed)
motor driver is (Big thanks to Juraj not a mystery) a ULN2803. Example to work with can be found here.

The circuit diagram enclosed:

How to use in ArduinoIDE:

First install the driver for prolific and makes sure your OS finds the robot  (done)

Then install the MightyCore which supports ATMega16 - there are detailed instructions how to do it
Start with a blink led example (pins from the schematic) compile and upload to test
Then a simple LCD example and so on.

Another posibility would be tor scrap the bot and salvage most parts.

If its feasable the Manual will tell you which parts can be removed without soldering
To get started you need the USB drivers for OS and the original SW to test wether the QBot is still ok from a hardware perspective,
Than you can salvage the parts from it to use with Arduino:

Than you have to make a new base plate (google for pics of 2-wheel robot base plates) and get a motor driver (I recommend for a beginner a cheap motor shield like an Adafruit V2 motor shield clone 5-7$).
As you probably have downloaded ArduinoIDE latest version for your OS, get some example programs and start to play around.


Just change

void sendSMS()

to

void sendSMS(const String& thisIsAString)

You can then access the parameter inside the function with thisIsAString.
No, you do not need a prototype.


remove weird chars from char array ESP32

You forgot to add one more character to the array to place a \0 (0 value byte) in. This denotes the end of a string. If you forget this, the string will continue until it finds the first 0 byte, which will probably be after the original string copy. This can be dangerous, because it might be in memory that is not containing useful data, and those weird character can be many if there is not a 0 soon or at all.

Note that the 6 bytes you get are the bytes EXCLUDING this 0 byte, so you need to allocate 7 bytes to store a string of length 6.

Instead of the for loop you can use the strcpy function which copies a function including the 0 string.

See description:

Description

The C library function char *strcpy(char *dest, const char *src) copies the string pointed to, by src to dest.

Declaration

Following is the declaration for strcpy() function.
char *strcpy(char *dest, const char *src)

Parameters

dest − This is the pointer to the destination array where the content is to be copied.

src − This is the string to be copied.

Return Value

This returns a pointer to the destination string dest.

Example

The following example shows the usage of strcpy() function.

#include <stdio.h>
#include <string.h>

int main () {
   char src[40];
   char dest[100];

   memset(dest, '\0', sizeof(dest));
   strcpy(src, "This is tutorialspoint.com");
   strcpy(dest, src);

   printf("Final copied string : %s\n", dest);

   return(0);
}


RobotConfig.h needs to include Arduino.h in order to have those constants.


Using a MIDI connector both as MIDI In and Out (not simultaneously)

I suggest you have a look at the 4051 or 4052 chip (datasheet). The 4051 is a 1:8 analog multiplexer while the 4052 contains two 4:1 multiplexers. So basically it allows you to switch one pin on your Arduino to any out of 4 or 8 MIDI circuits.

In the case of TX, it's really simple. You just need a pullup resistor on each output so that the pins don't float when not switched to.

In the case of RX, you have to make sure that you don't miss any transmissions. If your MIDI sources are not sending simultanously, that's easy as well... but probably they are. In that case you cannot use an existing RX UART. Since MIDI is very slow, you could still switch back and forth between the inputs and catch all the bits (you would be writing a software UART then). But if you're not short of pins, it would be much easier to just use SoftwareSerial for one input.


What to use instead of a USB to serial converter

May I suggest RS232 connection? It is an ancient tech but it might work for you. I am adding a tutorial. Also a component from eBay, which is 0.99 US dolar.


How to control 19 RGB LED strips with one arduino?

You can use addressable LEDs that allow chaining from one LED to another using a serial protocol.

Like this :

This would alow you to set the first row blue, the second purple, each one can be controled independently.

Take a look at Ada Fruit's neopixels to start. These are basically skillfully branded WS2811 & WS2812 LEDs, but they are very well documented and well built. They feature 8 bit per channel RGB color (24 bit color) and take care of PWM internally. You could even chain the end of one strip to another, allowing all control to come from two pins of an arduino.

Assuming you go this route, consider the following:

You will need enough RAM to store the full array of pixels in memory, which is 3 bytes per pixel.  Alternatively, you can create a custom library with reduced bit depth, or one that stores pixels in clusters, because at the end of the day you are just operating a giant shift register.
You will need to supply enough current (60mA per led), and supply it at several points along longer strips.  You will likely need to use external power sources.  You can drive a decent amount of LEDs from Vin (before the power regulator), but not anything near 19 strips.

Now if you already have the strips, and they are analog strips, I think you can find similar drivers that output more power to drive strips, but still use a serial protocol.

You can use my example code here:

// NeoPixel Demo minimum
// By leo etchaas
// released under the GPLv3 license to match the rest of the AdaFruit NeoPixel library

#include <Adafruit_NeoPixel.h>
#include <avr/power.h>

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

// How many NeoPixels are attached to the Arduino?
#define NUMPIXELS      55

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

int delayval = 500; // delay for half a second

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

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

void loop() {

// For a set of NeoPixels the first NeoPixel is 0, second is 1, all the way up to the count of pixels minus one.

for(int i=0;i<NUMPIXELS;i++){

// pixels.Color takes RGB values, from 0,0,0 up to 255,255,255
pixels.setPixelColor(i, pixels.Color(25,255,255)); // Moderately bright green color.

pixels.show(); // This sends the updated pixel color to the hardware.

delay(delayval); // Delay for a period of time (in milliseconds).

}for(int i;i>0;i-=1){

// pixels.Color takes RGB values, from 0,0,0 up to 255,255,255
pixels.setPixelColor(i, pixels.Color(255,5,255)); // Moderately bright green color.

pixels.show(); // This sends the updated pixel color to the hardware.

delay(delayval); // Delay for a period of time (in milliseconds).

}
}


How do you figure out an efficient battery setup for a project?

Our beloved admin Nick Gammon has made a very neat articile on this subject, I suggest you read it and apply as many of the methods he described.

Also, it can be worth to check the requirements of your project, how long should it work on battery to be acceptable? Set some realistic boundarys to avoid getting lost in (trying to) optimizing beyond all practical purposes.

There are two places where you can save power:

In software

The Atmega328P has a few tricks to save power.
Most notably is powering down peripheral devices and/or using sleep modes.
I believe the P version of the Atmega328 also has more power saving modes/ is more efficient overall.

Also take a look at this.

In hardware

An Arduino board has a lot of chips that may not even be neccesary on your battery project.
Most notably the USB interface chip, if you're going to run off battery, you most likely won't need this chip.
But also, the voltage regulator on the Arduino is, I believe, a linear regulator and is likely to be inefficient.
Also power/status LED's will some current.

You can choose to put a ATMega328P on a breadboard, and power it directly with a source that will be between the min/max voltage of the ATMega328P. This way you don't get the losses that a regulator will have.
If you want to use a regulator (for a higher voltage source) you should use a switching regulator, they're typically more efficient.

Mind that on low voltages, the ATMega328P can't do a 16Mhz, but it's actually a pretty interesting point, since it will consume less power on 8Mhz, or even less on 1Mhz.


There are two baud rates you need to diagnose.  One is the baud rate the ATMega8U2 runs at, and the other is the baud rate the ATMega328P runs at.

You need to work out which one is being calculated wrong:

The ATMega8U2's baud rate is set by the USB connection when you open the port
The ATMega328P's baud rate is set by your sketch

Obviously, the two have to match.  However, a baud rate isn't just set as a number, it's calculated as a fraction of the CPU clock.

If the CPU clock on just one of the chips is different to what the firmware or sketch expects then the calculation for the baud rate will be wrong.

An example:

Your ATMega328P is expected to be running at 1MHz - however, the fuse settings have it set to run from the internal 8MHz clock.  That means everything on that chip will run 8× faster than expected, so you have to compensate with a lower baud rate.

Another example:

Your ATMega8U2 is expected to be running at 16MHz - however, the fuse settings have it set to run at 2MHz.  That means everything on that chip (except the USB which is clocked separately) will run 8× slower than expected, so you have to compensate on the ATMega328P with a lower baud rate.

So check the fuse settings on both chips. Make sure they are set to the right speeds for your firmware and boards.txt file settings.

Also, you should look at getting a cheap oscilloscope or logic analyser. That would allow you to monitor precisely what is going on with the communication between the two chips and work out if the baud rate is actually 8× faster than expected (ATMega8U2 at fault), or the normal speed but you have to specify it as a lower number (ATMega328P at fault).


Connect S0 to 5V to get 100% OUTPUT FREQUENCY SCALING.

Currently, with S0 LOW and S1 HIGH, you get 2% OUTPUT FREQUENCY SCALING. Which would explain the 50 times to low values you get (100% / 2% = 50).


Mapping segments and memory allocation on a segment LCD driver

The trick here is to employ both a local memory buffer, and digit masking.

Step one: create a pair of masks that define which bits of the memory are associated with which digit.

Imagine you have your digits wired in this order in memory. For simplicity I am working with 16-bit values, but there is no reason why you can't split them into two 8 bit values each if you find that easier (P is the decimal point. Lower case is the left digit, upper case the right digit):

      MSB                         LSB
      a C d g E B p A c D f b e G F P

You would then create a pair of corresponding 16-bit values that represent which bits are associated with each digit.

      MSB                         LSB
      a C d g E B p A c D f b e G F P
Left  1 0 1 1 0 0 1 0 1 0 1 1 1 0 0 0
Right 0 1 0 0 1 1 0 1 0 1 0 0 0 1 1 1

The right is just the inverse of the left, so for right you can actually use ~left and save yourself 2 bytes.

So that would end up as:

uint16_t leftDigit = 0xB2B8;
uint16_t rightDigit = 0x4D47;

Now you create yourself a table of which segments create which numbers. Now the magic here is that you don't want individual digits. Not yet. What you want is a table of 16-bit values that represent the numbers 00, 11, 22, 33, 44, 55, 66, 77, 88, 99 (and optionally two spaces, but that's just 0x0000, so you may not need to store that explicitly).

You may end up with something like:

uint16_t digits[] = {
    0b1110110111111010, // 00
    0b0100010010010000, // 11
    0b1011110101011100, // 22
    // ... etc ...
};

Now the real magic happens.

You need a memory buffer that mirrors the contents of your driver memory.  You don't directly modify the driver memory - you modify your memory buffer, and then send both bytes of it to the display driver at once, updating all the segments together.

uint16_t buffer = 0;

Now to set a digit you first need to erase whatever is in the bits that correspond to the digit you want.  Let's say we want to display the number 12.  We'll start with the left digit.

// Step one, erase the left digit
buffer &= ~leftDigit;
// Step two, place into it the bits for 1 with the left digit mask imposed:
buffer |= (digits[1] & leftDigit);

// Step three, erase the right digit
buffer &= ~rightDigit;
// Step four, place into it the bits for 1 with the left digit mask imposed:
buffer |= (digits[2] & leftDigit);

That is actually quite a long winded way. But it does allow you to just change one digit without affecting the other.  If you want to just replace the entire content of the display (both digits at once) then you don't need as much work:

buffer = (digits[1] & leftDigit) | (digits[2] & rightDigit);

I'll just dismantle that for you so you can see what it does.

            MSB                         LSB
            a C d g E B p A c D f b e G F P
 digits[1]: 0 1 0 0 0 1 0 0 1 0 0 1 0 0 0 0
 leftDigit: 1 0 1 1 0 0 1 0 1 0 1 1 1 0 0 0
       AND: 0 0 0 0 0 0 0 0 1 0 0 1 0 0 0 0 // b and c enabled

 digits[2]: 1 0 1 1 1 1 0 1 0 1 0 1 1 1 0 0
rightDigit: 0 1 0 0 1 1 0 1 0 1 0 0 0 1 1 1
       AND: 0 0 0 0 1 1 0 1 0 1 0 0 0 1 0 0 // A B D E and G enabled

OR of ANDS: 0 0 0 0 1 1 0 1 1 1 0 1 0 1 0 0 // b c A B D E G enabled

And map those segments on to the standard layout of a 7 segment display:

And you form the number 12.

Then you take the buffer value and write it out to your display memory.  You can split the 16 bit value into 8 bit values with bit masking (& 0xFF) and bit shifting (>> 8).

uint8_t b1 = buffer & 0xFF; // Lower byte of memory
uint8_t b2 = (buffer >> 8) & 0xFF; // Upper byte of memory


Trying to read analog signal with digital pin using outside ADC

The MCP3008 is an SPI device. You connect it to the SPI pins of your Arduino. Then you can read 8 analog channels through it.

It requires 4 pins: MISO, MOSI, SCK and a chip select pin.


Add debouncing circuitry if you can; it's not that difficult.


Somehow I managed to do it but my code is un-optimized. Please let me now if I've done something that isn't good.

I changed the content format to this so it's much easier for me. (CONFIG.TXT)

SSID%&WIFIAP001&%KEY%&PASS1234&

New Code.

#include <SPI.h>
#include <SD.h>

File myFile;
char wifiSsid[63];
char wifiKey[63];
char temp;
char settingSsid[5] = "SSID";
char settingKey[4] = "KEY";
char settingTemp[10];
char valueTemp[63];
int settingTempLastPos = 0;
int valueTempLastPos = 0;
int percentCount = 0;
int andCount = 0;
bool isSetting = true;
bool ssidValueFound = false;
bool keyValueFound = false;

void readWifiConfig() {
  Serial.println("Initializing SD card...");

  if (!SD.begin(4)) {
    Serial.println("Initialization failed!");
    return;
  }
  Serial.println("Initialization done.");
  myFile = SD.open("CONFIG.TXT");
  if (myFile) {
    Serial.println("CONFIG.TXT");
    while (myFile.available()) {
      temp = myFile.read();
      if (temp == '%') {
        percentCount++;
        isSetting = true;
        if (percentCount == 2) {
          //Serial.println(settingTemp);
          if (strcmp(settingSsid,settingTemp) == 0) {
            Serial.println("SSID SETTING FOUND");
            //IF FOUND RAISE FLAG FOR ADDING VALUE TO SSID CHAR ARRAY
            ssidValueFound = true;
            }
          else if (strcmp(settingKey,settingTemp) == 0) {
            Serial.println("KEY SETTING FOUND");
            //IF FOUND RAISE FLAG FOR ADDING VALUE TO SSID CHAR ARRAY
            keyValueFound = true;
            }
          memset(&settingTemp[0], 0, sizeof(settingTemp));
          settingTempLastPos = 0;
          percentCount = 0;
        }
      }
      else if (temp == '&') {
        andCount++;
        isSetting = false;
        if (andCount == 2) {
          //Serial.println(valueTemp);
          if (ssidValueFound) {
            //Serial.println(valueTemp);
            memcpy(wifiSsid,valueTemp,63);
            //Serial.println(wifiSsid);
            ssidValueFound = false;
            }
          else if (keyValueFound) {
            //Serial.println(valueTemp);
            memcpy(wifiKey,valueTemp,63);
            //Serial.println(wifiKey);
            keyValueFound = false;
            }
          memset(&valueTemp[0], 0, sizeof(valueTemp));
          valueTempLastPos = 0;
          andCount = 0;
        }
      }
      else {
        if (isSetting == true) { //setting
          settingTemp[settingTempLastPos] = temp;
          settingTempLastPos++;
        }
        else if (isSetting == false) { //value
          valueTemp[valueTempLastPos] = temp;
          valueTempLastPos++;
        }
      }
    }
    //Serial.println(settingTemp);
    myFile.close();
  } else {
    Serial.println("Can't open CONFIG.TXT");
  }
}

void setup() {
  // put your setup code here, to run once:
  Serial.begin(115200);
  delay(10);
  readWifiConfig();
  Serial.println(wifiSsid);
  Serial.println(wifiKey);
}

void loop() {
  // put your main code here, to run repeatedly:

}

Output:

Initializing SD card...
Initialization done.
CONFIG.TXT
SSID SETTING FOUND
KEY SETTING FOUND
WIFIAP001
PASS1234


Password.h and keypad.h change pass sketch for Arduino

The logic of your function is garbled:

Function checkpasswd(): Most of the function is ok, but you don't need to send passwd2 through Serial, since it doesn't have anything to do with this function. You only use the variable for setting a new password. You can ditch this print statement.
Function changepasswd(): Here lies the problem. Most likely getKey() returns NO_KEY here, which is defined as the null character. So, when outputting it to Serial, you don't see anything there (The null character marks the end of a string in C/C++). You set the password to be the null character, which cannot every be inputted by the user. Also there lies another pitfall: The Arduino Playground Site for the Password library states for the set() function:

  Warning: The new password should be a global variable (not a local
  function variable) as this function copies a pointer to the new
  password into the library, not a copy of the password.

Since the key variable is only local, after the function the Password library has it's internal pointer pointing to a now freed memory space. At some other point in the program this space might be written again, effectively changing to password to something else.

And lastly the function does not contain any loop, so only 1 character will be inputted and the newly set password can only be 1 character long. The buffer variable passwd2 is of type char, so also only 1 character. What you really need there is a char [] (character array).

Here is a bit of code (not tested), that should implement this correctly:

char passwd2[6]=""; //global buffer for new password
                    // 6 bytes, because a C string has to end with the null character

void changepasswd(){
    for(byte i=0;i<5;i++){
        char key = NO_KEY;
        while(key == NO_KEY || key=='*' || key=='#' || key=='D') key = keypad.getKey();
        passwd2[i] = key;
        delay(60);
    }
    passwd2[5] = '\0'; //ensure correct string ending
    passwd.set(passwd2);
}

Note the following points:

This implementation blocks the programs execution, until a full valid password has been typed. It will ignore all invalid characters, that you use for other purposes (#, * and D).
The passwd.set(passwd2) is actually only necessary the first time, we change the password, to let the Password object have a pointer to our buffer. After that we technically can change the password directly in the buffer, without calling the set() function. I included it here for readability and making the code a bit more fail prove (against wrong futher coding).
This is hardcoded to accept only 5-digit passwords. If you want passwords with arbitrary length, you can start programming from this basis.
Debouncing buttons with a simple delay() may be not enough at some point. But as I understand the source code of the Keypad library, it also includes code for debouncing, by only checking every 10ms for a changed button and returning NO_KEY everytime else.


SoftwareSerial data being corrupted - looking for suggestions

As @Juraj mentions in the comments, don't use 115200 baud with SoftwareSerial.

The problem is that the AVR isn't fast enough to handle incoming data at that speed reliably.  Yes, it can receive a byte fine at that speed, but what it can't necessarily do is store that byte away in the receive buffer in time to be ready to receive the next byte - so it misses the first few bits and corruption ensues.

Running at a lower baud rate (such as 9600 baud) simply gives it more time to process the data as it arrives.


The print function takes an array of characters as zero terminated c-string. It prints until a byte with value 0. You have zero at arr[0] so it is an empty string.

To send bytes, write function is used. The print functions convert parameters to text or expect text as zero terminated char array.

In your case it should be client.write(arr, length); where length is the number of bytes you want to send from the buffer arr.


(Neopixels) How to keep the pixels of the same colour despite increasing brightness?

I have some simple NeoPixel fading going on in this example sketch:

/*
 *
 * NeoPixels demo - fades colours (in array) up and down
 *
 */

#include <SPI.h>
#include <NeoPixels_SPI.h>

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

void setup()
  {
  ledsetup();
  } // end of setup

float patterns [] [3] = {
  { 1, 0, 0 },  // red
  { 0, 1, 0 },  // green
  { 0, 0, 1 },  // blue
  { 1, 1, 0 },  // yellow
  { 1, 0, 1 },  // magenta
  { 0, 1, 1 },  // cyan
  { 1, 1, 1 },  // white
  { 160.0 / 256, 82.0 / 256, 45.0 / 256 },  // sienna
  { 46.0 / 256, 139.0 / 256, 87.0 / 256 },  // sea green

};

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

void loop()
  {

  for (byte i = 0; i < ARRAY_SIZE (patterns); i++)
    {
    // fade up
    for (byte m = 0; m < 100; m++)
      {
      showColor (PIXELS, patterns [i] [0] * m, patterns [i] [1] * m, patterns [i] [2] * m);
      delay (10);
      } // end of for

    // fade down
    for (byte m = 100; m > 0; m--)
      {
      showColor (PIXELS, patterns [i] [0] * m, patterns [i] [1] * m, patterns [i] [2] * m);
      delay (10);
      } // end of for
    } // end of for each array item

  } // end of loop

This is using the simple NeoPixel library that I wrote using the SPI hardware. The library with the exact code above is available here.

Basically the fading is done by multiplying the floating-point values for the R/G/B values by a constant from 0 to 100 (you could make it 0 to 255).

Since the colours themselves are expressed in the range 0 .. 1 then the result of the multiplication would be 0 to 255. To my naked eye the colours seem true at all brightnesses.

To use the library on your Uno just connect +5V, Gnd, and the data pin is MOSI (D11 on the Uno).


build simple IR sensor with 220 ohm and 1000 ohm resistors

You could always start out attempting a simple IR detector circuit.

Google Arduino IR detector brings up several tutorials, such as this one from the Instructables website

You would have to change the buzzer in tutorial for an LED and resistor in series.


Renaming folders in Arduino Uno' SD card

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.


Jot provided the answer in a comment: you are updating lastMillis in
the wrong place. The correct way is:

if (millis() - lastMillis >= 1000) {
    handleFingers();
    lastMillis = millis();
}

Optionally, you can use lastMillis += 1000 instead of
lastMillis = millis() if you want to precisely control the average
(rather than minimum) update period.

Just to elaborate a bit, the idiom I like for doing this kind of stuff
is as follows:

const unsigned long FINGER_UPDATE_PERIOD = 1000;
const unsigned long WRIST_UPDATE_PERIOD  = 1000;

void loop() {
    unsigned long now = millis();

    // Handle the fingers.
    static unsigned long last_finger_update;
    if (now - last_finger_update >= FINGER_UPDATE_PERIOD) {
        last_finger_update = now;
        handleFingers();
    }

    // Handle the wrist.
    static unsigned long last_wrist_update;
    if (now - last_wrist_update >= WRIST_UPDATE_PERIOD) {
        last_wrist_update = now;
        handleWrist();
    }
}

Note that:

The update periods are constants defined at the top of the
program.
millis() only needs to be called once per loop iteration: if the
loop takes many milliseconds to run you would be doing something
wrong anyway.
last_finger_update and last_wrist_update stand for lastMillis
and lastMillis2, which are very poor naming choices.
These two variables are local to loop(), as they are not needed
anywhere else.
These variables are also declared static, which means they are
implicitly initialized to 0 and they preserve their values from call
to call.
I update the timing variables before doing the actual work. This
helps keeping all the timing code together, which makes the code
clearer, especially if the actual work takes many lines of code (e.g.
you do the work inline instead of having it in separate functions).

Some people prefer using libraries for this kind of proto-threading. If
you use the ArduinoThread library, the same could be written as:

const unsigned long FINGER_UPDATE_PERIOD = 1000;
const unsigned long WRIST_UPDATE_PERIOD  = 1000;

Thread updateFingers(handleFingers, FINGER_UPDATE_PERIOD);
Thread updateWrist(handleWrist, WRIST_UPDATE_PERIOD);
StaticThreadController<2> scheduler(&updateFingers, &updateWrist);

void loop() {
    scheduler.run();
}


The v0.9 and v1.0 NodeMCU boards have 2 LEDs: One on the AIthinker module, and one on the actual NodeMCU board.

The AIthinker module's LED is connected between Vcc (3.3V) and GPIO2 (labeled D4 on nodeMCU). It turns ON when D4 is set LOW.

The NodeMCU LED is connected between Vcc (3.3V) and GPIO16 (labeled D0 on nodeMCU).  It turns ON when D0 is set LOW.

The pin labeled RST is the Reset signal from the AIthinker module, and is active-high, meaning you connect RST to GND to put the device in a reset state.

The pushutton labeled FLASH is connected between GND and GPIO0 (labeled D3 on nodeMCU). When the this pin is LOW when the ESP8266 comes out of a reset state, the chip is in flash-bootloader mode, meaning it is ready to receive a new sketch. On a NodeMCU, however, the ESP8266 chip is placed in flash mode by the USB chip and the flashing software, so there is not a need to manually press this button.


As stated by Majenko in the comments, I thought that all MCUs analog gpios had a pullup resistor built in, so I have been able to solve the problem using an external pullup, in this case connecting a 10K resistor like in the diagram:

 .

Special thanks to Majenko for his time and patience. Cheers!


Use an H-bridge motor driver. They can use arduino signals to control higher voltages without damaging the arduino. Check out the  L298N from gearbest. It's cheap but will probably do the trick if you're not using too much current.

It can supply about 1A through each gate at 5-30V.

this video should help explain it. (I haven't watched the video but it seems like it got good feedback).


Is my MQ-2 gas sensor analog or digital?

Your sensor is analog. I have the same one. By the way, there is no chip on board, so it cannot form a digital signal ;)


What sensor would work for soccer ball detection efficiently using Arduino?

This is potentially well beyond the capabilities of a simple MCU like an Arduino UNO. So I think it is very important to clearly define the problem you're trying to solve.

Currently, at top national and international level, video cameras are used to detect a ball crossing the goal line. AFAICT, a lot of the complexity comes from having the goal keeper and several players on the line too. It is important that a player kicking across the goal line is not mistaken for the ball crossing the line. Also, it is important that players bodies can't block the view; a simplistic approach might not be able to see the ball if its kicked between a players legs.

This amounts to (probably) millions of sensors (one per pixel) being monitored at 100+ Hz.

So, I'll assume you are not trying to solve such a complex problem. Instead I'll assume you only want to detect a ball crossing the back edge of the goal line, without considering interference by players.

First, let's gather some numbers to describe the core problem.

A soccer ball/football is at least 68cm in circumference, so it is
68/pi = 21.6cm in diameter, or 0.216m, which is 0.108cm radius.

Then there is the goal. FIFA rules say "The distance between the posts is 7.32 m (8 yds) and the distance from the lower edge of the crossbar to the ground is 2.44 m (8 ft)"

So a question is, must the system detect the ball crossing the goal line at any place?

A goal is about 34 times wider than the diameter of the ball, and
just over 11 times taller. So, if the sensors were some form of 'light beam' being broken, the 'simplest' system would need more than 11 sensors looking horizontally from one goal post to the other.

How fast might the ball travel through the posts? This says Cristiano Ronaldo was measured kicking a ball at 130km/hr. That's 36.1m/s.

So the ball is going to take 0.216/36.1 = 0.006 seconds, 6 milliseconds to pass the back edge of the goal line, ie. front edge to back edge will pass a point in 6 milliseconds. This means the sensors must all be scanned, at worst, every 6 milliseconds.

For a sound based system there are more issues.

How much of the ball is 'seen', ie. if only a small fraction of the ball is 'in view' might the returned sound be too small to register with an off-the-shelf ultrasound sensor? For example, if the angle of the reflected sound is too big, ie. from the front or back of the ball, will enough reflected sound return to the sensor to be detected?

Does the ball reflect sound well? It is a membrane at quite a low excess pressure, very different from a solid wall, so I would guess it isn't a perfect sound reflector. I haven't found anything quantifying this, but it seems reasonable to assume off-the-shelf ultrasound sensors might miss the ball under some circumstances.

So it would seem reasonable to assume that two or more sensor readings of the ball would give a significantly more reliable reading than a single sensor reading.

This equates to sampling at least every 3milliseconds. That is a maximum distance of 0.34m * 3/2millisecons (round trip) = 0.5m (approximately).

This might seem to be too much of a restriction. However, the ultrasound sensor only sends a pulse of a few cycles, so it isn't able to detect the ball for the whole of that 3 milliseconds. I haven't found a spec for the off the shelf sensors, but a plausible assumption might be each pulse lasts for about 10 cycles of 40kHz, so the pulse lasts for 0.25 milliseconds. That is the time the ball might travel, about, 1cm. So the angle of reflection would not change much. Hence trying to detect the ball more frequently will increase the quality of at least one signal.

This may explain why the ball is not always detected using ultrasound sensors in your existing approach.

Using any type of sensors to detect the ball, there is a bit of a trade-off. The ball is round, and so if the sensors are almost at the balls diameter apart, then the sensors are going to need to be scanned more quickly to detect a small part of the ball (think of this as a much smaller ball). On the other hand, if the sensors are much closer so at least one gets a longer 'view' of the ball, then one is going to see something closer to the diameter of the ball, hence see it for longer, and so they could be scanned more slowly.

This adds up to a similar outcome. Increase the number of sensors so one sees the ball for a reasonable length of time, or scan the sensors much faster to have a reasonable chance of a measurement.

A 'classic' way to detect something crossing a plane (a door way or in this case the goal mouth) is with a set of laser beams (think Mission Impossible, Entrapment, etc.).

So, consider eye-safe visible-light laser pointers? They must be eye safe, which AFAIK largely implies visible light lasers as eye-safe partly depends on the eyes 'blink response'.

At the width of a goal, the laser will have spread to several cm, but should still be straightforward to detect. With some care, it might be feasible to use mirrors to reflect a beam back towards the goal post carrying the laser, halving the number of lasers, and keeping all of the wiring on one side. I don't know how many reflections might work, but it is worth experimenting as every reflection reduces the number of lasers and sensors.

One advantage of an optical approach vs sound is the goal mouth could easily be monitored at a much higher rate than the ball could possibly pass.

To discriminate between sunlight, stadium or street lights, or other sources of light, the lasers would be modulated. 5kHz is a common figure, this is well away from mains frequency. The signal should be 'low' when the laser is off, and 'high' when the laser is on. If that isn't the case, then their is signal interference, and it isn't going to work.

With a little bit of electronics at the sensors, the signals may be purely digital, so there would be no reliance on the Arduino's slow ADC; the sensors could be scanned with digital GPIO pins, with, say, all 11 sensors being scanned at 10kHz.

You may be able to achieve a similar effect using narrow angle, high-power LEDs, lenses and tubes. A reasonable lens system should be able to focus LEDs over 7.32m of the goal mouth. However, I think eye-safe laser pointers would work with simpler optics, and the mechanics and optical systems are often harder to make robust than the electronics.

Summary:
A 'raster' of eye-safe, visible-light lasers, at approximately 10cm apart, maybe with mirrors to significantly reduce the number of lasers and sensors, directed horizontally across the goal mouth, could detect a ball passing.

However, it would be confused by players across the goal line.


Referencing local libraries from higher dir levels

The problem with a relative path for an include is that it has to be relative to one of the predefined list of existing include directories. This includes:

Compiler include locations
The Arduino core files
The locations of other included libraries
The build folder for the sketch

What it does not include is the location of the sketch, so you cannot specify a location relative to the sketch itself.

Further, even if you could, the compiler wouldn't know what library it was supposed to be referencing so, while the header would be found, any source files associated with it would be ignored and linking would fail miserably.

Instead you will have to place the library in a standard library location, such as the libraries folder in your sketch book.


What happens to the board if you connect the +5V pin directly to a digital input configured as input

Will it destroy the board?

No, it will just read HIGH. That's what HIGH is - 5V.

  Cause after i did this my board doesn't work anymore

Then you probably did something else.


With that library... you can't. All the code is in one big monolithic .h file. As you well know by now that is a big no-no. The author should be given a big slap on the wrists.
The closest you could do without re-writing the whole library is to just copy the class definition from the outer .h file and create an extern to the existing object - maybe make your own copy of the ESP8266Ping.h file without the #include "ESP8266Ping.impl.h" and PingClass Ping; (the latter of which you change to an extern).


What is this temperature sensor module? (LM358, 103)

"103" is standard resistor (and other component) numbering - the first two digits specify a value and the third is a power-of-ten multiplier:

1 0 3 = 10 * 10^3 = 10K

4 7 2 = 47 * 10^2 = 4.7K

For devices that are typically measured in thousandths, millionths or smaller (like a capacitor) then the third digit is a minus power-of-ten:

1 0 6 = 10 * 10^-6 = 1u

That black disc labelled '103' is a thermistor - a temperature-controlled resistor. It is most likely NTC, or negative-temperature coeffiecient, thus the resistance decreases as the temperature increases. This is contrary to typical physics where an increase in the temperature of a generic conductive material results in an increase in its electrical resistance.

The LM358 is included to buffer the thermistor from the Arduino/microcontroller. In simple terms, this means that the effective resistance of the analogue input pin does not have to be taken into consideration when converting the voltage measured to into a value for the temperature.

Without a better picture of both sides of the board, or better yet a circuit diagram, it is not possible to determine what the voltage on pin S will be for a given temperature. However, it seems that the thermistor is in series with another 10K resistor (R3, marked '103' of course) such that an increase in temperature results in an increase in voltage. At roughly 20 degrees Celsius (it depends on the manufacturer and their specifications) the resistance of the thermistor will be 10K, thus the voltage at S will be Vcc/2. Calculating the voltage for different temperatures requires you to know the temperature coefficient, which can be found from the datasheet or by measuring the resistance at various known temperatures and plugging those values into an equation.


unable to read RS232 output on Arduino mega with MAX232 shield

I have solved the above and will share the answer as it may be of help to others:

As the Tx indicator LED on the RS232 shield would not light up when connected to the sensor, I checked the voltage difference between pin 2 (Tx) and pin 5 (GND) of the RS232 connector. This turned out to be only 5V, indicating that the protocol used is TTL-RS232 rather than 'true' RS232.

Due to the low voltage, I have connected the RS232 Tx and GND pins directly to the Arduino. With Tx connected to digital port 10, I used the SoftwareSerial library with logic inversion to read the data: SoftwareSerial mySerial(10, 11, 1).

This works!


What difference makes resistance of thermistors?

The standard way to measure a resistive sensor is to make a voltage
divider with the sensor and a fixed resistance between Vcc and GND, like
this:

Vcc
 │
 Rb
 │
 ├─── analog input
 │
 Rx
 │
GND

where Rx is the resistance you want to measure and
Rb is a known bias resistance. The only unknown is the choice
of the bias resistance.

The simple rule of thumb is to choose a bias resistance close to the
typical values of the resistance you want to measure, as this will
optimize your measurement resolution. More specifically, the relative
measurement resolution, which could be stated as the number of ADC steps
you get per percent change in resistance, is maximal when Rx
= Rb, and decreases only slowly as Rx gets
further from Rb.

Now, one could argue that the relative resistance resolution is not
always the best performance metric. You may want to maximize the
absolute resistance resolution instead, or maybe the absolute
conductance resolution. Each of these choices would lead to a different
choice of bias resistor. For the case of a thermistor, however, the
choice is pretty clear: the resistance varies almost exponentially with
temperature, which means that the absolute temperature variations are
practically proportional to the relative resistance variations. If you
want to use temperature resolution as a metric, you could go through a
tedious calculation only to find out that the optimal Rb is
darn close to Rx.

In short, if your thermistor is 1 kΩ at 25 °C, and you will
use it near 25 °C, then a 1 kΩ pullup will give you the best
temperature resolution.

Now, measurement resolution may not be the only issue you care about,
and you may want to sacrifice some of it in order to improve something
else. For example:

Current consumption: a 1 kΩ thermistor in series with a 1 kΩ
pullup will draw 2.5 mA (assuming Vcc = 5 V), which
could rise to near 5 mA if it gets really hot. If you are running
off battery power this could be an issue.
Self heating: in that 1 kΩ + 1 kΩ configuration, the
thermistor will dissipate 6.25 mW. I've seen the datasheet of a
typical thermistor stating a thermal dissipation constant of
7 mW/K. This means the measurement current would heat the
thermistor to 0.9 °C above ambient temperature, which you would
need to take into account in your temperature calculations.

Both of these issues would be mitigated by using a larger value for
Rb, only at the cost of measurement resolution. Switching to
a 10 kΩ thermistor would mitigate these issues without sacrificing
resolution.


Motor controller for 24v motor, Arduino Uno

try this Arduino Compatible Mega Motor Shield. Specs:

Low-cost robust H-bridge ''shield'' for Arduino
Provides the ability to control up to 30A of current at up to 28V
Supply voltage: 5V to 28V (24V max battery rating)
Continuous output current: 13A
Have, a look:


NRF24L01+ how much supply ripple is acceptable?

I would suggest using a different power supply, that appears to be your problem.  250mV is 1/4 of a volt, that is a lot of noise/ripple.  I am assuming it is ripple from the AC mains.  The series resister is way to large, try something about 0.1 ohm.  Also put a filter cap on the load side of the resister.  If you have high frequency noise add a 0.01 cap that will help.  Be sure the grounds between the units are solid.

Gil

I have a feeling it is narrow fast rising spikes.  If so the odds are very high it is the power supply.  Can you try an analog one and see if the problem goes away?  Try adding more bulk capacitance, at the rate of at least 1000uF per amp.


Some generic techniques you can try:

Remove duplicate code and put it in a function.
If you have duplicate code that is ALMOST duplicate, parameterize it (i.e. add a function, make the difference a parameter(s) of the function and call from various locations with different argument(s).
Use a micro controller with more Flash memory.
Minimize the data storage, limiting array sizes for example (if these are in flash RAM).
If you use precalculated arrays, remove them and create a function calculating them real time (this will be a performance cost of course).
Check for dead code inside functions. A smart compiler will already remove uncalled functions, but do not check inside functions.
Remove or minimize debug/print statements. Each character cost a byte, which adds up quickly with many strings.
Try to remove complete libraries, like removing the Serial for print statements used only for debugging.


Arduino library not working, can't find header

You spelled the header filename wrong:

#include "SegDispaly.h"

should be:

#include "SegDisplay.h"

You have also made the same mistake in the class name multiple places in SegDisplay.cpp.


Reading the audio signal from a smartphone

No. It partly depends on the phone, but most put out a low voltage AC signal. This would drive the Arduino inputs negative. You can do this by biassing the input at the mid point (+2.5V) and feeding audio in via a capacitor. There are many projects which use similar to record audio.

PS I would not recommend cutting a headphone cord. The wires are very fine, and almost impossible to solder. If you want to do this make a custom cable.


After trying  a lot of things i got it working.
And even the contrast is working directly on the pwm signal.

#define F_CPU 16000000UL
#include <avr/io.h>
void main(void){
    DDRB = 0x06;
    OCR1A = 200; //Duty cycle for PB1 ~80%
    OCR1B = 100; //Duty cycle for PB2 ~40%
    TCCR1A = 0; //Set TCCR1A to zero. We will configure it manually
    TCCR1A |= (1 << COM1A1) | (0 << COM1A0) | ( 0 << COM1B0) | (1 << COM1B1);
    TCCR1A |= (0 << WGM12) | (0 << WGM11) | (1 << WGM10);
    TCCR1B = 0; //Set TCCR1B to zero. We will configure it manually
    TCCR1B |= (0 << CS12) | (0 << CS11) | (1 << CS10);
    while(1){

    }
}


How to assign text stored in a local file to a string at compile time

I found another way to include a literal file (html, css, or other) and assign it to a constant string without resorting to make files:
Add one line of code on top of your html (css, js, etc) file, and another at the bottom, and save it with an extra .h extension. Then include that file in de Arduino IDE.
This could easily be done by a (manually executed) script, every time those files are changed.
const char *indexHtml = R"====( // added by script
<html> <!-- original .html file -->
.
.
.
</html> <!-- end .html -->
)===="; // added by script

The variable name can be derived from the original filename. The result is saved with an extra .h extension. In the .ino (or .cpp) you can then include this file:
#include index.html.h

This will compile in the Arduino IDE.


What should I use Arduino-Mega or Rasbeery pi?

A RaspberryPi is essentially a small, low-spec computer. It is mostly an overkill for many small projects. Imagine using a super high-spec computer to play Minecraft. It's just nonsensical.

I'm assuming you'll be connecting to the car battery? Take note of the power requirements of your project. The RaspberryPi has a power requirement of 2.1A at 5V (which is a lot!), whilst an Arduino has a minimum requirement of 250mA.

Also remember: the RaspberryPi is running an operating system in the background in order to run your code. It will be working on numerous other operations and programs, not just yours. The Arduino will only run your program.

I had a similar project to what it sounds like you're doing. I used an Arduino Mega and had Bluetooth, GPS, and SD card all connected to it. The project worked absolutely fine, and I had lots of spare program space left over should I wish to expand on it. For reference, feel free to explore.


Unable to compare two integer values in Arduino Mega

You should use

 int x = XX.toInt()

Without the int x = part, the string is converted and the result (the integer) is not used.

Also comparing strings should be done with the strcmp function. The problem is that if you compare two strings, you compare the pointers to those strings and two strings can have equal texts but (probably) not equal addresses.


In general, you don't want to be copying strings around when you don't have to because it's inefficient. For parsing things like command lines, you can often just work with the existing String (or better yet, string; see Majenko's tutorial).

In this particular example, you have a string and you want to know if it's an HTTP GET command. That's simple enough; the first four characters will be GET (we check the space on the end because we don't want to interpret GETMORE /foo as a GET command).

This is extremely easy:

String s = "GET /foo/bar";

if (s.startsWith("GET "))
    Serial.println("GET command");
else
    Serial.println("Not GET command");

For stuff in the middle of a string you obviously can't use startsWith, but there are other functions that can help. For example, once you know it's a GET command, you know that the URL starts at position 4 (the 5th character, since counting starts at 0). You could test to see if it starts with '/foo' with

if (s.indexOf("/foo") == 4)
    Serial.println("Path starts with /foo.");
else
    Serial.println("Path doesn't start with /foo.");

That said, while this kind of thing is workable for quick tests, in the long run you probably want to move towards parsing in C in the way that Majenko's tutorial above talks about, and likely parsing as much as possible as you do the reading (rather than reading everything into memory and then parsing it) due to HTTP requests being relatively large compared to the memory you have to handle them.


Unable to use RGB matrix and the serial monitor at once

According to Adafruit https://learn.adafruit.com/32x16-32x32-rgb-led-matrix/overview these led matrixes require active scanning. It means that the RGBMatrixPanel will set up some scanning interrupt to refresh the screen periodically.

This can very much interfere with serial receive, as according to Adafruit, the panels require a serious data transmission all the time.

Try the followings:

have one byte serial commands, e.g. N for "on" and F for "off" (I know you will need more complex commands, but this is just to verify the theory)
remove all debug Serial.printlns (those also consume some time)

So try this:

void loop() {
  if (Serial.available() > 0) {
    char incomingByte = Serial.read();
    if (incomingByte=='N') {
       matrix.drawPixel(0, 0, matrix.Color333(7, 7, 7));
    }
    if (incomingByte=='F') {
       matrix.drawPixel(0, 0, matrix.Color333(0, 0, 0));
    }
  }
}


When motors stuck their current draw increases, you can sense that increase in the current and then change the rotation of the motor. The simplest way to measure current is with using a shunt resistor, for sensing high currents, current sensors based on hall effect sensors is usually used. ACS712 is one example.

How to sense current using a shunt?

Basically we're measuring the voltage drop over a resistor (RS), but the voltage drop is too small for Arduino to measure so we need an opamp to "amplify" the input:

simulate this circuit – Schematic created using CircuitLab

The schematic above is the simplest way to measure the voltage drop at "LOW SIDE", there is differential mode and "HIGH SIDE" measurement methods.

The gain of opamp can be set with resistors and this formula:

VOUT = (1 + R2/R1) * V1

The output of opamp then can be calculated to get current using ohm's law:

I = V / R

A simple code to calculate current:

int rawAnalog;
float voltageDrop;
int resistor = 0.1;
float current;

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

void loop() {
  rawAnalog = analogRead(A0); // Read A0 input
  voltageDrop = (rawAnalog * 5) / 1024; // Convert the raw value to voltage
  current = voltageDrop / resistor; // calculate the current
}

Bonus: INA219 is an easy to use high-side I2C module which can measure both current and voltage.


How to make two wheels turn only for a particular amount of time?

Use the delay() function.

Pseudo code as follows:

1) Turn clockwise motor on;
2) Turn counterclockwise motor on;
3) delay(<time>);
4) Turn CW motor off;
5) Turn CCW motor off.


How to manage two alarms with one interrupt?

Consider it is good practice to leave as little code in an interrupt as possible.  In this case, as the time in question is much greater then how often the loop() function is called, setting a single flag indicating an interrupt occurred would be sufficient.

Each time in your loop() function test for this flag.  If TRUE, immediately set it to FALSE so as not forget to do so later.  Next, while still in the scope of the IF statement, assuming the RTC DS3231 has been configured to create an interrupt every 30 minutes, take your "30 minute sample".  Next, while still in the scope of the IF statement, increment a counter.  Make sure this counter is defined as a global variable in order to persist between calls to the loop() function.  If this counter has reached the value of 2, clear this counter to zero and take your "60 minute sample".

Consider the following pseudo code:

// Global variable defined outside of functions to track state & time.
bool state_interrupts;
int counter_interrupts;

void setup()
{
  // Initialize RTC to generate an interrupt once every 30 minutes.
  <RTC initialization code.>
  // Call attach interrupt to identify interrupt function name "wakeUpNow".
  attachInterrupt(...)
  // Initialize state & counter;
  interrupts_state = false;
  interrupts_counter = 0;
}

void loop()
{
  // Check if interrupt occurred.
  if(interrupts_state)
  {
    interrupts_state = false;
    interrupts_counter++;
    // Sample 30 minute sensor.
    <Sample 30 minute sensor code.>
    if(interrupts_counter >= 2)
    {
      interrupts_counter = 0;
      // Sample 60 minute sensor.
      <Sample 60 minute sensor code.>
    }
  }
}

void wakeUpNow()
{
    interrupts_state = true;
}


Arduino Nano joystick x2 / potentiometer

Yes, this should work. The potentiometer slider will source about 5mA and each joystick axis about 50mA. In total this gives you 205mA. Here it is important, that your power source can provide enough current. If you are using an USB port from your computer, this would result in 500mA maximum that can be drawn from the bus. Since this is shared with the Arduino you can externally use about 400mA

For more information about current ratings refer to this question

EDIT: Since your previous resistance values were not correct, I edit my answer.

When all potentiometers have 10kOhm resistance (and this seems to be more likely the right values), each one draws about 5mA from the 5V pin (You can calculate this with Ohm's Law U = R * I, which gives you I = U / R. So you have to divide the voltage by the resistance.). So you aren't getting anywhere near the problematic currents. These potentiometers are designed this way. They don't want to draw a high amount of power, but only setting a certain voltage to the output pin.


So a quick feasability assessment:

2592 W * 1944 H * 10 bit = 50388480 bits

50388480 bits / 8 bit data bus = 6298560 packets

84000000 clocks per second / 6298560 packets = ~13 clock cycles per packet

I think that by itself, from a purely data perspective, without looking too deep into datasheets, you could feasibly read data from a port and push it out the USB port, and clock the data in less than 13 cycles. But what this means is you'd have to get into the nitty gritty of the processor and figure out how to do that as low level as possible because DigitalRead() and Serial.print() aren't going to cut it as they won't be fast enough.

The real challenge is that the above totally depends on being able to clock the data from the sensor yourself, which if I recall correctly, these sensors can actually be pretty picky about their clock.

I would highly recommend a FIFO, that way the sensor data can be clocked to it as fast as it wants to be clocked, and then you could read from the FIFO at your own pace as it will clock data out at exactly the rate you want it. Also 1 FPS is a pretty lofty goal if you are only a beginner. Like I said, it is probably possible, but it requires a lot of optimizations and planning that are not very straightforward to implement, especially if you are just starting out.


You probably used a direct upload button that uses default Arduino programming using RX TX, not the programmer you had selected.
All wirings are perfect that's why you were able to burn the bootloader.
Now you just need to go under Sketch -> Upload Using Programmer.


Difference between simple wifi transceiver and arduino yun

The nRF24L01+ modules aren't WiFi. They cannot talk to a WiFi router or the internet. They can only talk to other nRF24L01+ modules. They are good for connecting two or more UNOs together.

The Yún has a full WiFi connection and is also able to operate as a router itself. It is best suited when you need to run complex networking on an Arduino.  To access the WiFi on the Yún you need to communicate with it over the in-built serial connection. There are libraries to help you, but the overall package is really very much overkill unless you have a requirement to do complex network routing (VPN for instance) or run software (say a Python program) directly on the Linux portion of the device.

It sounds like what you are really after for your project is an Arduino UNO and WiFi shield.

Another popular option is the ESP8266 modules.  These can be controlled through serial using AT commands, or directly programmed using the Arduino-compatible core available from https://github.com/esp8266/Arduino


My Arduino got stuck and continuous looping in if condition

What is being brought to your attention is the following part of your code...

//here is my problem>>>>

if(now.Hour() == 22 && now.Minute() == 40)
{
  Servo1.write(0);
  delay(1000);
  Servo1.write(90);
  delay(1000);
}

In this code you use an "if" statement and ask:
   if the now.Hour is equal 22 AND if the now.Minute is equal 40 then
    write a 0 to your servo then
    delay for 1000
    then write a 90 to your servo
    and wait another 1000

What is being brought to your attention is that until now.Hour changes or
until now.Minute changes your write 0, delay, write 90, delay will continue
on and on and on until now.Hour changes (which will take a while) or now.Minute
changes. Since minutes are 60 seconds long your code will repeat for all of those
60 seconds...

If you were to change your code to include, oh, lets say now.Second() (like this)--

if(now.Hour() == 22 && now.Minute() == 40 && now.Second() == 00)

Then your code will repeat over and over until now.Second changes (which will take 1 second).

By the time your loop gets back to the "if" statement now.Second will no longer be 00 and it will not be "stuck" for you...

As has been brought to my attention, your 5 second delay will be a problem, so you might find that changing it will allow the now.Second "fix" to work.

In the following part of your code change delay(5000)

void loop ()
{
    RtcDateTime now = Rtc.GetDateTime();

    printDateTime(now);
    Serial.println();
    delay(5000);
}

to something like delay(1000) or so.

That way it will only wait 1 second before dropping out of the loop and checking the loop with the newly added now.Second(). This will make the printDateTime(now) happen every second instead of every 5 seconds, but it shouldn't get "stuck".

Hopefully this helps you to better understand how time (and its parts) work.


Interfacing Arduino Leonardo with PCA8574AN

tl;dr: It seems like you need to send a null bit (0) to terminate the communication with this board.

In the downloads section, I found a .nxc file, which I assume is a NXT code file.

In the main loop, they configure the I2C port and a "touch sensor" (I believe this is to figure out how to synchronize the text with the motor). In that, there is a main loop in which they call DispLetter.

This is the DispLetter function:

void DispLetter (const byte & letter[])
{
  int nbytes;
  // Wait for the end of previously sent data
  while(I2CStatus(I2Cport, nbytes)==STAT_COMM_PENDING);
  // Write buffer to send to PCF8574
  byte WriteBuf[];
  ArrayBuild(WriteBuf, I2CAddr8574, letter);
  for(int i=1; i<ArrayLen(WriteBuf); i++)
  {
     WriteBuf[i] ^= 0xff;
  }
  I2CWrite(I2Cport, 0,  WriteBuf);
}

Let's read this code! First of all, it seems to make sure that the I2C port is connected, which we don't really have to worry about in our case since that's platform-specific.

After that, they create an array called WriteBuf[] that will store the data to be sent to the controller. Then we come across a function called ArrayBuild. Looking that up, it combines I2CAddr8574 and letter and places it into the WriteBuf array. (Click here for documentation for that function.) Please note that the I2CAddr8574 is just a byte containing 0x70 (the address of the chip), so we will not have to do this step since the Arduino handles the address. So, you will just have to send the letter array to the controller, ignoring the WriteBuf and ArrayBuild!

Let's figure out how letter is passed. In the main loop, they had this code:

DispLetter(L_);
DispLetter(E_);
DispLetter(G_);
DispLetter(O_);

That must display "LEGO." Let's figure out what L_ is defined as. At the beginning of the document, they have this defined:

// Display patterns
// Each byte represents a column of dots
// Bit set to 1 means lit LED.
// Least significant bit is at top of column.
// Last byte must be all 0
// Maximum number of bytes par pattern: 15

byte L_[] = {0xff, 0x80, 0x80, 0x80, 0x80, 0x80, 0x80, 0x80, 0};
byte E_[] = {0xff, 0x89, 0x89, 0x89, 0x89, 0x81, 0x81, 0};
byte G_[] = {0x7e, 0x00, 0x81, 0x81, 0x81, 0x81, 0x91, 0x90, 0x72, 0};
byte O_[] = {0x7e, 0x00, 0x81, 0x81, 0x81, 0x81, 0x81, 0x00, 0x7e, 0};

byte La_[] = {0x80, 0x80, 0x80, 0x80, 0x80, 0x80, 0x80, 0xff, 0};
byte Ea_[] = {0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0};
byte Ga_[] = {0x72, 0x90, 0x91, 0x81, 0x81, 0x81, 0x81, 0x00, 0x7e, 0};
byte Oa_[] = {0x7e, 0x00, 0x81, 0x81, 0x81, 0x81, 0x81, 0x00, 0x7e, 0};

byte N_[] = {0xff, 0x01, 0x02, 0x04, 0x08, 0x10, 0x20, 0x40, 0x80, 0xff, 0};
byte X_[] = {0x80, 0x41, 0x22, 0x14, 0x08, 0x14, 0x22, 0x41, 0x80, 0};
byte T_[] = {0x01, 0x01, 0x01, 0x01, 0xff, 0x01, 0x01, 0x01, 0x01, 0};

As you can see, they listed out how the dots are configured. There's a max of 15 bytes (I assume including the null bit).

There's one more piece of code that we haven't talked about:

for(int i=1; i<ArrayLen(WriteBuf); i++)
{
   WriteBuf[i] ^= 0xff;
}

So it goes through each bit, and does something to it. That is the shorthand for this:

WriteBuf[i] = WriteBuf[i] ^ 0xff;

No, that is not an exponent. That is an exclusive OR, a bitwise operator. A bitwise operator is basically where it "overlays" the two binary sequences and it does a special computation on them. If the nth bit of each input number is 1 or the nth bit of each input number is 0, the nth output bit is 0. If the nth bit of one input number is 1 and the nth bit of the other input number is 0, then the nth bit of the output is 1.

Since 0xff = B11111111, it will essentially reverse the values of each bit. You can avoid this if you say that a bit set to 0 is on, instead of a bit set to 1 (like they do in the example code). A minor adjustment that just makes your life a bit easier :)

After that, you can write that array to the I2C bus and it should display the data!


Module and library for self healing large sensor network

A few thoughts:

For ~$20 per unit, the 1mW Digimesh modules will take care of reliable mesh networking plus provide a high degree of configurability and scalability. Depending on the budget for your sensor nodes this might be better than "wasting a ton of time" messing with bare-bones hardware and third party code.
Constrain the mesh network within the "monitoring area" and set up dedicated point-to-point links (with higher power and directional antennae) between it and your office. Set up two or three if you want redundancy.
If you can't afford better hardware but have time to spare, consider reading up on mesh protocols and implementing one you think best fits your project. Many of them are reasonably simple if you are not pushing for maximum efficiency or performance.


give a class's function name as a parameter

CRGB::Red, etc, are just numbers. You need to treat them as such.

uint32_t colorPallette[2] = { CRGB::Red, CRGB::Blue };

And then:

leds[0] = colorPallete[0];

From pixeltypes.h:

/// Predefined RGB colors
typedef enum {
    AliceBlue=0xF0F8FF,
    Amethyst=0x9966CC,
    AntiqueWhite=0xFAEBD7,
    Aqua=0x00FFFF,
    Aquamarine=0x7FFFD4,
    Azure=0xF0FFFF,
    Beige=0xF5F5DC,
    Bisque=0xFFE4C4,
    Black=0x000000,
      ... etc ...
} HTMLColorCode;


How to use tinygps.h library to measure distance? using NEO6mv2

You don't use the tinygps.h library to measure distance. You use the tinygps.h library to get coordinates. Over short distances those coordinates (longitude and latitude) can be equated to x,y coordinates on a plane (over greater distance - hundreds or thousands of miles - it gets a whole lot more complex).

Two sets of x,y coordinates form a line. A line is one side of a right-angled triangle (the hypotenuse).

Pythagoras (remember him from math class? That rubbish you thought you'd never need? Well, now you do...) says that the square of the hypotenuse is equal to the sum of the squares of the other two sides.

You know the other two sides - they're just the difference between the two x coordinates and the two y coordinates.

We're not going to write the code for you, and Google is probably better at finding websites with example code on than we are.


Passing HardwareSerial and SoftwareSerial as a Class Property

A base type for Arduino hardware serial classes, SoftwareSerial and other software serial classes and some other Arduino classes is Stream (reference). Stream.h on GitHub

class CustomSerial {

private:
  Stream &stream;

public:
  CustomSerial(Stream &_stream) : stream(_stream) {}

  int read() {
    return stream.read();
  }

  int available() {
    return stream.available();
  }

  int peek() {
    return stream.peek();
  }

  void write(byte b) {
    stream.write(b);
  }

};

SoftwareSerial Serial0(10, 11);
CustomSerial SerialCus(Serial0);

void setup() {
}

void loop(){
  if (SerialCus.available()) {
    char c = SerialCus.read();
    SerialCus.write(c);
  }
}


4-digit 7-segment display resets when common pin set to HIGH

This should work (sort of). It will be flickery, but it should give you a starting place to work from.

int A = 2;
int B = 3;
int C = 4;
int D = 5;
int E = 6;
int f = 7;
int G = 8;
int P = 9;

int D4 = 10;
int D3 = 11;
int D2 = 12;
int D1 = 13;

void setup() {

  // put your setup code here, to run once:
  pinMode(A, OUTPUT);
  pinMode(B, OUTPUT);
  pinMode(C, OUTPUT);
  pinMode(D, OUTPUT);
  pinMode(E, OUTPUT);
  pinMode(f, OUTPUT);
  pinMode(G, OUTPUT);
  pinMode(P, OUTPUT);
  pinMode(D1, OUTPUT);
  pinMode(D2, OUTPUT);
  pinMode(D3, OUTPUT);
  pinMode(D4, OUTPUT);

}

void loop() {
  // put your main code here, to run repeatedly:

  digitalWrite(D1, LOW);
  digitalWrite(D2, HIGH);
  digitalWrite(D3, HIGH);
  digitalWrite(D4, HIGH);

  //0
  digitalWrite(A, HIGH);
  digitalWrite(B, HIGH);
  digitalWrite(C, HIGH);
  digitalWrite(D, HIGH);
  digitalWrite(E, HIGH);
  digitalWrite(f, HIGH);
  digitalWrite(G, LOW);

  digitalWrite(D1, HIGH);
  digitalWrite(D2, LOW);
  digitalWrite(D3, HIGH);
  digitalWrite(D4, HIGH);

  //1
  digitalWrite(A, LOW);
  digitalWrite(B, HIGH);
  digitalWrite(C, HIGH);
  digitalWrite(D, LOW);
  digitalWrite(E, LOW);
  digitalWrite(f, LOW);
  digitalWrite(G, LOW);

  digitalWrite(D1, HIGH);
  digitalWrite(D2, HIGH);
  digitalWrite(D3, LOW);
  digitalWrite(D4, HIGH);

  //2
  digitalWrite(A, HIGH);
  digitalWrite(B, HIGH);
  digitalWrite(C, LOW);
  digitalWrite(D, HIGH);
  digitalWrite(E, HIGH);
  digitalWrite(f, LOW);
  digitalWrite(G, HIGH);

  digitalWrite(D1, HIGH);
  digitalWrite(D2, HIGH);
  digitalWrite(D3, HIGH);
  digitalWrite(D4, LOW);

  //3
  digitalWrite(A, HIGH);
  digitalWrite(B, HIGH);
  digitalWrite(C, HIGH);
  digitalWrite(D, HIGH);
  digitalWrite(E, LOW);
  digitalWrite(f, LOW);
  digitalWrite(G, HIGH);
}


Arduino Uno won't upload code and overheats

The fact that it doesn't blink the LED when plugged in or reset indicates that the bootloader of the main microcontroller no longer works.
The fact that the computer no longer recognizes the board as a serial port means that the USB-to-Serial interface doesn't work.
The fact that it heats up tells you that at least one of the chips on the board is dead.

I'm afraid that you'll have to get yourself a new Arduino.


You're actually entering into a very tricky and difficult area.

Yes, having a plain text password in your sketch is a risk. It is stored in flash as plain text. If an attacker can gain access to the contents of the flash through some means (whatever they may be) then they could obtain that WiFi password.

You would think that encrypting the password would be the answer, but that's not the case. The problem with an encrypted password like this is it has to be decrypted to use it. That means that both the encrypted password and the encryption key are both stored together in flash. If you can get one you can get the other, and thus the encryption is null and void.  Encryption security relies on keeping the encrypted data and the key used to encrypt/decrypt it completely separate. After all, you don't leave the key to your house in the front door lock when you go out, do you? It's exactly the same.

So what do you do?

Well, there's lots of different ways of looking at security. In this case there is one specific viewpoint that works best:

Security Through Obscurity

Your system is (pretty much) unique. Nobody but you knows just what it does and how it does it, or how you interact with it. It's not obvious to the casual observer just what it is or what could be done with it. That means that they won't know how to break in to it.

The majority of use of vulnerabilities in systems rely on those systems being ubiquitous - that is, all over the place; easy to obtain. In short, easy to find out what they are, how they work, and even reverse engineer them to a certain extent. Attackers aren't going to be able to do that with your system, since you are the only person in the world with it.

However, it's far from perfect, and you shouldn't rely only on Security Through Obscurity.

Simple obfuscation of the password (not actual encryption, but just storing it in a way that isn't obvious) can help, since it isn't then easy to see where in a memory dump the password would be. Splitting it up and scattering it around the place, too, can be useful.

Basically there is no simple answer, other than make it as hard for an attacker to find sensitive things as possible and don't tell anyone what you have done to hide it ;)


Receiving serial data in acsii, how to split it.

This:

if (Serial.read() == le)
{ }

looks very suspicious - sometimes it can read the C or L and therefore render the rest of your code useless.

Also Serial.parseInt shall be avoided - it returns the first thing which looks like a number, and will not wait for all three numbers.

However, your problem is likely the DMX write speed. While the DmxSimple.write is getting executed, no new incoming message can be processed. Depending on your actual Arduino board and chip, there is some buffer, but the solution is not rocket-proof at all.

You can:

make a solid protocol between the PC and the Arduino, i.e. the PC sends one command, arduino sends it out over the DMX, and Arduino answers an OK to the PC. The PC will not send out any new command unless it has received an OK first.
avoid these ad-hoc mess, i.e. serial-reads and serial.printlns here-and there.

For example, if you change the protocol so: CxxxLxxxE (E stands for end) you can utilize readStringUntil to read the input until a separator, and then use the toInt method to actually convert the read data to integer:

void loop() {
    strDummy = Serial.readStringUntil('C');
    strC = Serial.readStringUntil('L'); // xxx from CxxxL
    strL = Serial.readStringUntil('E'); // xxx from LxxxE
    channel = strC.toInt();
    value = strL.toInt();
    DmxSimple.write(channel, value);
}

After learning that it is not possible to change the protocol, here is a new plan

int channel;
int value;
void loop() {
    if (Serial.read()=='C') { // wait for a C
        channel=Serial.parseInt(); // parse till first non-number
        value=Serial.parseInt(); // parse till first non-number
        DmxSimple.write(channel, value);
    }
}

See https://www.arduino.cc/en/Tutorial/ReadASCIIString for a tutorial. Note that Arduino Serial commands are pretty confusing sometimes :) for example, parseInt will actually consume one non-number character implicitly after parsing a number.

Also note that this solution works well if the command is sent as one batch. If you are trying to send the command manually, e.g. from a terminal window, character by character, parseInt may time out. Consider increasing the timeout to 10 seconds or more by https://www.arduino.cc/en/Serial/SetTimeout


Calculate absolute time based on cycles and RTC

In general, the idea is sound.  But there are problems with some of the details and tuning.

The most important detail:  Use the correct data type for storing and computing with time variables (like time, checkPointMillis and checkPointRTC).  The correct data type is unsigned long (or, equivalently, unsigned long int or uint32_t).

A second detail:  Rather than storing your calibration correction in two variables which you always use as a difference (in effect, checkPointRTC-checkPointMillis) just compute and store the difference.  For example:

...
unsigned long clockCorrection;
...
unsigned long time = millis() - clockCorrection;
...
clockCorrection = getRTCTime() - checkPointMillis;

This will save a few bytes of RAM and a few cycles of computation.

A third detail:  If outside of the ISR you will need to access any of the values computed in the ISR, declared their variables volatile.  Example:

volatile unsigned long time;

Fourth: If getRTCTime() or any of your sensor-reading code use interrupts, you will need to move such code out of the “timer interrupt at 20Hz” section, into (for example) loop(), triggered by a volatile variable going true.  [That's the model under which the balance of this answer was conceived; I overlooked, at first, the “timer interrupt at 20Hz” label.]  Note that millis() itself does not use interrupts.  But if your 20-Hz ISR runs longer than a millisecond, the millis() total will drop one millisecond per millisecond of additional ISR time.

By tuning, I refer to the number of measurement intervals to wait between recomputing the clock correction.  Under reasonable assumptions, the number of compute cycles is so closely the same with a one second interval versus a ten minute interval, that one probably should use only a second (or at the outside, a minute) interval between clock correction computes.

For example, suppose the total number of cycles awake per second is given by the following equation:

  a = 20*s + 1000*t + k * r

where s is the number of cycles used per sensor-set reading and recording; t  is the number of cycles used per clock interrupt; k is the number of clock correction computes per second; and r is the number of cycles used per clock correction compute.

For example, if s is 2000, t is 100, and r is 200, the equation becomes

  a = 20*2000 + 1000*100 + k * 200 = 140000 + k * 200

Now consider three cases: k equal to 20, or 1, or 1/600, corresponding to a clock correction compute 20 times per second, or once a second, or every 10 minutes:

   k           a
  20        144000
   1        144200
1/600       144000.3

As you can see, under the assumptions s is 2000, t is 100, and r is 200, there is no compelling reason to prefer 1/600 corrections per second to one  correction per second.

If your RTC can be read reliably and quickly, reading it either every time (ie 20 per second) or every second has other advantages:  you compensate more quickly for MCU clock drift (ie, every second, rather than every 10 minutes) and strongly decrease the risk of out-of-order times.

For example, if your MCU clock drifts 2 seconds fast per 10 minutes, readings taken during the first two seconds of each new 10-minute interval would show smaller times than those taken during the last two seconds of the previous interval.  With secondly corrections, no such non-monotonic readings will occur.

Here is a slightly more correct analysis of the 2 seconds fast per 10 minutes case:  2 seconds error in 600 seconds is 3.33 milliseconds per second.  With sensor readings 50 milliseconds apart, and corrected clock readings not more than 3.33 milliseconds out of whack, non-monotonicity won't occur.  However, this does not meet the “logged time needs to be exact down to ms” criterion.  To meet that, drift of more than a half millisecond must be prevented.  That requires drift correction at least 6.67 times per second.  You could accomplish that by making a  clock correction compute at every third sensor cycle.

It should be clear from the example calculations of awake cycles that the major contributor to the count is ISR cycles, here taken as 100*1000, or 100000 cycles per second.  You could set up timer 1 to interrupt 20 times per second and turn timer 0 off (which would disable millis() and require a different time = ... formula).  If each timer 1 interrupt took 1000 cycles, that would contribute 20000 cycles instead of 100000 per second.

Edit 4: As I noted in a comment to Edgar Bonet's answer, one can change the TOP value used for timer interrupts, to control interrupt rate with better resolution than can be obtained by merely subtracting base values.

According to Gerben's comment, “getRTCTime only has 1sec resolution”.  As I haven't seen any code for your getRTCTime() I don't know if that is true or not; but if so, here is another approach for time-rate correction:

  • At some beginning point coincident with an RTC seconds-change, record millis() and an RTC reading, in eg millibase and RTCbase.
  • At some interval (eg, 10 seconds or a minute, in each case coincident with an RTC seconds-change) measure millis() and an RTC reading, in eg millinow and RTCnow.  Compute RTCdeltaK as the number of milliseconds from RTCbase to RTCnow.  Compute millidelta as millinow-millibase.
  • Whenever elapsed time in milliseconds is needed, compute elapsedms = ((millis()-millibase)*RTCdeltaK)/millidelta.

The above is an algorithm, and may need some adjustment before use as an implementation.  First, the elapsedms calculation can be arranged to avoid division, using a scaled multiplicative factor based on millidelta, RTCdeltaK, and some powers of 2.  Secondly, relatively constant clock drift is assumed.  If that assumption is incorrect, an average ratio with exponential decay could be used, instead of just a factor equivalent to RTCdeltaK/millidelta.


Multiple data packets with CIPSEND, associate each with pathway

Your "CIPSEND" is already associated with a path.

The sequence is generally:

You configure the ESP8266 as a server, including turning on multiple connections
You browse to the IP
The browser sends a HTTP request including a path. This has a "channel" number associated with it.
You generate a HTTP response and send it to the channel given in 3 using AT+CIPSEND.

The fact that you're sending the response to the browser through the channel that the request came in through "associates" the response with the request.

To do different things depending on the path it's up to you to recognise that path in the request and generate a different response accordingly.


I have the same problem since version 1.8.10.

With a good running sketch I don't get any message "Multiple libraries were found" (and no warnings also)

But with every small compiler error I get a whole list of "Multiple libraries were found"

My custom libraries are in a sketchbook location
D:\DATA BACKUPPED\Documenten Albert\Arduino\Sketchbook-and-user-libraries


Just get one with a 3.3v regulator on it. PS logic levels are allowed to be 5v.

DHT22 and LCD will also work fine on 3.3v so, alternatively, you could also get a 3.3v Nano.

The resistor value for the DHT22 depends on the length of wire between the DHT and Nano. Just buy them to be sure, or get a breakout board that already has them on the board (along with a capacitor, which is nice).


Here's the picture of the Nokia FBUS connector from your link:

And here's a (slightly dubious) method of connection from some random web page

which goes on to say

  The F-bus protocol uses 115,200bps so we can easily use the Arduino’s serial function to communication with the phone. All you need to is hook up the phones TX to the Arduino’s RX and then use a resistor divider (I choose 330 ohm resistors) to connect the Arduino’s TX to the phones RX as shown above.

That page goes on to show how to use an Arduino to get the phone to send SMS text messages.

Sources:

http://www.insidegadgets.com/2013/01/12/how-to-use-nokia-f-bus-to-send-an-sms-message/
http://forum.gsmhosting.com/vbb/f148/nokia-105-new-100-working-solution-1731398/


Unstable system when controlling power to serial peripheral devices and sleeping

Using an NPN transistor to control power to a peripheral may be problematic.

An NPN transitor would presumably be used as a low-side switch interrupting the peripheral's ground line, however, even when turned on this will have a non-trivial voltage drop.

Most logic level definitions are asymmetric, ie, the maximimum legal voltage for a logic "0" is relatively low. If you insert the voltage drop of a bipolar transistor into a peripheral's ground line, then it may be borderline unable to drive a fully legal '0' to the ATmega, which is reference to the lower true ground and would see the peripheral's ground difference added to its output voltage.

A better approach would be to use either a high-side switch (as there is typically more room between the minimum legal '1' and the supply) or else to use an FET switch which would have a much lower voltage drop.

Also keep in mind that most IC's are not specified to tolerate lasting I/O voltages much outside of the range of their power suppliers, and in fact their protection diodes may mean that application of such voltages effectively powers them through the I/O pin.  So before turning off power to a peripheral, you probably want the ATmega software to assert all shared I/O lines towards the side of the peripheral supply which is not being disconnected, ie, for a low side switch drive everything high and for a high side switch drive everything low.

Finally, the process of power cycling could potentially confuse peripheral interface engines and it is possible that some error flags set in this process might never be cleared.  So you may want to clear the flags of and generally re-initialize your USART, I2C, etc on resume.


Function is executing when I try to store it in an array

What you have done will certainly call the function. Since it is always the same function, just store the arguments into an array. Something like this:

const int COUNT = 100;

struct
  {
  int midi;
  int row;
  int col; int len;
  bool short_led;
  } notes [COUNT] = {
  { 0x40, 3, 1, 414 },  //Quarter note: E
  { 0x3e, 2, 4, 414 },  //Quarter note: D
  { 0x3c, 2, 2, 414 },  //Quarter note: C

  // and so on
  };

int playNote(int midi, int row, int col, int len, bool short_led = false);

void setup()
  {
  // put your setup code here, to run once:
  }

void loop()
  {
  for (int i = 0; i < COUNT; i++)
    {
    if (notes [i].midi)
      playNote (notes [i].midi, notes [i].row, notes [i].col,
                notes [i].len, notes [i].short_led);
    }
  }

int playNote(int midi, int row, int col, int len, bool short_led)
{
    int len1, len2;
    if (short_led) {
        len1 = len * 3 / 4;
        len2 = len * 1 / 4;
    } else {
        len1 = len;
        len2 = 0;
    }
    noteOn(0x90, midi, 100);
    digitalWrite(LedR[row], HIGH);
    digitalWrite(LedC[col], LOW);
    delay(len1);
    digitalWrite(LedR[row], LOW);
    digitalWrite(LedC[col], HIGH);
    delay(len2);
    noteOff(0x90, midi, 0);
}

  yeah but i want to be able to store the function in an array with the set parameters

Do you? I wonder why.

Anyway, you can do that by making an array of lambda functions like this:

const int COUNT = 100;

int playNote(int midi, int row, int col, int len, bool short_led = false);

void (*SongSeq[COUNT])() =
 {
 [] { playNote(0x40, 3, 1, 414); } ,
 [] { playNote(0x3e, 2, 4, 414); } ,
 [] { playNote(0x3c, 2, 2, 414); } ,
 [] { playNote(0x3e, 2, 4, 414); } ,

 // ... and so on

 };

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

void loop()
  {
  for (int i = 0; i < COUNT; i++)
    {
    if (SongSeq [i])
      SongSeq [i] ();
    }
  }

int playNote(int midi, int row, int col, int len, bool short_led)
{
  Serial.print ("Playing note ");
  Serial.println (midi);
  delay (100);
}


pins_arduino.h has some standard macros that can be used for some of what you're looking to do. Using the arduino:standard variant used by Uno for example:

https://github.com/arduino/Arduino/blob/1.8.1/hardware/arduino/avr/variants/standard/pins_arduino.h#L35:

#define digitalPinHasPWM(p) ((p) == 3 || (p) == 5 || (p) == 6 || (p) == 9 || (p) == 10 || (p) == 11)

Or if you want to use your naming scheme:

#define supportsPWM(p) digitalPinHasPWM(p)

After that it gets a bit more sketchy:

https://github.com/arduino/Arduino/blob/1.8.1/hardware/arduino/avr/variants/standard/pins_arduino.h#L28

#define NUM_DIGITAL_PINS 20

So, assuming that Arduino digital pins will always be numbered consecutively from 0 and any pin that supports digital input also supports digital output(which is the case in any variant I'm familiar with), you could use that to write some macros:

#define supportsDigitalInput(p) ((p) < NUM_DIGITAL_PINS)
#define supportsDigitalOutput(p) supportsDigitalInput(p)

https://github.com/arduino/Arduino/blob/1.8.1/hardware/arduino/avr/variants/standard/pins_arduino.h#L29

#define NUM_ANALOG_INPUTS 6

Could be used to write this macro(with numbering assumption):

#define supportsAnalogInput(p) ((p) < NUM_ANALOG_INPUTS)

Note that this will not work for the An analog pin names(e.g. A0 vs 0).

As for:

props.supportsAnalogOutput();
props.analogInputBits();
props.analogOutputBits();
props.pullupResistance();
props.pulldownResistance();

I'm don't know of pre-existing code for those. There is probably a way to get it for the first three in an architecture specific manner. The last two you'd most likely need to get the information from datasheets for all of your target microcontrollers and define then using processor specific macros.


Low-power detect rise and fall of input signal

You can generate a pulse on any edge of a signal using some logic gates. For instance combining a rising edge detector with a falling edge detector and adding a time delay would probably achieve what you want:

simulate this circuit – Schematic created using CircuitLab

Simulate it here.

The length of time the pulse is on for is (roughly) defined by the time constant of R1 and C1.  That's T=RC, so in this instance 100 x 0.0000001 =  10uS.

for a time of (say) 30 seconds, you will want to massively increase those values. For example, 470uF and 80K would give you around 32 seconds.

Power consumption? Well, that's all dependent on the logic gates and how you build the circuit.  74HC chips are pretty efficient now (far better than the old 74LS ones), but you will want to reduce it down to as few chips and gates as possible. That means converting the circuit to just one gate type (for example NAND) and reducing redundancy in the circuit to minimise power consumption.


The issue, as Maximilian Gergardt suggested in comments, was with Arduino's TX/RX sending 5V signal. Adding voltage dividers on RX line solved the issue. Refer to diagram below for details:


Suggest me an Arduino development board, with a removable ATmega chip?

Only the Arduino Uno has a socketed IC chip. All the rest are using soldered SMD ICs.


void loop followed by other "void" expressions

The void loop() section is a function, the same as void setup() is a function.  When you start you Arduino program another function, that you can't see in the IDE, call setup() and then calls loop() repeatedly.

These other function you have seen, i.e. void Num_Write(int n) can be called from either setup() or loop() and they will execute their instructions before returning to the function that called them. Its also possible the Num_Write() may call other functions before it returns controller to the function that called it.

The type void is used to represent nothing (its actually more complex than that, but for this level of explanation nothing will do).  Other functions may return other types int, char, bool for instance.  So if we had a function like this:

int theMeaningOfLife(void)
{
  return 42;
}

This is a function that returns an int (a number) so you would call it like this:

void setup()
{
  int number = theMeaningOfLife();
}

There is one catch, the function has to be declared BEFORE it is used, this allows the compiler to know what you are referring to.  The simplest way of doing this is to write the function above the function that is calling it.  The second way is to just write the function's signature above the function using it, i.e.:

int theMeaningOfLife(void);

void setup()
{
  int number = theMeaningOfLife();
}

The best way (but not always practical on an Arduino) is to have all the function declarations in a header file (.h) and the code in a .cpp file.  (Have a look a library to see what I mean).

Summary

There is only one function that is called repeatedly and that is the loop function.
Just because a function returns void doesn't mean its going to loop repeatedly.


I was able to fix the issue by editing the boards.txt file and adding the following lines:
lolin32.menu.PartitionScheme.huge_app=Huge APP (3MB No OTA/1MB SPIFFS)
lolin32.menu.PartitionScheme.huge_app.build.partitions=huge_app
lolin32.menu.PartitionScheme.huge_app.upload.maximum_size=3145728

This will add a "Huge APP" partition scheme to WEMOS Lolin32.


You cannot directly give an index (0..7) to a shift register if you want the index to represent the LED number to be switched on.
You have to build a table similar to the following:

byte led[8] = {
0b00000001,
0b00000010,
0b00000100,
0b00001000,
0b00010000,
0b00100000,
0b01000000,
0b10000000
};

and later . . .

shiftOut(dataPin, clockPin, LSBFIRST, led[leds]);

where leds is a number 0..7


Is it possible to simulate PWM using delay() function?

It is possible to create a PWM signal from a non-PWM digital pin although you would not want to use delay, but timer interrupts for accuracy and finite timing. PWM intervals are typically measured in (μs[microseconds] vs ms[milliseconds]).

The standard Arduino servo library  does this: Servo.


Unless you've manually set the btSerial speed, you need to be at the default for AT commands which is 38400 -> btSerial.begin(38400);

If you want to read regular Serial communication, you'll need to monitor 9600 -> btSerial.begin(9600);

If you are unable to to send commands, I feel as if you wouldn't have changed the default speeds.

I used this link as a reference with my project: Modify The HC-05 Bluetooth Module Defaults Using AT Commands

Lastly, you didn't mention whether or not you soldered a jumper wire to PIN 32 for your ArdProgramOff/On. Another reference for you as well: DIY Arduino Bluetooth Programming Shield

Hope my answer helps! Good luck!


The function Serial.print() and it's siblings cuts all leading zeros. So 0b00001111 get's displayed as 1111 and 0b00000000 as 0. So you actually get what you expect. It's just printing different.

Also, when reading PORTF, you actually read the output state of the pins, as you have set it before. If you want to read the real input level of the pins, you should read PINF instead.

Though I don't know, where that segmentation fault came from.


Trying to power 100 Arduino's from single power line

You are already using a differential signalling system that doesn't care about ground levels, so you don't need to worry about that side of things.

As for power distribution - a strategy known as point of load regulation is what you want. That is where you supply a higher voltage (but lower current) power feed to one, or in this scenario more likely a group of, boards and regulate that power down using a switching regulator to a lower voltage (5V) and higher current.

This has the advantage that:

You are only worrying about small groups of Arduinos, not the whole lot
You can use thinner wires to feed in the power to a group
You get less losses from wire resistance at high currents

For 100 Ardunos you may want to have maybe 10 to a group with a 3A switching regulator for each group, giving an average of 300mA per board (depending on your current needs, of course - you may want less per group and more groups to give more average current per board).

In that example you'd have a total output current limit of 30A in 10 sections at 5V. That equates to (P=V×I) 150W. So a 200W 24V power supply would be adequate.

At 24V, 150W would demand 6.25A (plus some more to account for the efficiency of the regulators, so call it 8A - hence the desire for a 200W supply).

For 3A you need at least 24AWG wire - but preferably considerably thicker - maybe 18AWG.  The 8A for the 24V would need minimum 15AWG, preferably bigger - although you don't need that size all the way to the end of your chain of regulators. If you had each regulator wired directly back to the power supply individually that would only need thin wires (absolute minimum 30AWG, which is tiny - though to keep losses to a minimum you'd want more like 20AWG).

So for simplicity and to reduce your wire costs, just stick to one size all the way through so you're buying only one gauge of wire (so you get a bigger discount for buying more).  You could quite easily use:

18AWG direct from the PSU to each POL regulator (24V, 0.8A)
18AWG from each POL regulator to all Arduinos in a group (5V, 3A)

Of course, this is all using numbers plucked out of thin air, and you'd need to adjust it to fit your specific project, but you get the idea - higher voltage to a group, regulate to 5V, then 5V to each Arduino in the group. You don't need to care about grounding etc because you're using RS-485.


How can I read delay of a note that I am playing

Your code currently will only measure the code execution time and not the duration of the note(s) being played.

You need to follow uint128_t's suggestion and rewrite the code to detect the "button release", at which point you measure the time with millis(), and call noTone(). Only then will you be able to measure the note's duration.

I believe that the source of confusion is that you seem to think that tone() acts like delay() and waits for the note to finish - it does not. tone() merely starts the note and then the next instruction is executed, without waiting for the note to end.

So, using millis() straight after calling tone() will actually only measure the time it takes to execute the tone() statement (and a few if statements - depending on whether you use your original code, or Maximus's code).


"Arduino" is just plain old C++ with (in some cases) bits removed and some helper functions and classes.
For the smaller (lower powered AVR for example) there is no full STL in the C++ library, and some functions are of a reduced complexity (such as no floating point support in the printf family of functions by default).
For OOP you don't need to know anything "Arduino" - it's just C++. Any C++ OOP tutorial will teach you what you need to know for Arduino OOP.