text:
Connect Arduino to LiDAR via RS-232
Edit: We're so close! Update at bottom!
I'm not sure if this is the right place to ask, but since you helped my so much in the past, I thought it's worth a try.
So as I stated in my last question, I'm using my Arduino Leonardo to simulate a GPS Receiver.
The Arduino is now connected to a Velodyne VLP-16 LiDAR
Here's what the Lidar needs:

I wired it like this:

And wrote the following code:
#include <SoftwareSerial.h>
SoftwareSerial mySerial(7, 6); //232_TX,232_

int triggerFreq = 1;
unsigned long timestamp;
unsigned long triggerStartTime;
const unsigned long dt = 1000000/triggerFreq; //micros

unsigned long i;

float gprmc = 181721.000;

void setup() {
  pinMode(11, OUTPUT); // PPS
  pinMode(12, OUTPUT); // Indicator of msg_sent
  Serial.begin(9600);
  mySerial.begin(9600);
  triggerStartTime = micros();
}

void loop() {
  timestamp = micros()-triggerStartTime;
  if (timestamp>= dt*i+200000)
  {
    digitalWrite(12,HIGH);

    i +=1;
    gprmc += 1;
    mySerial.print("$GPRMC,");
    if (gprmc < 100000) mySerial.print(F("0"));
    mySerial.print(gprmc,3);
    mySerial.println(F(",A,4042.695,N,07400.796,W,,,080120,000.0,W*63"));
    Serial.print("$GPRMC,");
    if (gprmc < 100000) Serial.print(F("0"));
    Serial.print(gprmc,3);
    Serial.println(F(",A,4042.695,N,07400.796,W,,,080120,000.0,W*63"));
    digitalWrite(12,LOW);
  }
  else if (timestamp>=dt*i+100000)
  {
    digitalWrite(11,LOW);
  }
  else if (timestamp>=dt*i)
  {
    digitalWrite(11,HIGH);

  }

}

Here's the situation now:

I'm seeing on the board that the messages are being sent (TX LED flashing)
I'm also seeing that the pulse is sent correctly (flashing LED)
I don't measure any voltage on the TX output pin (RS232 pin3) (I'm just using my multimeter, but normally it reacts to such short voltage pulses by blinking an LED)
I do measure such a pulse on RS232 pin4
The LiDAR doesn't react to my sent messages

Now my question: Do you see an error in my implementation? Is the message sent correctly?
Thank you sooo much for your help! I'm really appreciating it!
Edit: The LiDAR manual says:

The supported NMEA sentence and syntax are exactly the same as on the wired (serial) GPS interface. Supported sentence delimiter sequences include  (HEX 0D0A, the standard),  by itself, and  by itself.

To be honest I'm not very familiar with these kind of problems so I'm not sure if these delimiters are already being sent?
Edit Nr2: Ok the following situation:

I'm actually not sure what changed. The code is still the same as above
The LiDAR now recognizes SOME of the messages (I can only see the position, so I edited the code to change the position a bit every second, and the Lidar updates its position irregularly but approx. all 10 seconds)
If anyone knows an explanation, I would be very happy to know. Otherwise, I just keep on trying an will keep you updated!

So the following code partially works. That means: the LiDAR recognizes certain messages... it seems like those are always the same messages (i incremented the position every second, these are the positions):

3015.2746
3015.2766
3015.2971
3015.3107
3015.3117

I displayed all the times when something was sent, and i could not find any differences between the messages that worked and those that didn't work.
One more followup:
If I try to increment pos+=0.0001, it does not work... it seems like i can only change up to 3 decimals. I don't understand why, since the float uses 4 bytes, so this should be no problem to store?! helpppp
Ok so here is the code for now:
#include <SoftwareSerial.h>
SoftwareSerial mySerial(7, 6); //232_TX,232_

int triggerFreq = 1;
unsigned long timestamp;
unsigned long triggerStartTime;
const unsigned long dt = 1000000/triggerFreq; //micros
unsigned long ts_pps_high;
unsigned long ts_pps_low;
unsigned long ts_msg_high;
unsigned long ts_msg_low;

unsigned long i;

int hh = 04;
int mm = 51;
int ss = 00;
float pos = 3015.2307;
bool msg;

void setup() {
  // put your setup code here, to run once:
  pinMode(11, OUTPUT); // PPS
  pinMode(12, OUTPUT); // Indicator of msg_sent
  Serial.begin(9600);
  mySerial.begin(9600);
  triggerStartTime = micros();
}

void loop() {
  timestamp = micros()-triggerStartTime;
  if (timestamp>= dt*i+350000)
  {
    pos +=0.001;
    digitalWrite(12,HIGH);
    i +=1;
    if (ss == 59)
    {
      ss=0;
      if (mm==59)
      {
        mm=0;
        hh+=1;
      }
      else mm+=1;
    }
    else ss+=1;

    ts_msg_high = micros();
    mySerial.print("$GPRMC,");
    if (hh<10) mySerial.print(F("0"));
    mySerial.print(hh);
    if (mm<10) mySerial.print(F("0"));
    mySerial.print(mm);
    if (ss<10) mySerial.print(F("0"));
    mySerial.print(ss);
    mySerial.print(".000,A,");
    mySerial.print(pos,4);
    mySerial.println(",N,09749.2872,W,0.67,161.46,030913,,,A*7C");

    // Print Debug Messages
    digitalWrite(12,LOW);
    ts_msg_low=micros();
    Serial.print("PPS at: ");
    Serial.print(ts_pps_high);
    Serial.print("\t PPS low after: ");
    Serial.print(ts_pps_low-ts_pps_high);
    Serial.print("\t MSG high after: ");
    Serial.print(ts_msg_high-ts_pps_high);
    Serial.print("\t MSG low after: ");
    Serial.print(ts_msg_low-ts_pps_high);
    Serial.print("$GPRMC,");
    if (hh<10) Serial.print(F("0"));
    Serial.print(hh);
    if (mm<10) Serial.print(F("0"));
    Serial.print(mm);
    if (ss<10) Serial.print(F("0"));
    Serial.print(ss);
    Serial.print(".000,A,");
    Serial.print(pos,4);
    Serial.println(",N,09749.2872,W,0.67,161.46,030913,,,A*7C");
  }
  else if (timestamp>=dt*i+100000)
  {
    digitalWrite(11,LOW);
    if (msg==true)
    {
      msg = false;
      ts_pps_low = micros();
    }

  }
  else if (timestamp>=dt*i)
  {
    digitalWrite(11,HIGH);
    if (msg==false)
    {
      msg = true;
      ts_pps_high = micros();
    }
  }

}

You can see my output as well:
PPS at: 2001060  PPS low after: 100000   MSG high after: 350016  MSG low after: 427132$GPRMC,045103.000,A,3015.2336,N,09749.2872,W,0.67,161.46,030913,,,A*7C
PPS at: 3001060  PPS low after: 100004   MSG high after: 350004  MSG low after: 427112$GPRMC,045104.000,A,3015.2346,N,09749.2872,W,0.67,161.46,030913,,,A*7C
PPS at: 4001056  PPS low after: 100000   MSG high after: 350004  MSG low after: 427116$GPRMC,045105.000,A,3015.2355,N,09749.2872,W,0.67,161.46,030913,,,A*7C
PPS at: 5001060  PPS low after: 100004   MSG high after: 350004  MSG low after: 427112$GPRMC,045106.000,A,3015.2365,N,09749.2872,W,0.67,161.46,030913,,,A*7C
PPS at: 6001056  PPS low after: 100004   MSG high after: 350004  MSG low after: 427116$GPRMC,045107.000,A,3015.2375,N,09749.2872,W,0.67,161.46,030913,,,A*7C
PPS at: 7001060  PPS low after: 100004   MSG high after: 350004  MSG low after: 427120$GPRMC,045108.000,A,3015.2385,N,09749.2872,W,0.67,161.46,030913,,,A*7C
PPS at: 8001056  PPS low after: 100004   MSG high after: 350020  MSG low after: 427132$GPRMC,045109.000,A,3015.2395,N,09749.2872,W,0.67,161.46,030913,,,A*7C
PPS at: 9001060  PPS low after: 100000   MSG high after: 350016  MSG low after: 427160$GPRMC,045110.000,A,3015.2404,N,09749.2872,W,0.67,161.46,030913,,,A*7C
PPS at: 10001052     PPS low after: 100008   MSG high after: 350020  MSG low after: 427164$GPRMC,045111.000,A,3015.2414,N,09749.2872,W,0.67,161.46,030913,,,A*7C
PPS at: 11001064     PPS low after: 100000   MSG high after: 350020  MSG low after: 427164$GPRMC,045112.000,A,3015.2424,N,09749.2872,W,0.67,161.46,030913,,,A*7C
PPS at: 12001056     PPS low after: 100008   MSG high after: 350004  MSG low after: 427152$GPRMC,045113.000,A,3015.2434,N,09749.2872,W,0.67,161.46,030913,,,A*7C
PPS at: 13001056     PPS low after: 99996    MSG high after: 350020  MSG low after: 427164$GPRMC,045114.000,A,3015.2443,N,09749.2872,W,0.67,161.46,030913,,,A*7C
PPS at: 14001056     PPS low after: 100008   MSG high after: 350008  MSG low after: 427156$GPRMC,045115.000,A,3015.2453,N,09749.2872,W,0.67,161.46,030913,,,A*7C
PPS at: 15001052     PPS low after: 100004   MSG high after: 350020  MSG low after: 427164$GPRMC,045116.000,A,3015.2463,N,09749.2872,W,0.67,161.46,030913,,,A*7C
PPS at: 16001052     PPS low after: 100000   MSG high after: 350016  MSG low after: 427164$GPRMC,045117.000,A,3015.2473,N,09749.2872,W,0.67,161.46,030913,,,A*7C
PPS at: 17001056     PPS low after: 100004   MSG high after: 350020  MSG low after: 427164$GPRMC,045118.000,A,3015.2482,N,09749.2872,W,0.67,161.46,030913,,,A*7C
PPS at: 18001052     PPS low after: 100000   MSG high after: 350016  MSG low after: 427164$GPRMC,045119.000,A,3015.2492,N,09749.2872,W,0.67,161.46,030913,,,A*7C
PPS at: 19001056     PPS low after: 100004   MSG high after: 350020  MSG low after: 427160$GPRMC,045120.000,A,3015.2502,N,09749.2872,W,0.67,161.46,030913,,,A*7C
PPS at: 20001060     PPS low after: 100000   MSG high after: 350004  MSG low after: 427148$GPRMC,045121.000,A,3015.2512,N,09749.2872,W,0.67,161.46,030913,,,A*7C
PPS at: 21001052     PPS low after: 100004   MSG high after: 350020  MSG low after: 427168$GPRMC,045122.000,A,3015.2521,N,09749.2872,W,0.67,161.46,030913,,,A*7C
PPS at: 22001064     PPS low after: 100004   MSG high after: 350004  MSG low after: 427148$GPRMC,045123.000,A,3015.2531,N,09749.2872,W,0.67,161.46,030913,,,A*7C
PPS at: 23001052     PPS low after: 100008   MSG high after: 350020  MSG low after: 427172$GPRMC,045124.000,A,3015.2541,N,09749.2872,W,0.67,161.46,030913,,,A*7C
PPS at: 24001052     PPS low after: 100008   MSG high after: 350024  MSG low after: 427168$GPRMC,045125.000,A,3015.2551,N,09749.2872,W,0.67,161.46,030913,,,A*7C
PPS at: 25001056     PPS low after: 100000   MSG high after: 350016  MSG low after: 427168$GPRMC,045126.000,A,3015.2561,N,09749.2872,W,0.67,161.46,030913,,,A*7C
PPS at: 26001052     PPS low after: 100008   MSG high after: 350024  MSG low after: 427160$GPRMC,045127.000,A,3015.2570,N,09749.2872,W,0.67,161.46,030913,,,A*7C
PPS at: 27001056     PPS low after: 100000   MSG high after: 350020  MSG low after: 427156$GPRMC,045128.000,A,3015.2580,N,09749.2872,W,0.67,161.46,030913,,,A*7C
PPS at: 28001060     PPS low after: 100008   MSG high after: 350004  MSG low after: 427144$GPRMC,045129.000,A,3015.2590,N,09749.2872,W,0.67,161.46,030913,,,A*7C
PPS at: 29001056     PPS low after: 100000   MSG high after: 350020  MSG low after: 427156$GPRMC,045130.000,A,3015.2600,N,09749.2872,W,0.67,161.46,030913,,,A*7C
PPS at: 30001056     PPS low after: 100004   MSG high after: 350020  MSG low after: 427164$GPRMC,045131.000,A,3015.2609,N,09749.2872,W,0.67,161.46,030913,,,A*7C
PPS at: 31001056     PPS low after: 100008   MSG high after: 350004  MSG low after: 427148$GPRMC,045132.000,A,3015.2619,N,09749.2872,W,0.67,161.46,030913,,,A*7C
PPS at: 32001056     PPS low after: 99996    MSG high after: 350012  MSG low after: 427164$GPRMC,045133.000,A,3015.2629,N,09749.2872,W,0.67,161.46,030913,,,A*7C
PPS at: 33001056     PPS low after: 100008   MSG high after: 350020  MSG low after: 427164$GPRMC,045134.000,A,3015.2639,N,09749.2872,W,0.67,161.46,030913,,,A*7C
PPS at: 34001056     PPS low after: 100000   MSG high after: 350016  MSG low after: 427164$GPRMC,045135.000,A,3015.2648,N,09749.2872,W,0.67,161.46,030913,,,A*7C
PPS at: 35001060     PPS low after: 100004   MSG high after: 350000  MSG low after: 427144$GPRMC,045136.000,A,3015.2658,N,09749.2872,W,0.67,161.46,030913,,,A*7C
PPS at: 36001060     PPS low after: 100000   MSG high after: 350004  MSG low after: 427148$GPRMC,045137.000,A,3015.2668,N,09749.2872,W,0.67,161.46,030913,,,A*7C
PPS at: 37001060     PPS low after: 100004   MSG high after: 350004  MSG low after: 427144$GPRMC,045138.000,A,3015.2678,N,09749.2872,W,0.67,161.46,030913,,,A*7C
PPS at: 38001064     PPS low after: 100004   MSG high after: 350004  MSG low after: 427144$GPRMC,045139.000,A,3015.2687,N,09749.2872,W,0.67,161.46,030913,,,A*7C
PPS at: 39001060     PPS low after: 100008   MSG high after: 350004  MSG low after: 427152$GPRMC,045140.000,A,3015.2697,N,09749.2872,W,0.67,161.46,030913,,,A*7C
PPS at: 40001052     PPS low after: 100008   MSG high after: 350024  MSG low after: 427160$GPRMC,045141.000,A,3015.2707,N,09749.2872,W,0.67,161.46,030913,,,A*7C
PPS at: 41001052     PPS low after: 100000   MSG high after: 350016  MSG low after: 427168$GPRMC,045142.000,A,3015.2717,N,09749.2872,W,0.67,161.46,030913,,,A*7C
PPS at: 42001060     PPS low after: 100004   MSG high after: 350004  MSG low after: 427148$GPRMC,045143.000,A,3015.2727,N,09749.2872,W,0.67,161.46,030913,,,A*7C
PPS at: 43001056     PPS low after: 100000   MSG high after: 350020  MSG low after: 427164$GPRMC,045144.000,A,3015.2736,N,09749.2872,W,0.67,161.46,030913,,,A*7C
PPS at: 44001052     PPS low after: 100004   MSG high after: 350020  MSG low after: 427164$GPRMC,045145.000,A,3015.2746,N,09749.2872,W,0.67,161.46,030913,,,A*7C
PPS at: 45001064     PPS low after: 100004   MSG high after: 350004  MSG low after: 427144$GPRMC,045146.000,A,3015.2756,N,09749.2872,W,0.67,161.46,030913,,,A*7C
PPS at: 46001052     PPS low after: 100004   MSG high after: 350020  MSG low after: 427172$GPRMC,045147.000,A,3015.2766,N,09749.2872,W,0.67,161.46,030913,,,A*7C
PPS at: 47001056     PPS low after: 100004   MSG high after: 350020  MSG low after: 427164$GPRMC,045148.000,A,3015.2775,N,09749.2872,W,0.67,161.46,030913,,,A*7C
PPS at: 48001056     PPS low after: 100000   MSG high after: 350016  MSG low after: 427164$GPRMC,045149.000,A,3015.2785,N,09749.2872,W,0.67,161.46,030913,,,A*7C
PPS at: 49001060     PPS low after: 100004   MSG high after: 350004  MSG low after: 427144$GPRMC,045150.000,A,3015.2795,N,09749.2872,W,0.67,161.46,030913,,,A*7C
PPS at: 50001052     PPS low after: 100000   MSG high after: 350016  MSG low after: 427160$GPRMC,045151.000,A,3015.2805,N,09749.2872,W,0.67,161.46,030913,,,A*7C
PPS at: 51001060     PPS low after: 100004   MSG high after: 350004  MSG low after: 427148$GPRMC,045152.000,A,3015.2814,N,09749.2872,W,0.67,161.46,030913,,,A*7C
PPS at: 52001056     PPS low after: 100000   MSG high after: 350020  MSG low after: 427164$GPRMC,045153.000,A,3015.2824,N,09749.2872,W,0.67,161.46,030913,,,A*7C
PPS at: 53001064     PPS low after: 100004   MSG high after: 350000  MSG low after: 427144$GPRMC,045154.000,A,3015.2834,N,09749.2872,W,0.67,161.46,030913,,,A*7C
PPS at: 54001056     PPS low after: 100004   MSG high after: 350020  MSG low after: 427164$GPRMC,045155.000,A,3015.2844,N,09749.2872,W,0.67,161.46,030913,,,A*7C
PPS at: 55001060     PPS low after: 100004   MSG high after: 350020  MSG low after: 427172$GPRMC,045156.000,A,3015.2854,N,09749.2872,W,0.67,161.46,030913,,,A*7C
PPS at: 56001068     PPS low after: 100004   MSG high after: 350000  MSG low after: 427144$GPRMC,045157.000,A,3015.2863,N,09749.2872,W,0.67,161.46,030913,,,A*7C
PPS at: 57001060     PPS low after: 99996    MSG high after: 350012  MSG low after: 427160$GPRMC,045158.000,A,3015.2873,N,09749.2872,W,0.67,161.46,030913,,,A*7C
PPS at: 58001064     PPS low after: 100004   MSG high after: 350004  MSG low after: 427148$GPRMC,045159.000,A,3015.2883,N,09749.2872,W,0.67,161.46,030913,,,A*7C
PPS at: 59001056     PPS low after: 100000   MSG high after: 350024  MSG low after: 427132$GPRMC,045200.000,A,3015.2893,N,09749.2872,W,0.67,161.46,030913,,,A*7C
PPS at: 60001060     PPS low after: 100004   MSG high after: 350020  MSG low after: 427124$GPRMC,045201.000,A,3015.2902,N,09749.2872,W,0.67,161.46,030913,,,A*7C
PPS at: 61001064     PPS low after: 100008   MSG high after: 350004  MSG low after: 427116$GPRMC,045202.000,A,3015.2912,N,09749.2872,W,0.67,161.46,030913,,,A*7C
PPS at: 62001060     PPS low after: 100008   MSG high after: 350008  MSG low after: 427124$GPRMC,045203.000,A,3015.2922,N,09749.2872,W,0.67,161.46,030913,,,A*7C
PPS at: 63001060     PPS low after: 100012   MSG high after: 350008  MSG low after: 427120$GPRMC,045204.000,A,3015.2932,N,09749.2872,W,0.67,161.46,030913,,,A*7C
PPS at: 64001052     PPS low after: 100000   MSG high after: 350020  MSG low after: 427136$GPRMC,045205.000,A,3015.2941,N,09749.2872,W,0.67,161.46,030913,,,A*7C
PPS at: 65001060     PPS low after: 100008   MSG high after: 350004  MSG low after: 427120$GPRMC,045206.000,A,3015.2951,N,09749.2872,W,0.67,161.46,030913,,,A*7C
PPS at: 66001064     PPS low after: 100000   MSG high after: 349996  MSG low after: 427116$GPRMC,045207.000,A,3015.2961,N,09749.2872,W,0.67,161.46,030913,,,A*7C
PPS at: 67001060     PPS low after: 100004   MSG high after: 350004  MSG low after: 427120$GPRMC,045208.000,A,3015.2971,N,09749.2872,W,0.67,161.46,030913,,,A*7C
PPS at: 68001060     PPS low after: 100000   MSG high after: 350004  MSG low after: 427112$GPRMC,045209.000,A,3015.2980,N,09749.2872,W,0.67,161.46,030913,,,A*7C
PPS at: 69001052     PPS low after: 100004   MSG high after: 350020  MSG low after: 427164$GPRMC,045210.000,A,3015.2990,N,09749.2872,W,0.67,161.46,030913,,,A*7C
PPS at: 70001064     PPS low after: 100004   MSG high after: 350004  MSG low after: 427136$GPRMC,045211.000,A,3015.3000,N,09749.2872,W,0.67,161.46,030913,,,A*7C
PPS at: 71001060     PPS low after: 100004   MSG high after: 350004  MSG low after: 427148$GPRMC,045212.000,A,3015.3010,N,09749.2872,W,0.67,161.46,030913,,,A*7C
PPS at: 72001064     PPS low after: 100004   MSG high after: 350004  MSG low after: 427144$GPRMC,045213.000,A,3015.3020,N,09749.2872,W,0.67,161.46,030913,,,A*7C
PPS at: 73001056     PPS low after: 100000   MSG high after: 350016  MSG low after: 427164$GPRMC,045214.000,A,3015.3029,N,09749.2872,W,0.67,161.46,030913,,,A*7C
PPS at: 74001064     PPS low after: 99988    MSG high after: 350004  MSG low after: 427148$GPRMC,045215.000,A,3015.3039,N,09749.2872,W,0.67,161.46,030913,,,A*7C
PPS at: 75001052     PPS low after: 100000   MSG high after: 350020  MSG low after: 427164$GPRMC,045216.000,A,3015.3049,N,09749.2872,W,0.67,161.46,030913,,,A*7C
PPS at: 76001060     PPS low after: 100004   MSG high after: 350000  MSG low after: 427144$GPRMC,045217.000,A,3015.3059,N,09749.2872,W,0.67,161.46,030913,,,A*7C
PPS at: 77001056     PPS low after: 100008   MSG high after: 350004  MSG low after: 427148$GPRMC,045218.000,A,3015.3068,N,09749.2872,W,0.67,161.46,030913,,,A*7C
PPS at: 78001060     PPS low after: 100008   MSG high after: 350004  MSG low after: 427152$GPRMC,045219.000,A,3015.3078,N,09749.2872,W,0.67,161.46,030913,,,A*7C
PPS at: 79001052     PPS low after: 100008   MSG high after: 350020  MSG low after: 427164$GPRMC,045220.000,A,3015.3088,N,09749.2872,W,0.67,161.46,030913,,,A*7C
PPS at: 80001052     PPS low after: 100000   MSG high after: 350016  MSG low after: 427164$GPRMC,045221.000,A,3015.3098,N,09749.2872,W,0.67,161.46,030913,,,A*7C
PPS at: 81001056     PPS low after: 100008   MSG high after: 350020  MSG low after: 427164$GPRMC,045222.000,A,3015.3107,N,09749.2872,W,0.67,161.46,030913,,,A*7C
PPS at: 82001060     PPS low after: 100000   MSG high after: 350016  MSG low after: 427172$GPRMC,045223.000,A,3015.3117,N,09749.2872,W,0.67,161.46,030913,,,A*7C

A number of hints to check, though I can only throw vague observations on the error (EDIT: some hints only make sense with an older version of the question):

You set the SoftwareSerial to pin 7 for RX and pin 6 for TX, but the TX LED of the board is connected to the hardware UART, which is used by Serial. So the TX LED reacts to your debug messages sent via Serial.print() to the PC. The TX and RX pins on your Arduino board are always connected to the hardware UART, which always is managed by Serial and cannot be claimed by SoftwareSerial.
The "SoftwareSerial TX pin" of your Arduino (note: the TX pin you set via SoftwareSerial mySerial(7, 6);) needs to be connected to RX of the GPS module. Remember: If you transmit something via the transmit line of one device, it needs to be received by the receive line of the other device (T stands for transmit, R for receive, and X for that you must cross the lines). (This hint ignores that you've got a RS232 shield, I realized that only later.)
The docs state that your gprmc record is accepted in either hhmmss or hhmmss.s format. Yet you send a string with three places after the dot. I'm not sure whether I misinterpret something here.
If you just add 1 to gprmc every second, you'll end up sending the equivalent of "18 hours, 17 minutes, 61 seconds" after 40 seconds runtime (because the format is expected to be hhmmss), which might or might not confuse the GPS chip.
Is 9600 baud the correct speed for the GPS receiver? Somewhere in the docs should be a hint about that (I'd expect at least 115200 on devices that are less than 20 years old...).
The pulse line might follow negative logic, i.e. it normally is HIGH and need to be pulled LOW for the pulse. Check the data sheet whether a LOW pulse is needed, in which case you need to swap HIGH and LOW on the pulse line.
What is pin 12 (msg_sent) and why do you need it? Its not mentioned in the schematics. I can only glean that it might signal your RS232 shield that the message has been sent to the RS232 shield and the RS232 UART now may empty its buffer, i.e. actually send the message over the wire to the GPS chip. If this is indeed the case, you signal the RS232 shield that the message has been sent before you actually send the message.
Try it without the RS232 shield? RS232 is just a specification of "serial protocol" that allows for voltage levels of up to 25V plus a few extra signal lines. By the schematic and wiring, I see that the GPS chip does not use any extra lines and expects a signal level of 5V. With SoftwareSerial, you already output "serial protocol" at 5V signal level from your GPIO pins. From afar, it looks like the RS232 shield inserts more potential points of failure into the communication. Have you got a Serial-to-USB converter to actually check the output of your RS232 shield?
Your delimiters are not sent. Hex 0D0A is simply CRLF, or "carriage return, line feed" or "the standard line break characters in plain text files on DOS and Windows". Which means: The last mySerial.print() would need to be changed to mySerial.println(), which is just like mySerial.print(), only that it adds a line break at the end.
Maybe it works if you connect the pin labeled GPS_RXD_CNT in the schematics with pin 6 of your Arduino while removing any own wiring from TX and RX of your Arduino.
Floats do not "store 3 decimal places after the decimal point", they store the significant binary places plus the position of the point. This means: if the number of significant places is big, you lose precision at the end. Converted to decimal, a 32-bit float only has a precision of 6-7 decimal places. A number like (decimal) 100000.01 would lose its last 1, yielding 100000.0; this also is true for 1000000.1 (=1000000.0), 10000001000.0 (=10000000000.0) and 0.000010000001 (=0.00001). So if you add 0.1 to 1234567.0, you'll end up with 1234567.0 -- or in the extreme: 1234567000000.0 + 11111.0 = 1234567000000.0. (Numbers off the top of my head, reality might introduce some rounding between decimal and binary representation, this is just to get the point across -- also, your decimal output will not show this exactly, because a binary representation only is precise for fractions of powers of two after the point).

Also, you might want to add some Serial.println() calls for each of your digitalWrite() calls, outputting something like "pin 11 (PPS) is now HIGH". Then use the Serial Monitor of Arduino IDE (don't forget to set its baud rate to 9600) to check whether the protocol looks right.

Thanks for your hints. I'm trying to answer them:

Indeed i set the softwareSerial to Pin7 & 6. This is because I have the RS-232 shield mounted on top of the Arduino, which executes the communication. It has it's own TX LED that's flasching, when data is sent via RS-232. So this should be right

Maybe my schematic was a bit confusing. i connected the Arduino Tx to the Lidar RX, so this should also work (i tested the connection). I will update my  schematic.

You are right. However, in an other part of the document, the say

"The GPRMC record may be configured for HHMMSS, HHMMSS.s, HHMMSS.ss, and HHMMSS.sss formats." So this should be right as well...

Yess nice input! I changed this and will edit my question. However, it still doesnt work :S

@MarayJay "may be configured for" may mean that you'll have to tell the GPS chip the exact format before using it. Also, I'm not sure whether you actually need the RS232 shield. Maybe you can just directly wire the Arduino pin 6 to the GPS board.

The manual of the LiDAR says that it expects RS-232 communication (Higher voltage). But honestly, at this point I'm not sure anymore. I just need it to work

@MarayJay Added more hints to check ^^

@MarayJay Have you been successful yet? :)

thank you for all your hints and support! :O Unfortunately I ran out of time...I had to present a working system today, and had to invest my time in other things, since this is only a very small part of my project. now the deadline is over and after several night shifts, I honestly don't have the energy to persue this any further. But if I or anyone from our lab finds a way, I will let you know! :)


text:
Information about 'Arduino Nano 33 IoT'
blox w-102 is based on esp32** which (Esp32) can be used as a standalone chip for projects.
Here I want to know how w-102 and samd21g18a are communicating with each other.
If they are communicating then what is the need of doing so?

The Arduino boards with the NINA module: MKR 1010 WiFi, MKR 4000 vidor, Uno WiFi and Nano 33 IoT use the NINA module for WiFi networking with the WiFiNINA library and for BLE with the ArdunioBLE library. Additionally the flash memory of the NINA module will be available as storage.
The NINA module runs a firmware made by Arduino with ESP32 IDF framework.
I wired MKR ZERO with an ESP32 dev board for the WiFiNINA firmware and library according to MKR 1010 WiFi schematics, which is very similar to Nano 33 IoT. The MCUs are connected on SPI pins and UART for communication. The firmware uses one additional pin to signal to SPI master as 'ready' pin. Also io 0 and enable pin of NINA module are wired to put the ESP32 into flashing mode for firmware upgrade over UART.
On MKR 1010 and Nano33 IoT I2C is connected too. Boot MCU have access to on-board I2C sensors and could in theory communicate over I2C. This is currently not used.
The WiFiNINA library uses SPI communication. SAMD is master, NINA is slave.
The ArduinoBLE library communicates over UART. 'Ready' pin is used to switch to BLE mode in firmware at NINA reset.
The firmware uses io 0 as 'heartbeat' signal for the library.
My wiring:

the orange wire from MKR pin 5 is connected as reset to EN (with a wire under the ESP32 board)
io 0 of ESP32 is the yellow wire to MKR pin 4
VSPI pins 5, 18, 19, 23 (I changed 12 to 19 in firmware). white wire on MKR pin 7 and ESP32 pin 19 is CS
I used 22 as readyPin (originally 33). white wire on MKR pin 6
I didn't wire I2C and Serial here

The two chips are connected together by both UART and SPI channels.  I am unsure, but I think the main communication is performed over SPI and the UART is only used for programming and debugging of the NINA.

source: Stack Exchange

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

sort: votes


text:
Generate number
I wanna make some sketch to generate number to represent sensor value, with range from high (900) to low (670), that number decrease with range between 1-10 and with some delay of switching number with range from 5-15 seconds:
    void setup() {
      Serial.begin(9600);
    }

    void number(){
      int sensor = 0;                  //sensor variable
      int a = random(0, 10);           //range subtraction sensor value
      int delay = random(5000, 15000); //range delay switching value
      for(sensor = 900; sensor >= 670; sensor -=a){ //iteration sensor value with range 670-900
        Serial.println(sensor);
        delay(delay);}
    }

    void loop() {
    number();
    }

with output:

900 (delay 7 sec)
894 (delay 3 sec)
988 (delay 5 sec)
979 (delay 9 sec)

The sketch above was work as well, but i still can't using variable "sensor" result after iteration "for" in void loop.
I hope you can help me, thanks.

upvote for well presented question ... this is a programming question, so the c++ tag is valid, but the other 4 tags are not valid ... it is not completely clear what you are asking, but that appears to be because of language difference

i just wanna generate random number, with range, maybe had another alternative sketch?

To use the for() loop iteration variable after the end of the loop, it has to be defined outside of the loop. Defining a variable in the loop is a convenience for when you only need it inside the loop.

how to upvote? so i need to make variable utside the loop?

int sensor = 900;                 //variabel sensor

void setup() {
  Serial.begin(9600);
  while (!Serial);
  randomSeed(analogRead(A0));
}

int number() {
  int a = random(0, 10);          //range pengurang nilai sensor
  int d = random(500, 1500); //range delay perubahan nilai
  if (sensor < 670) {
    sensor = 900;
  }
  sensor -= a;
  delay(d);
  return sensor;
}

void loop() {
  int val = number();
  Serial.println(val);
}

I modified the delay for test.
randomSeed ensures different random values at every run
EDIT: a not blocking version which returns the same values for random interval:
int sensor = 900;                 //variabel sensor
unsigned long nextChangeMillis = 0;

void setup() {
  Serial.begin(9600);
  while (!Serial);
  randomSeed(analogRead(A0));
}

int number() {

  if (millis() < nextChangeMillis)
    return sensor;

  int a = random(0, 10);          //range pengurang nilai sensor
  int d = random(500, 1500); //range delay perubahan nilai
  if (sensor < 670) {
    sensor = 900;
  }
  sensor -= a;
  nextChangeMillis += d;
  return sensor;
}

void loop() {
  int val = number();
  Serial.println(val);
}

@Juraj Why did you kind of copied my answer? Btw, you don't need to return sensor in number(), since it's a global variable anyway.

@MichelKeijzers, your function returns only the last value. the function number() should simulate values returned from a sensor

@Juraj ... thanks ... I thought that was the intention, but I guess the question was not so clear. Upvoted!

@UlinnuhaLuthfi (I removed my answer, this answer should answer your question already.

and when in practical, analog port A0 was used actual sensor, can i switch value from random seed with constant value?

@UlinnuhaLuthfi, not constant. you would get always the same 'random' sequence

sorry everyone, i just realize how to upvote

To "hide" the variable sensor you could put it inside number() and make it static. This way it's clear that no-one is allowed to access it.

@thebusybee, yes I know. but then I would have to explain it

thanks a lot guys, that sketch was work well, but i get some problem again, when sketch running, range delay 5 sec-15 sec its way too big, and interrupt all system, is there any alternative ways to replace "delay" function?

@Juraj, thank you

you're so fast responed dude, awesome

@UlinnuhaLuthfi, I realized that a sensor would not block but return the same value so I added the improved version some hours ago before your request

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


text:
Spiffs vs Eeprom on esp8266
In my project, i have some data to save permanently. After some research i got many examples and informations to do that with eeprom. I used it effectively.
After all i decide to deep dive to esp8266 and i got some information about spiffs.
Now i know what spiffs is and what its purpose. But i am wondering what is difference between eeprom vs spiffs?
I know both of them using flash memory as same and we can write and store data with them but why spiffs? Why eeprom ? What are their pros and cons or etc.?

Thanks for the answers. I completed some missing parts about it

I don't think it makes any difference from a hardware point of view. The benefits of using the eeprom library is that it avoids rewriting unchanged data (if you use spiffs you might want to implement that as well) and that the esp is compatible with the arduino environment, where there is a real eeprom.
On the other hand, SPIFFS has its advantages (e.g. easy upload, space). It's up to you...

On the ESP8266 there's very little to choose from between the two. It all really boils down to what you want to store and how you best want to access it.
EEPROM emulation is ideal for small bits of data - configuration values and that sort of thing. Where you just want to store a few of values that would seldom change.
SPIFFS though is better at dealing with large amounts of data. Since it's a filesystem it can store actual files, and that makes it ideal for serving images and static data for web pages, for example.
A SPIFFS filesystem can be built on your PC from files of your choice and then uploaded over serial using mkspiffs and esptool.py or the SPIFFS tool that can be installed into the Arduino IDE. That means the files are very easy to update.
SPIFFS is not so great when it comes to writing data though - experiments have shown that it gets quite slow when writing often.  EEPROM doesn't suffer from such a problem, but then you can't write as much data to EEPROM as you can to SPIFFS.
So that's really all there is to it. Neither is "better" than the other, but each is better suited to different ways of working or to different styles of data.

If I save measured data as CSV with SPIFFS, and config data on the EEPROM, can there every be a conflict because the libs write at the exact same location?

No, because SPIFFS and EEPROM are different things.

@Majenko Different in name and API, but under the hood both use the same hardware, namely Flash. The EEPROM on the OP's device is merely an emulation.

I will also add a few more things:
SPIFFS acts like a String or Serial object -- so you can do a println() or whatever else you want, and read/parse it back out. There's also a digital-level access that lets you read or write memory structures directly, too. It is wear-leveled and is wonderful for anything where you need multiple independent configs or lots of (searchable!) data.
You can also upload files (or download them) from a web server, and most things that support Strings to write to can use a File as well (YMMV).
EEPROM is not (unless you specifically downloaded a 3rd-party library to do so) wear-leveled on this system and uses one sector of flash. Writing to it too often will cause the sector to fail (~10,000-100,000 times, so it's a lot though). You are also limited by the size of the sector, so the maximum size of the data you can store is 4096 bytes.
Furthermore, EEPROM is written like an array. All your data ends up in this array, and you have to keep track of where each piece is and how large it was (potentially across multiple libraries, files, or functions). Worse, you can't tell if you changed the format since it was last saved (reuploaded your code or something), so you really should have a checksum or something.

TL;DR:
SPIFFS is larger (storable capacity and in terms of code to access) and wear-leveled. It has a lot of convenience features, and lets you write or compose complex data.
EEPROM is tiny and has a limitation on how many times it can be committed before it fails (bad for datalogging and stuff). At best you can write memory blocks to it.

Edit: SPIFFS has now been deprecated due to lack of support by the devs, which is somewhat sad. It has been replaced by LittleFS, which (annoyingly to me) has more overhead AND does not do static wear-leveling (it only wear-levels to free space when a file is edited/moved, and does not reuse memory consumed by files that don't change (even if those have by far the least wear)). The interface (aside from changing all instances to "LittleFS" instead of SPIFFS, and some other minor things) is largely the same to the user otherwise, however, so this post still applies.


text:
Arduino randomly freezes during runtime?
I'm currently trying to create a traffic simulation project on Arduino, where it can change lights, open a gate, and turn on street lamps based on light. If anybody could help me diagnose why my arduino is behaving this way, that'd be extremely appreciated. Here is my code, if it helps you understand.
//Libraries Used
#include<Servo.h>

//Variable Declaration
int red1 = 10;
int yellow1 = 9;
int green1 = 8;
int red2 = 13;
int yellow2 = 12;
int green2 = 11;
int debug = 3;
int PIR = 5;

int button1 = 2;
int buttonState = 0;

int light = 0;

unsigned long previousTime = 0;
unsigned long currentTime = 0;
int currentState = 0;

int currentPIR = 0;
int pirState = LOW;

Servo servo;

void setup()
{
  pinMode(red1, OUTPUT);
  pinMode(yellow1, OUTPUT);
  pinMode(green1, OUTPUT);
  pinMode(red2, OUTPUT);
  pinMode(yellow2, OUTPUT);
  pinMode(green2, OUTPUT);
  pinMode(debug, OUTPUT);

  pinMode(PIR, INPUT);

  pinMode(button1, INPUT);

  servo.attach(4);
  servo.write(90);
}

void loop()
{

  currentPIR = digitalRead(PIR);
  if(currentPIR == 1){
    servo.write(180);
  }else{
    servo.write(90);
  }

  buttonState = digitalRead(2);
  light = analogRead(A0);

  if(light > 100){
    digitalWrite(debug, HIGH);
  }else{
    digitalWrite(debug, LOW);
  }

  if(buttonState == HIGH){
    if(currentState == 3){
      digitalWrite(debug, HIGH);
      currentState++;
    }
  }
  //Using millis() instead of delay(), so program doesn't pause completely.
  currentTime = millis();
  changeLights();
}

void changeLights(){
  if(currentState == 0){
    //Red, Green
    digitalWrite(red2, LOW);
    digitalWrite(red1, HIGH);
    digitalWrite(green2, HIGH);
    asyncDelay(4000);
  }
  else if(currentState == 1){
    //Red, Yellow
    digitalWrite(green2, LOW);
    digitalWrite(yellow2, HIGH);
    asyncDelay(2000);
  }
  else if(currentState == 2){
    //Red, Red
    digitalWrite(yellow2, LOW);
    digitalWrite(red2, HIGH);
    asyncDelay(750);
  }
  else if(currentState == 3){
    //Green, Red
    digitalWrite(red1, LOW);
    digitalWrite(green1, HIGH);
    asyncDelay(4000);
  }
  else if(currentState == 4){
    //Yellow, Red
    digitalWrite(green1, LOW);
    digitalWrite(yellow1, HIGH);
    asyncDelay(2000);
  }
  else if(currentState == 5){
    //Red, Red
    digitalWrite(yellow1, LOW);
    digitalWrite(red2, HIGH);
    asyncDelay(750);
  }
}

void asyncDelay(int delayTime){
  if(currentTime - previousTime == delayTime){
    currentState++;
    previousTime = currentTime;
    if(currentState == 6){
      currentState = 0;
    }
  }
}

add debugging code to your sketch

You should replace:
if(currentTime - previousTime == delayTime){

with
if(currentTime - previousTime >= delayTime){

There is always a chance that, since you are using a servo which is quite intensive with interrupts, that millis() may skip a beat and that statement can never be true.

Thank you! I don't know why I hadn't thought of this before, but thank you for such a simple fix! I will accept your answer as solved in a few minutes when it allows me to, but thank you so much, I've been so confused over this the whole day.

@BillBai You should confirm it fixes it - it's only a suggestion...

yup, I confirmed it worked, and it's been working for a few minutes already - rather than the 20 seconds max as before.


text:
Cancelling state of code before going to interrupt
Currently, I have two loops in my Arduino code.
Certain cases take me from loop 1 to loop 2
I also have an ISR
When my ISR condition is met the code is executed and part of the ISR code is supposed to go to loop 1. Which it does but...
Then I close the ISR accordingly, but the service routine goes back to loop 2.
Any ideas why?
I've been surfing the web for the past couple hours and haven't caught a wave..
Thanks all.
//Physical variables
int eStop = 3;         // the number of the input pin
int eStopLED = 9;       // the number of the output pin

int dispenseButton = 6;         // the number of the input pin
int dispenseLED = 8;       // the number of the output pin

// have 789 for colors and 3456 for input only 3 ND 6 NEEDS TO BE USED

int eStopZone = HIGH;      // the current eStopZone of the output pin
int eStopScan;           // the current eStopScan from the input pin
int eStopPrior = LOW;    // the eStopPrior eStopScan from the input pin

int dispenseZone = HIGH;      // the current eStopZone of the output pin
int dispenseScan;           // the current eStopScan from the input pin
int dispensePrior = LOW;    // the eStopPrior eStopScan from the input pin

//Other Variables
volatile int vControl = 0;
int eVar;
int i; //Normal counting integer

// will quickly become a bigger number than can be stored in an int.
long time = 0;         // the last time the output pin was toggled
long debounce = 200;   // the debounce time, increase if the output flickers

void control(void);
void emergency(void);
//another coid for char ring

void setup()
{
  pinMode(eStop, INPUT);
  pinMode(eStopLED, OUTPUT);

  pinMode(dispenseButton, INPUT);
  pinMode(dispenseLED, OUTPUT);
  eVar = 0;
  Serial.begin(9600);  //Start Serial
  attachInterrupt(digitalPinToInterrupt(eStop), emergency, CHANGE);
}

void loop()
{
  eStopScan = digitalRead(eStop);
  dispenseScan = digitalRead(dispenseButton);
  //Serial.println(eStopScan);
  /*if (eStopScan == HIGH && eStopPrior == LOW && millis() - time > debounce) { //eStop control conditions
    switch (eVar) {
      case 0:
        vControl = 0;
        control();
        break;

      case 1:
        vControl = 1;
        control();
        break;
    }
    time = millis();
    }
  */

  if (dispenseScan == HIGH && dispensePrior == LOW && millis() - time > debounce) { //dispense control conditions
    Serial.println("in this loop");
    switch (eVar) {
      case 0:
        vControl = 2;
        control();
        break;

      case 1:
        vControl = 3;
        control();
        break;
    }
    time = millis();
  }

  eStopPrior = eStopScan;
  dispensePrior = dispenseScan;
}

void control () {

  switch (vControl) {
    case 0: //estop case put in another variable for showing last estop state
      eStopZone = HIGH;
      dispenseZone = LOW;
      digitalWrite(dispenseLED, dispenseZone);
      digitalWrite(eStopLED, eStopZone);
      eStopScan = LOW;
      dispenseScan = LOW;
      Serial.println("Case 0");
      //eVar = 1;
      break;

    case 1:
      for (int i = 0; i <= 2; i++) {
        eStopZone = LOW;
        digitalWrite(eStopLED, eStopZone);
        delay(345);
        eStopZone = HIGH;
        digitalWrite(eStopLED, eStopZone);
        delay(345);
        Serial.println("Case 1");
        //Serial.println(i);
      }
      break;

    case 2:
      dispenseZone = HIGH;
      eStopZone = HIGH;
      digitalWrite(eStopLED, eStopZone);
      digitalWrite(dispenseLED, dispenseZone);
      Serial.println("here 1");
      delay(1000);
      Serial.println("here?");
      eStopZone = LOW;
      digitalWrite(eStopLED, eStopZone);
      Serial.println("Case 2");
      break;

    case 3:
      dispenseZone = HIGH;
      eStopZone = LOW;
      digitalWrite(eStopLED, eStopZone);
      digitalWrite(dispenseLED, dispenseZone);
      eVar = 0;
      Serial.println("Case 3");
      // make led go green
      break;
  }
  time = millis();
  loop();
}

void emergency () {
  Serial.println("interrupt");
  vControl = 0;
  control();
}

Com window from debugging
in this loop
here 1
here?
Case 2
in this loop
here 1
here?
Case 2
in this loop
here 1
interrupt
interrupt
interrupt
here?
Case 2

Please show us the sketch you're using.

please explain what you understand about an interrupt and about ISR

It is difficult to understand, what you actually mean. Please include your code and a detailed description about what you expected the code to do and what it actually does.

My understanding is that the ISR will get completed and then go back to the state where it left off. However, I thought since im saying to go back into the loop where my variable is now changed it would nullify the previous case..

Your explanation of what you expect to happen is not very clear but I'll take a stab at your question.
First thing - Interrupt Service Routines (ISR) need to be short (execution time, not necessarily code length). Do the minimum necessary to save whatever status or data caused the interrupt and exit. Let the background (your main sketch) handle any further processing resulting from the interrupt.
That means the ISR has to leave some indication - a boolean flag, f/ex - that it did something, and your background has to check that frequently, act on it when it changes, and reset it for the next interrupt.
It looks like your ISR is calling into your background code, which effectively becomes part of the ISR, runs at interrupt level, prevents further interrupts while it is doing so, and (possibly) returns to your background code at a place or in a state that is no longer relevant by then.
Think about organizing your code so that the background does whatever ongoing, routine tasks you need it to be doing, but checking frequently for whether an interrupt has occurred yet. When one has, do whatever needs to done to handle it, reset the "interrupt has occurred" flag, and return to your background task(s).

I cannot see what actually goes wrong, but you're calling way too much stuff in your ISR. You're changing non-volatile variables with the control() call in your ISR, leading to undefined behaviour: You don't know when the ISR is being called, especially not whether it is called before or after the non-volatile variables have been transferred from memory to the registers or back in the routine started from loop(). Also: Never output anything from an ISR nor from code you call from that ISR. Serial communication is slooow (compared to what the processor could be doing in that time frame).
I'd say: The only thing your ISR should do is to add 1 to a volatile variable, then end. In your loop(), check whether that volatile variable is greater than 0, then reset the volatile variable back to 0 and run what you've got in your current ISR. To react to the interrupt in a timely manner, this also means that you should not use delay() anywhere in your code. This would put your code back into defined behaviour, at least.


text:
I2C sensor hogs the bus with empty write commands
I am trying to read data from a pair of TLE493-W2B6 magnetic position sensors [1, 2] with Arduino over I2C. I can read from each sensor individually, using the Arduino library from the manufacturer [3, with corrections from 4], but when I try to read both sensors, I can only read the first sensor I initialize. The first sensor then issues empty write commands, and the second sensor NACKs when I try to address it. The sensors have different factory-programmed addresses, and they are connected to the same I2C bus on a PCB with pullup resistors. When I scan the bus for I2C devices, both sensors show up (ie they both ACK their own address).
How do I read both sensors over I2C with Arduino?
Code for reading both sensors:
#include <Tle493d_w2b6.h>

Tle493d_w2b6 sensor_A0 = Tle493d_w2b6(Tle493d_w2b6::MASTERCONTROLLEDMODE, Tle493d_w2b6::TLE493D_W2B6_A0);
Tle493d_w2b6 sensor_A1 = Tle493d_w2b6(Tle493d_w2b6::MASTERCONTROLLEDMODE, Tle493d_w2b6::TLE493D_W2B6_A1);

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

  sensor_A1.begin();
  sensor_A0.begin();
}

void loop() {
  sensor_A1.updateData();
  Serial.print(sensor_A1.getX());
  Serial.print(", ");
  Serial.print(sensor_A1.getY());
  Serial.print(", ");
  Serial.println(sensor_A1.getZ());

  sensor_A0.updateData();
  Serial.print(sensor_A0.getX());
  Serial.print(", ");
  Serial.print(sensor_A0.getY());
  Serial.print(", ");
  Serial.println(sensor_A0.getZ());

  delay(500);

}

Here is what the average cycle looks like:

(0.005ms) Read the first six registers of sensor A1.

Address frame =  0x22
R/W = R
Data frames = FF 00 FF 80 F1 1F 6A~ (this is as expected)

(0.828ms) Library sends empty write command to sensor A1?

Address frame =  0x22
R/W = W
Data frames = empty

(2.281ms) Attempt to read the first six registers of sensor A0, address is NACK'd, no data is returned.

Address frame =  0x35~
R/W = R
Data frames = empty

(2.353ms) Library sends another empty write command to sensor A1.

Address frame =  0x22
R/W = W
Data frames = empty

There seems to be something wrong at the fundamental I2C protocol execution. There are no empty writes or reads in the library (I think this isn't even possible with the Wire library, which is used there). Also the spike at the end of the 0x44 write span (as in the image) is suspicious. The sensor is operating at 3.3V. Do you use a 3.3V Arduino? You didn't specify

I was using the 5V rail on the Arduino to power the sensors. I replaced the sensors, and I am now powering them off the Arduino's 3.3V rail, with the Arduino's internal I2C pullups disabled and external pullups to the 3.3V. Still having the same issue. I am going to try sending bits with an I2C host adapter, to see if it's a problem on the Arduino side.

By default the sensor adds trigger bits to the register address, so I'm having some trouble communicating with the device. I'm having some trouble getting the right initialization sequence.


text:
Is it possible to get values only during vibration/movement from an Accelerometer(ADXL335/MPU6050)?
I'm trying to make a wearable motion sensor using ESP32 board and ADXL335 Accelerometer.
Presently when I'm serial printing the output I'm getting the tilt value as well, which have different values at different orientation (I'm printing average of the X,Y & Z). So when I try to light up an led by setting a threshold the average value is different in different orientation.
Is there way to get values only during vibration and be zero when there is no vibration/body movement.
Thanks in advance guys for the help.

i think that your question needs to be about recognizing movement

Acceleration is a vector quantity. Therefore, instead of looking at the average values of X,Y, and Z, you should probably look at the magnitude of the acceleration vector, that is (X^2+Y^2+Z^2)^0.5. Then, you can set an acceleration threshold below which you would send no data.
The benefit of using the magnitude of the acceleration vector is that it is independent of the orientation of the device. For example, if you placed the device on a table along the X-axis, the accelerometer would read something like X = -g, Y=0, Z=0, where g is the gravitational acceleration. Similarly, if you placed the device on a table at 45 degrees between X and Y axes, the accelerometer would read something like X = -g sqrt(2)/2, Y=-g sqrt(2)/2, Z=0. In both cases, the magnitude of the acceleration vector is just g. On the other hand, the average values would be -g/3 and -g sqrt(2)/3, respectively, as you observed in "...the average value is different in different orientation."

Thanks a lot for the help  @Kavka. I'll try this way.

Still the magnitude is different with different orientation.

Yes.
Linear Acceleration at given axis = Actual Acceleration - Gravitational Acceleration
Gravitational Acceleration across any Axis = Magnitude of Gravity Vector x Cosine of axis angle with the Gravity Vector


text:
Bootloader difference between Atmel328p(through hole) and Atmel328p au(smd)
It’s been bugging me lot that Can’t we burn the same bootloader for both 328p and 328p au?
I got confused when I see this linksmd 328p au bootloader burn.
Will there be any impact on performance or any other impact if I use same bootloader for both?

AFAIR the bootloader is the same for both chips.

My question is, I read if we burn 328p bootloader to smd 328p au, it might not perform well. That’s how I got this url as a reference. Because Uno is having through hole chip with 28 pins and smd 328p is having 32 pins. I’ll update where I read that smd chip 32 pins might not perform well if we upload 328p through hole chip bootloader.

Your link does not mention explicitly, which bootloader is used. The IDE allows to choose different boards, which refers to different sections in boards.txt There the address of the appropriate bootloader is found. Uno and Nano should refer to the same optiboot/optiboot_atmega328.hex

@DataFiddler, the tutorial is before Nano had a bootloader selection.

The bootloader doesn't care about how many pins the device has. All it cares about is the UART pins, and they are the same.
Internally the two chips are the same, it's just the packaging that is different. They take the same silicon chip and mount it on a different lead frame and encapsulate it in epoxy. Which is why the only pin differences are a couple of extra power and ground pins, and two dedicated ADC pins that they don't connect in the DIP package.  Even the pins are in the same order around the chip if you examine the pinouts in the datasheet.
Whether you use the DIP (Uno) or the SMD (Nano) bootloader it makes no difference (the two bootloaders are the same anyway). There can be no "perform better" anyway, since that isn't a valid concept. Either it is compatible, in which case it will work, or it's not, in which case it won't.
The only real thing of concern is to ensure that your fuses are set correctly for your chosen clock source, and that the bootloader you install is compiled to run at the speed of your chosen clock source. That has nothing at all to do with which chip it is you are using, but how you have designed your circuit.

I got the clarity now. Thanks. By the way I’m am using it with 16Mhz and 22pf capacitors as a normal Arduino simple circuit nothing super.

I was in an impression of two different bootloaders for them. Thanks again for clarifying.

Two different bootloaders are used for ATmega328p. One is used in Uno, it is based on Optiboot 4. Second is used in Arduio Nano and is based on Atmel bootloader. Arduino replaced the old Nano bootloader with the Uno Optiboot bootloader in 2018, but Nano clones and old Nanos still in use have the old bootloader. In current AVR boards package version there is a bootloader selection in Tools menu.
With the burn of bootloader fuses are written to set the bootloader area size.
The old Nano bootloader is 2 kB large. The Optiboot bootloader is 0.5 kB large (small). But Arduino didn't change for Nano the size of the flash memory reserved for bootloader so 1.5 kB of flash memory is lost because of inaccurate fuse setting.
The old Nano bootloader didn't reset the watchdog flag. If your sketch setup the watchdog for some short time, after the reset the watchdog did reset the MCU while still in bootloader ending in endless reset loop.
The tutorial in your question would flash the Nano bootloader, because the author of the tutorial has Nano as target board while burning the bootloader. In 2017 it would be the Old bootloader.
So the Uno bootloader is recommended for ATmega328p with Uno fuse settings for bootloader size. After uploading the "Arduino as ISP" sketch and before activating "Burn bootloader" change the board selection to Uno.
Notes:

For ATmege328p with different frequency then 16 MHz the bootloader must by build with the required frequency.
there are newer versions of Optiboot (7 is current) with additional options. Some of the options result in larger bootloader.


text:
Multiple Time-Sensitive Tasks
I'm using an Arduino Leonardo and need to perform two time-sensitive tasks like this:
// Task 1 - Gets executed once a second (1Hz)
// Execution of task needs approx 70ms
   task1(); //Sending a message via Serial

// Task 2 - Gets executed 50 times a second (50Hz)
// Execution of task need a few micros
   task2(); //digitalWrite

As you can see, the problem is, that task one needs very long for execution and therefore task2 is executed too late to send a 50Hz signal. I'm not sure how, but I think there must be a way to give task 1 higher priority to interrupt task 2?
Thanks in advance! :)
Just for completion, here is my (not so clean) code:
#include <SoftwareSerial.h>
SoftwareSerial mySerial(7, 6); //232_TX,232_

int triggerFreq = 10;
unsigned long timestamp_pps;
unsigned long timestamp;
unsigned long triggerStartTime;
const unsigned long dt_pps = 1000000; //micros
const unsigned long dt_trig = 1000000/triggerFreq; //micros
unsigned long ts_pps_high;
unsigned long ts_pps_low;
unsigned long ts_msg_high;
unsigned long ts_msg_low;

unsigned long i_pps = 0;
unsigned long i_trig = 0;

int hh = 04;
int mm = 51;
int ss = 00;
unsigned int pos = 2307;
bool msg;
bool trigMsgSent;

void setup() {
  // put your setup code here, to run once:
  pinMode(11, OUTPUT); // PPS
  pinMode(12, OUTPUT); // Indicator of msg_sent
  pinMode(13, OUTPUT); // FPS
  Serial.begin(9600);
  mySerial.begin(9600);
  triggerStartTime = micros();
}

void loop() {
  // ================== Part for the GPS Simulation ==================
  timestamp_pps = micros()-triggerStartTime;
  if (timestamp_pps>= dt_pps*i_pps+350000)
  {
    pos += 1;
    digitalWrite(12,HIGH);
    i_pps +=1;
    if (ss == 59)
    {
      ss=0;
      if (mm==59)
      {
        mm=0;
        hh+=1;
      }
      else mm+=1;
    }
    else ss+=1;

    ts_msg_high = micros();
    mySerial.print("$GPRMC,");
    if (hh<10) mySerial.print(F("0"));
    mySerial.print(hh);
    if (mm<10) mySerial.print(F("0"));
    mySerial.print(mm);
    if (ss<10) mySerial.print(F("0"));
    mySerial.print(ss);
    mySerial.print(".000,A,3015.");
    mySerial.print(pos);
    mySerial.println(",N,09749.2872,W,0.67,161.46,030913,,,A*7C");

    // Print Debug Messages
    digitalWrite(12,LOW);
    ts_msg_low=micros();
    Serial.print("PPS at: ");
    Serial.print(ts_pps_high);
    Serial.print("\t PPS low after: ");
    Serial.print(ts_pps_low-ts_pps_high);
    Serial.print("\t MSG high after: ");
    Serial.print(ts_msg_high-ts_pps_high);
    Serial.print("\t MSG low after: ");
    Serial.print(ts_msg_low-ts_pps_high);
    Serial.print("$GPRMC,");
    if (hh<10) Serial.print(F("0"));
    Serial.print(hh);
    if (mm<10) Serial.print(F("0"));
    Serial.print(mm);
    if (ss<10) Serial.print(F("0"));
    Serial.print(ss);
    Serial.print(".000,A,3015.");
    Serial.print(pos);
    Serial.println(",N,09749.2872,W,0.67,161.46,030913,,,A*7C");
  }
  else if (timestamp_pps>=dt_pps*i_pps+100000)
  {
    digitalWrite(11,LOW);
    if (msg==true)
    {
      msg = false;
      ts_pps_low = micros();
    }

  }
  else if (timestamp_pps>=dt_pps*i_pps)
  {
    digitalWrite(11,HIGH);
    if (msg==false)
    {
      msg = true;
      ts_pps_high = micros();
    }
  }
  // ================== Part for the FPS Trigger ==================
  timestamp = micros()-triggerStartTime;
  if (timestamp>= dt_trig*i_trig+2000)
  {
    digitalWrite(13,LOW);
    i_trig +=1;
    trigMsgSent = false;
  }
  else if (timestamp >=dt_trig*i_trig)
  {
    digitalWrite(13,HIGH);
    if (trigMsgSent == false)
    {
      Serial.print("FPS at: ");
      Serial.println(micros());
      trigMsgSent = true;
    }
  }

}

Update: So i implemented it with an interrupt according to this example. I just programmed the interrupt for the 50Hz signal, because that one must be accurate. The code is at the end. However, I'm still experiencing the 50Hz signal to be late when the serial is sent. It's now in the dimensions of half a millisecond, but that's not negligible in my project (Sensor fusion computer vision). The output of my post-processing-tool shows:
Trigger Nr. 25 is 646.912us late!
Trigger Nr. 28 is 434.176us late!
Trigger Nr. 75 is 653.056us late!
Trigger Nr. 78 is 429.056us late!
Trigger Nr. 125 is 646.912us late!
Trigger Nr. 128 is 434.944us late!
Trigger Nr. 175 is 646.912us late!
Trigger Nr. 178 is 439.04us late!
Trigger Nr. 225 is 646.912us late!
Trigger Nr. 228 is 440.064us late!
Trigger Nr. 275 is 647.168us late!
Trigger Nr. 278 is 434.944us late!
Trigger Nr. 325 is 611.84us late!
Trigger Nr. 328 is 462.08us late!
Trigger Nr. 375 is 612.864us late!
Trigger Nr. 378 is 475.136us late!
Trigger Nr. 425 is 619.008us late!
Trigger Nr. 428 is 473.856us late!
Trigger Nr. 475 is 613.888us late!
Trigger Nr. 478 is 467.968us late!
Trigger Nr. 525 is 612.864us late!
Trigger Nr. 528 is 474.88us late!
Trigger Nr. 575 is 613.12us late!

Does anyone know how I could improve my code?
Code:
//GPS DEFINITIONS
#include <SoftwareSerial.h>
SoftwareSerial mySerial(7, 6); //232_TX,232_

int triggerFreq = 50;
unsigned long timestamp_pps;
//unsigned long timestamp;
unsigned long triggerStartTime;
const unsigned long dt_pps = 1000000; //micros
//const unsigned long dt_trig = 1000000/triggerFreq; //micros
unsigned long ts_pps_high;
unsigned long ts_pps_low;
unsigned long ts_msg_high;
unsigned long ts_msg_low;

unsigned long i_pps = 0;
//unsigned long i_trig = 0;

int hh = 04;
int mm = 51;
int ss = 00;
unsigned int pos = 2307;
bool msg;
bool trigMsgSent;

void setup() {

  cli();//stop interrupts
  //set timer1 interrupt at 1Hz
  TCCR1A = 0;// set entire TCCR1A register to 0
  TCCR1B = 0;// same for TCCR1B
  TCNT1  = 0;//initialize counter value to 0
  // set compare match register for 1hz increments
  //OCR1A = 15624;// = (16*10^6) / (1*1024) - 1 (must be <65536)
  OCR1A = 19999; // = (16*10^6) / (100 * 8) -1 (must be <65536)
  // turn on CTC mode
  TCCR1B |= (1 << WGM12);
  // Set CS11 bit for 8 prescaler
  TCCR1B |= (1 << CS11);
  // enable timer compare interrupt
  TIMSK1 |= (1 << OCIE1A);
  sei();//allow interrupts

  // GPS SETUP
  pinMode(11, OUTPUT); // PPS
  pinMode(12, OUTPUT); // Indicator of msg_sent
  pinMode(13, OUTPUT); // FPS
  Serial.begin(9600);
  mySerial.begin(9600);
  triggerStartTime = micros();

}

ISR(TIMER1_COMPA_vect){  //change the 0 to 1 for timer1 and 2 for timer2
   //interrupt commands here
   digitalWrite(13,!digitalRead(13));
}

void loop() {
  // ================== Part for the GPS Simulation ==================
  timestamp_pps = micros()-triggerStartTime;
  if (timestamp_pps>= dt_pps*i_pps+350000)
  {
    pos += 1;
    digitalWrite(12,HIGH);
    i_pps +=1;
    if (ss == 59)
    {
      ss=0;
      if (mm==59)
      {
        mm=0;
        hh+=1;
      }
      else mm+=1;
    }
    else ss+=1;

    ts_msg_high = micros();
    mySerial.print("$GPRMC,");
    if (hh<10) mySerial.print(F("0"));
    mySerial.print(hh);
    if (mm<10) mySerial.print(F("0"));
    mySerial.print(mm);
    if (ss<10) mySerial.print(F("0"));
    mySerial.print(ss);
    mySerial.print(".000,A,3015.");
    mySerial.print(pos);
    mySerial.println(",N,09749.2872,W,0.67,161.46,030913,,,A*7C");

    // Print Debug Messages
    digitalWrite(12,LOW);
    ts_msg_low=micros();
    Serial.print("PPS at: ");
    Serial.print(ts_pps_high);
    Serial.print("\t PPS low after: ");
    Serial.print(ts_pps_low-ts_pps_high);
    Serial.print("\t MSG high after: ");
    Serial.print(ts_msg_high-ts_pps_high);
    Serial.print("\t MSG low after: ");
    Serial.print(ts_msg_low-ts_pps_high);
    Serial.print("$GPRMC,");
    if (hh<10) Serial.print(F("0"));
    Serial.print(hh);
    if (mm<10) Serial.print(F("0"));
    Serial.print(mm);
    if (ss<10) Serial.print(F("0"));
    Serial.print(ss);
    Serial.print(".000,A,3015.");
    Serial.print(pos);
    Serial.println(",N,09749.2872,W,0.67,161.46,030913,,,A*7C");
  }
  else if (timestamp_pps>=dt_pps*i_pps+100000)
  {
    digitalWrite(11,LOW);
    if (msg==true)
    {
      msg = false;
      ts_pps_low = micros();
    }

  }
  else if (timestamp_pps>=dt_pps*i_pps)
  {
    digitalWrite(11,HIGH);
    if (msg==false)
    {
      msg = true;
      ts_pps_high = micros();
    }
  }

}

You may try to run task2 from a timer interrupt: this way it will be able to interrupt task1. Do a web search for “Arduino timer interrupt”.

Here lies your ≈ ½ ms problem:

#include <SoftwareSerial.h>

SoftwareSerial is very time sensitive. It generates the serial stream by
bit-banging, with interrupts disabled. For each byte sent, interrupts
are disabled just before sending the start bit, and re-enabled just
after the stop bit has been written. At 9600 bps, interrupts are
thus disabled for a little more than 9 bit times on each byte, i.e.
936 µs.
Do not use SoftwareSerial if you need short interrupt latency. Use a
hardware serial port instead. This can be problematic on the Uno, where
you would loose the ability to send debugging info, but it is fine on
the Leonardo.
Alternatively, if the only thing your ISR has to do is toggle a pin,
you can instead configure the timer to generate that as PWM. This way
the CPU is not involved at all in the pin toggling, and you get
cycle-accurate signal timing irrespective of interrupt latency.

Edit: Answering your comment.
About the hardware serial ports: on the Uno you just have Serial, so
you are out of luck if you want one port for outputting NMEA sentences
and another one for debugging information. However, on the Leonardo,
Serial is a virtual serial port emulated over USB. The real hardware
serial port is called Serial1, and you should use it in preference to
a SoftwareSerial instance.
About “more than just toggle the pin”: You may still be able to use PWM
if whatever other stuff task2 has to perform is less time-critical than
toggling the pin. In this case, you use PWM to toggle the pin on the
TIMER1_COMPA event, and ISR(TIMER1_COMPA_vect) to do the other
stuff. Then, each time the timer hits TIMER1_COMPA, it will
immediately toggle the pin and, at the same time, rise an interrupt
request. The CPU may take some time to service the request, but this
delay could be acceptable if only the toggling needs extra-accurate
timing.

What do you mean by "Use a hardware serial port instead"? How would you implement this?
I will need to to more than just toggle the pin. It's just not implemented yet

@MarayJay: See amended answer.

Two possible solutions:

Split the serial string in small pieces so it's (comfortably) less than 50 ms and send the string in 'pieces' … you could even send it until e.g. 45 ms has been reached and continue in the next round. Use the Blink Without Delay mechanism to switch between the tasks.
More robust solution: Make Task 2 an interrupt... This is probably much easier, since you can keep sending the serial string and the MCU takes care of automatically starting the interrupt each 50 ms. Make sure the interrupt code is very short. When it is finished, it will automatically resume with the normal code (sending serial data). I have not checked this library, but it seems very simple to use: https://playground.arduino.cc/Code/Timer/ .

Thanks! I implemented it with an interrupt. I'm not sure where I should post my solution code? Should i edit your answer or update my question?

It's not mandatory but it may help others, so it's always good... I would create a new answer. Good luck with your project.


text:
Arduino encrypted Radio communication
Is there any way or library to communicate two Arduino devices with encrypted connection using modules NRF24L01 or "433Mhz RF" ? Similar encryption like CCMP in Wi-Fi network.

There is no answer at all.

Ups, the question, if this answers your question was added automatically. Your original was closed because it needs more focus. You asked the exact question again, so this question will also be closed

Please read both questions, and you will see the difference...

I have done so. Both question are exactly the same. Besides exchanging one "wireless" with "Radio" in the title. The rest is exactly the same.

Please compare.

New Question: Is there any way or library to communicate two Arduino devices with encrypted connection using modules NRF24L01 or "433Mhz RF" ? Similar encryption like CCMP in Wi-Fi network.
Old Question(updated, but it's already closed):What is the best way/library to communicate two Arduino devices with encrypted connection using modules NRF24L01 or "433Mhz RF" ?

When I google "Arduino encryption library" I find this about an AES library for example. Would that help you?

Ah, ok, now I'm seeing. You already edited your old question to replace the "best way", that was critisized in the comments.

you asked a yes/no question that has an answer of yes ... that seems kind of pointless to me

ESP-NOW offers an encrypted mode at a lower performance rate.

Communicating and Encryption are to completely separate things. How you communicate (with what device) has no relevance to encryption. True, there are devices that can themselves encrypt data, but they tend to be higher-end or geared towards a specific purpose (such as WiFi).
What you send is just data. What that data consists of is entirely up to you.  If you want your communications encrypted then send encrypted data before sending it and decrypt it after receiving it.
Of course, you have to then consider such things as sharing of keys, etc.
There are numerous ways of encrypting data, but one of the easiest to implement on Arduino is AES, for which there is a library here.


text:
Error to work in reverse VNH2SP30
ım building a rover and ı using Johson 12v Dc motor and VNH2SP30. My code and motor works perfectly but my motor driver works only one way. It cant go to reverse and motor starts buzzing when it tries to go in reverse. Here is the code ım using for testing.
#define BRAKE 0
#define CW    1
#define CCW   2
#define CS_THRESHOLD 15   // Definition of safety current (Check: "1.3 Monster Shield Example").

//MOTOR 1
#define MOTOR_A1_PIN 7
#define MOTOR_B1_PIN 8

#define PWM_MOTOR_1 5

#define CURRENT_SEN_1 A2

#define EN_PIN_1 A0

#define MOTOR_1 0

short usSpeed = 150;  //default motor speed
unsigned short usMotor_Status = BRAKE;

void setup()
{
  pinMode(MOTOR_A1_PIN, OUTPUT);
  pinMode(MOTOR_B1_PIN, OUTPUT);

  pinMode(PWM_MOTOR_1, OUTPUT);

  pinMode(CURRENT_SEN_1, OUTPUT);

  pinMode(EN_PIN_1, OUTPUT);

  Serial.begin(9600);              // Initiates the serial to do the monitoring
  Serial.println("Begin motor control");
  Serial.println(); //Print function list for user selection
  Serial.println("Enter number for control option:");
  Serial.println("1. STOP");
  Serial.println("2. FORWARD");
  Serial.println("3. REVERSE");
  Serial.println("+. INCREASE SPEED");
  Serial.println("-. DECREASE SPEED");
  Serial.println();

}

void loop()
{
  char user_input;

  while(Serial.available())
  {
    user_input = Serial.read(); //Read user input and trigger appropriate function
    digitalWrite(EN_PIN_1, HIGH);

    if (user_input =='1')
    {
       Stop();
    }
    else if(user_input =='2')
    {
      Forward();
    }
    else if(user_input =='3')
    {
      Reverse();
    }
    else if(user_input =='+')
    {
      IncreaseSpeed();
    }
    else if(user_input =='-')
    {
      DecreaseSpeed();
    }
    else
    {
      Serial.println("Invalid option entered.");
    }

  }
}

void Stop()
{
  Serial.println("Stop");
  usMotor_Status = BRAKE;
  motorGo(MOTOR_1, usMotor_Status, 0);
}

void Forward()
{
  Serial.println("Forward");
  usMotor_Status = CW;
  motorGo(MOTOR_1, usMotor_Status, usSpeed);
}

void Reverse()
{
  Serial.println("Reverse");
  usMotor_Status = CCW;
  motorGo(MOTOR_1, usMotor_Status, usSpeed);
}

void IncreaseSpeed()
{
  usSpeed = usSpeed + 10;
  if(usSpeed > 255)
  {
    usSpeed = 255;
  }

  Serial.print("Speed +: ");
  Serial.println(usSpeed);

  motorGo(MOTOR_1, usMotor_Status, usSpeed);
}

void DecreaseSpeed()
{
  usSpeed = usSpeed - 10;
  if(usSpeed < 0)
  {
    usSpeed = 0;
  }

  Serial.print("Speed -: ");
  Serial.println(usSpeed);

  motorGo(MOTOR_1, usMotor_Status, usSpeed);
}

void motorGo(uint8_t motor, uint8_t direct, uint8_t pwm)         //Function that controls the variables: motor(0 ou 1), direction (cw ou ccw) e pwm (entra 0 e 255);
{
  if(motor == MOTOR_1)
  {
    if(direct == CW)
    {
      digitalWrite(MOTOR_A1_PIN, LOW);
      digitalWrite(MOTOR_B1_PIN, HIGH);
    }
    else if(direct == CCW)
    {
      digitalWrite(MOTOR_A1_PIN, HIGH);
      digitalWrite(MOTOR_B1_PIN, LOW);
    }
    else
    {
      digitalWrite(MOTOR_A1_PIN, LOW);
      digitalWrite(MOTOR_B1_PIN, LOW);
    }

    analogWrite(PWM_MOTOR_1, pwm);
  }
}

Looks like you're controlling it right at first glance. Care to share your wiring?

swap the wires between pin 7 and pin 8

hi i just added to wires but ıts not perfectly same


text:
How to prevent the garbage data when the serial port is initialised?
I use Arduino Uno. I get garbage in Serial Monitor or HyperTerminal right after I connect to the port. Here is an example code:
void setup() {
  // initialize serial:
  Serial.begin(57600);

}

void loop() {

    Serial.println("Test");
}

An example screenshot of the output. When port is re-connected the first received data is not Test:

So my problem is when the port is initialised the first data received is garbage. Is there a way to prevent this happening? Is that something to do with bootloader baud rate? I tried other baud rates and get same issue and I really want to use 57600 or 115200 baud rate.

I mean  during Serial.begin(57600); I get garbage values. How can I skip this?

@jsotola I re-articulated the problem. Please see the edit.

If I comment out I get nothing. By "When port is re-connected" means clicking "call" in HyperTerminal or openning Arduino serial monitor. First data is always garbage.

In HyperTerminal  there is Disconnect and Call buttons which closes and initiates the port. Similar to Arduino's serial monitor. I couldnt find a fix.

this may be an XY problem ... why are random characters a problem?

use a terminating or initializing char to trigger monitoring on the PC side; that way, any inadvertent signals get ignored.

Your use of the terminology in your edited post and comments is problematic because you are not being clear enough. For example:
"I mean during Serial.begin(57600); I get garbage values. How can I skip this? " and "If I comment out I get nothing".
"By "When port is re-connected" means clicking "call" in HyperTerminal or openning Arduino serial monitor. First data is always garbage". There are others."
"An example screenshot of the output. When port is re-connected the first received data is not Test:" - But, the first received data you are showing is, in fact, the word Test.
There are others.
I will try to help by answering your main question which seems to be "How to prevent the garbage data" and note that I have not included "when the serial port is initialized".
Firstly, when I use my Uno and V 1.8.13 of the IDE, and I compile and run your sample program, I get the usual output showing progress of the compilation and upload to the board, and that text ends with "avrdude done.  Thank you." At this point, the program is running and println is doing its thing.
When I open the serial monitor (by clicking on the box in the upper right corner of the full IDE screen - baud rate=57600, no line ending), I get corrupt characters at first. This always happens and I believe that is what you are seeing.
This happens because when you open the serial monitor, the UNO is being reset, but it is not the complete reset that is done when you upload code and begin execution. To be a bit simplistic, when you open the serial monitor, your program is running and the reset from opening the serial monitor is not the clean start that is done when you compile, upload and begin to execute the program.
Use either of these programs to test out what I am getting at.
void setup() {
  // initialize serial:
  Serial.begin(57600);
}

void loop() {
    delay(10000);
    while(1){
    Serial.println("Test");
    }
}

or
void setup() {
  // initialize serial:
  Serial.begin(57600);
  delay(10000);
}

void loop() {
  Serial.println("Test");
}

Go through your steps with either of these modified versions and open the serial monitor during the 10 second delay (unclick autoscroll to make it easier to see) and you will not get any corruption.
If, however, you compile/load/execute the program and then start opening and closing the serial monitor, you will start to see corruption in subsequent opens of the serial monitor - again because the reset when you open the serial monitor is not the clean reset that is done when you compile/load/execute.
Why doesn't everybody complain like crazy about the problem that you are experiencing? I think because folks learns to work with/around the way the UNO works. Your code just sends out serial data, so it is a prominent illustration of the issue, but it is not an insurmountable issue.
You can go deep into the serial monitor code and learn all about what is going on and come up with an elegant and likely tedious solution - I'm not sure, but I don't doubt that some have done this and it may even involve some hardware manipulation of serial control lines.
Alternatively, you can write the program to allow time to complete the serial monitor opening before you start sending out the data. You can even clean out any residual data (as long as you know what you are doing) if you anticipate multiple opening and closings.
Hope it helps.

There are probably a number of reasons that might contribute to the problem that you are observing:

You are trying to send the string "Text" within the main loop without any delay between println calls. So the microprocessor is running at full speed and trying to send the string "Text" much faster than the baud rate can accommodate. The serial interface has a finite I/O buffer, which is probably filling very fast and overwriting old values in the middle of serial transmission. Hence potentially garbage characters.
Even when HyperTerminal is not running, the PC and Arduino are exchanging serial messages. So when you start HyperTerminal at some arbitrary time, the data in the serial buffer might not correspond cleanly to the start or end of a transmission.

As an alternative, you may want Arduino wait for a serial command from the PC before starting to send the serial data. For example, when using the Serial Monitor, you may send a key press to Arduino, which would then start sending data so that no data is lost while there is no body listening on the PC side or while a terminal program is not running.
Finally, flushing the serial buffers on either side of the serial connection might help you clear partial serial messages.

Reason 1 is not valid: Serial.println() does not overwrite bytes that have not yet been sent. It instead switches to blocking mode, where it waits for the interface to make enough room in the buffer for the new message.

The Serial object blocks when the UART buffer is full, so no data gets overwritten in the UART buffer.


text:
Long range wireless RC airplane control
I pretty new to Arduino and I need help to clarify some things.
 First, I want to make an Arduino controlled RC airplane but I don't know what communication module to use. I did some research and found three options.
1. Hc 12 Bluetooth: It has a decent range of about
    1.8km, buy suffers from delay(it can't be used on
     fast rc cars or airplanes)
2. Nrf24I01: About 850m in open space, uses
     2.4ghz which perfect for RC planes but doesn't
     really work through walls.
3. Lora: has a range of up to 10km but I didn't read on it that much.
So my question is: which one is better to use in a mini uav. I have no problem with mounting an antenna on top of my building. Will any of these work or is it better to use a wifi module connected to a modem which gives it internet access so that I can control the plane over the internet.

Any standard RC. For long range TBS CrossFire. For standard range (up to 2 km) - any other 2.4 control. Let say Jump[er T16 with any RX. As you new in Arduino I guess you also new in flight controllers SW. So better to start with something already manufactured. Let say legacy (old) ArduPilot was based on Arduino Mega. Sources can be found on APM site.

Can you pls elaborate more. By the way, I'm on a tight budget.

i think that HC12 is not a bluetooth module

you could use a module that uses the cellular phone network

@Brandy, what do you mean: APM is here: https://github.com/ArduPilot/ardupilot TBS is here: https://www.team-blacksheep.com/shop/cat:cat_crossfire#product_listing Any RC things are expensive except toys

@jsotola, no. It will not work because of latency. Nothing that has more than 20-40ms delay will never work with UAV (may be with car but on very slow speed).

i like ESP-NOW; cheap, fast, semi-simple, longer range than raw wifi.

Regarding "Lora: has a range of up to 10km...", I know this is not your question but, if you are based in the US, there are laws about keeping constant visual contact (line-of-sight) with autonomous aerial vehicles. And usualy, 10 km is very much of out of that range.

I guess I’ll have to use the ESP for the project. Thanks


text:
Pressure Switch 4-20mA
Im working on a project trying to read the pressure value from an Allen Bradley Pressure Transmitter 836P-D2NFGB20PA-D4 Ser.A

However the pin configuration that comes on the description along with the schematics its way different that the one i used before

And the circuit im using is like this one, on the top its the circuit from the pressure documentation, and the bot one it the one im wiring on my Arduino Uno.
However on arduino im reading a constant value of 230 that does not increase nor decrease when i apply pressure to mi sensor even when the lcd on my sensor displays the correct psi value.

#include <LiquidCrystal.h> //libreria
int V0 = 3;
int RS= 4;
int E = 5;

int D4 = 6;
int D5 = 7;
int D6 = 8;
int D7 = 9;
LiquidCrystal lcd(RS, E, D4, D5, D6, D7); //Indicar los pins de la interfaz

//Variables globales
int SensorPin= 0; //Variable del pin de entrada del sensor
int indice; //posicion del array de textos
int presion; //variable para almacenar el valor obtenido del sensor(0 a 1023)
int outputValue = 0;
int state = 0;
int prv_state = -1;

#define ARRAYTXT 4 //Numero de textos a escribir

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

Serial.begin(9600);
analogWrite(V0, 50);

//lcd.begin(16, 2);
//lcd.clear();
//lcd.begin(Cols, Rows);
}

void loop() {

 //Configuramos un comando de textos
  String textos[ARRAYTXT] = {"Baja presion", "Presion normal", "Alta presion", "Apagar Maquina"};

  presion = analogRead(SensorPin); //obtenemos datos del sensor
    outputValue = map(presion, 175, 1023, 0, 367);

//Indicamos los textos que se definieron en el comando texto al principio("Baja presion" = 0)
  if(outputValue < 50){
    indice = 0;
  } else{
    if(outputValue >=50 && outputValue < 100){
      indice = 1;
    }else{
      if(outputValue >=100 && outputValue < 200){
        indice = 2;
      }else{
        if(outputValue >=200 && outputValue < 350){
          indice= 3;
        }
      }
    }
  }
  //lcd.clear(); // se borran pantallas
  //lcd.setCursor(0, 0); //Escribimos en la fila de abajo
  Serial.print("PRESION: "); // escribimos mensaje en el lcd
  Serial.print(outputValue,DEC);
  Serial.println(" PSI");
  //lcd.setCursor(0, 1); //Escribimos en la fila de abajo
  Serial.println(textos[indice]); // Indicamos que imprima los indices
  //Serial.print("Psi ");
  //Serial.println(outputValue);
  delay(200); //Tiempo para repetir el mensaje(1 segundo)
  //lcd.clear();
}

Try disconnecting pin 4.

I tried disconnecting the pin4 (OUT) and there is no difference, the serial port on arduino ide is -75psi or 270psi but it does not increment or decrement.

pin 4 appears to be a voltage output ... disconnect the current loop (pin 2) .... or put a resistor between pin 2 and pin 4 and measure the voltage across the resistor

Here is a similar situation, at the very least it has useful information for you.
Search for "reading-4-to-20ma-pressure-sensor-using-uno" here at stackexchange.

Your drawing is different from the drawing in the wiring diagram of that sensor: the resistor has to be connected right like the "4-20mA"-block in the drawing, (-) goes to ground. Measure the voltage directly at pin 2.
When reading the sensor's analog signal you can probably leave pin 4 floating.

I changed the "4-20mA" block for a 250k ohm resistor and measured the current just before the resistor and it still 0

250k or 250? And where is "before" the resistor?

My mistake, 250ohms, still no change at all, the votlage on pin2 (suposedly the output for 4-20ma) its constantly 3v

3V corresponds to a current of 12mA and in the comment above you wrote that you measured 0mA...?

So you must be doing sth wrong or didn‘t tell us everything

I think this is the connection you want. Leave out the OUT connection completely and use a 250 ohm resistor (the datasheet says < 0.5 kiloohm).

Ive already tried that conection however the pin 3 (gnd) causes that when my psi its over the overlimit of the sensor in this case 110 psi (maximun capacity of the pressure switch is 200) short circuits and reset

Using a smaller resistor value might help. Note that, as you reach the pressure limit, the voltage across the resistor will reach 250 ohm * 20 mA = 5 V. If the voltage at pin A0 becomes larger than 5 V, this might cause problems with Arduino, including potentially a reset.


text:
Motor does not rotate smoothly ( Even in High speed )
I am bhanuka and i am new to Stepper motors and to this library.
I am trying to control 4 NEMA 17 motors ( Different speeds in same time ) using 4 (four)  DM320t stepper driver. Actually i want to move the robot ( Robot has omni wheels) to coordinates according to the Gcode.
It seem like code is ok, but when i enter a G-code, motors start to rotate to correct direction but they don't give smooth rotation ( I can hear  clicking sound , motor seems jumping from step to step and motor get hot too much ).
I think the problem for this case is motor miss some steps.
here i have attach the code. Can someone help me to overcome this problem.
Thank you.
#include <AccelStepper.h>
#include <math.h>

int Gval;
int Xval, Yval, Zval;
int Fval;
int Ival, Jval;
String Gvalstr, Xvalstr, Yvalstr, Zvalstr, Fvalstr, Ivalstr, Jvalstr;
char Key;
String code; // parameters of G code Translator, It will execute the code
String ab; // Para of G code translator, For come to Gcode function

AccelStepper w1(1, 2, 3); // pin 3 = step, pin 6 = direction
AccelStepper w2(1, 49, 51); // pin 4 = step, pin 7 = direction
AccelStepper w3(1, 5, 6); // pin 3 = step, pin 6 = direction
AccelStepper w4(1, 8, 9); // pin 4 = step, pin 7 = direction

int w1_enb = 4;
int w2_enb = 53;
int w3_enb = 7;
int w4_enb = 10;
char x ; // x cordinate
char y ; // x cordinate
char command; // case vari.
char com;

String inString = "";

void setup() {
  digitalWrite(w1_enb, HIGH);
  digitalWrite(w2_enb, HIGH);
  digitalWrite(w3_enb, HIGH);
  digitalWrite(w4_enb, HIGH);

  Serial.begin(9600);
  Serial.println("G code");

}

void loop() {
  Gvalstr = "";
  Xvalstr = "";
  Yvalstr = "";
  Zvalstr = "";
  Fvalstr = "";
  Ivalstr = "";
  Jvalstr = "";

  String code;
  if (Serial.available() > 0 ) {
    ab = Serial.readString();
    Gcode();
  }
  else {}

}

void Gcode () {
  code = ab;
  Serial.println("code is " + ab);
  //Serial.println(code);
  //String code = "G01 X1 Y1 F200 T01 M03 S500";
  int len = code.length();
  for (int i = 0; i < len; i++) {

    if (code[i] == 'G')Key = 'G';
    else if (code[i] == 'X')Key = 'X';
    else if (code[i] == 'Y')Key = 'Y';
    else if (code[i] == 'Z')Key = 'Z';
    else if (code[i] == 'F')Key = 'F';
    else if (code[i] == 'i')Key = 'i';
    else if (code[i] == 'j')Key = 'j';
    else if (isdigit(code[i]) || code[i] == '-') {
      if (Key == 'G') {
        Gvalstr += code[i];
      }
      else if (Key == 'X') {
        Xvalstr += code[i];
      }
      else if (Key == 'Y') {
        Yvalstr += code[i];
      }
      else if (Key == 'Z') {
        Zvalstr += code[i];
      }
      else if (Key == 'F') {
        Fvalstr += code[i];
      }
      else if (Key == 'i') {
        Ivalstr += code[i];
      }
      else if (Key == 'j') {
        Jvalstr += code[i];
      }

    }
    else
    {
      Key = '-1';
    }

  }

  Gval = Gvalstr.toInt();
  Xval = Xvalstr.toInt();
  Yval = Yvalstr.toInt();
  Fval = Fvalstr.toInt();

  Serial.println( Gval);
  Serial.println (Xval);
  Serial.println (Yval);
  Serial.println (Fval);

  switch (Gval) {

    case 0:
      motor_setup(Xval, Yval);
      //Serial.println("**********");
      break;
    case 1:
      motor_setup(Xval, Yval);
      //Serial.println("**-------");
      break;

    case 2:
      motor_setup(Xval, Yval);
      break;

    case 3:
      motor_setup(Xval, Yval);
      break;

    case 90:
      motor_setup(Xval, Yval);
      break;

    case 91:
      motor_setup(Xval, Yval);
      break;

    case 92:
      motor_setup(Xval, Yval);
      break;

  }
}

void motor_setup (int Xval , int Yval) {

  double Xprojection;
  double Yprojection;

  if (Yval == 0 ) {

    if (Xval > 0) {
      Xprojection = '1';
    }

    else if (Xval == 0) {
      Xprojection = 0;

    }

    else {

      Xprojection = -1;
    }
    Serial.println("Xprojection in if ");
    Serial.println(Xprojection);

    Yprojection = 0;

  }
  else {
    float alpha = Yval / Xval;
    Serial.println("CALCULATING");
    Serial.println(alpha);

    double atanval = atan(alpha);
    Xprojection = cos(atanval);
    Yprojection = sin(atanval);

    Serial.println("X_projection : ");
    Serial.println(Xprojection);

    Serial.println("Y_projection : ");
    Serial.println(Yprojection);
  }

  float W1, W2, W3, W4;  // Radial Velocity required to move to Position

  W1 = float ( -0.35 * Xprojection + 0.35 * Yprojection) ;
  W2 = float (-0.35 * Xprojection - 0.35 * Yprojection );
  W3 = float ( 0.35 * Xprojection - 0.35 * Yprojection );
  W4 = float (0.35 * Xprojection + 0.35 * Yprojection );

  Serial.println ("Velocity components ");
  Serial.println (W1);
  Serial.println (W2);
  Serial.println (W3);
  Serial.println (W4);
  Serial.println('\n');

  long c = 20;    // these values for testing
  long d = 20;
  long e = 20;
  long f = 20;

  w1.setMaxSpeed(2);
  w1.setAcceleration(12);
  w1.moveTo( Xval );

  w2.setMaxSpeed(2);
  w2.setAcceleration(12);
  w2.moveTo( Yval);

  w3.setMaxSpeed(2);
  w3.setAcceleration(12);
  w3.moveTo( -Xval);

  w4.setMaxSpeed(2);
  w4.setAcceleration(12);
  w4.moveTo( -Yval );

  while (w1.distanceToGo() != 0 || w2.distanceToGo() != 0 || w3.distanceToGo() != 0 || w4.distanceToGo() != 0) {
    w1.run();
    w2.run();
    w3.run();
    w4.run();

  }

  Serial.println("Executed");
  Serial.println("Next GCODE");
  Serial.flush();

}

reduce your code to control only one motor ... remove all other code ... run motor for 2 seconds and stop ... update your post with the results

The problem was the Supply Voltage. I have connected it to 24DC V. when i connect it to 12V problem was solved.

It seems that you see too high current at the driver. You should always use minimum current, that smoothly moves your device. Try decreasing the current, it then will work at lower voltages

It's OK to accept you're own answer as the solution to the problem.


text:
How should I connect 5 buttons to arduino so that I can use the least number of inputs all the buttons are connected to ground
The problem here is that I want to connect 5 input buttons to an Arduino but I do not want to utilize 5 input pins of Arduino, is there any matrix like connection using which I can reduce the number of inputs used. The conditions here are:

All the buttons will be connected to ground and initialized using:
pinMode(PIN_NUMBER, INPUT_PULLUP)

Only digital input is required and not analogue

Look at the schematics of almost any keyboard (just Google: "keyboard schematic" and select the images tab). Are any of them using switches that are grounded on one side? There are "matrix" type solutions but your "buttons connected to ground" throws all those solutions out of the window. A one pin solution is possible if you would allow using an analog input and some resistors.

How many can be activated simultaneously? If only one button is active at a time then it's easier.

@Andyaka yes, only one at a time

@Bimpelrekkie what I mean by "buttons connected to ground is" that out of the two terminals of a button (switch) will be connected to the common ground. I don't know if this comment make it simpler or even more complicated.

@ShaktiPhartiyal it did not change anything..

Arrange the buttons with a pulse width modulation circuit such that your digital input can read the pulse width and determine which button that has been pressed.

@Andyaka can you please elaborate / illustrate how and what exactly you mean

@ShaktiPhartiyal  is that "one terminal always connected to ground" an actual restriction or did you add that restriction hoping to make the solution easier? Because without that restriction (and a few diodes), two digital IO pins are totally sufficient, with that restriction, you need an analog input pin, or extensive external logic circuitry, or one pin for every button.

@MarcusMüller I added them, ok what is I remove that restriction ? I still do not want to use an analogue input.

@MarcusMüller I sense XY problem.

@ShaktiPhartiyal you make our and your own life difficult by adding restrictions like the ground connections and no analog input. You will get more suggestions if you leave things as open as you can, so ask: "How to detect which (of 5) button is pressed while using as few pins as possible on my microcontroller." Then you might get some suggestions. Look at the suggestions and see if that suits your needs. If you have restrictions then make clear why they are there, you will need to have a good reason. An "I don't like analog inputs" for example isn't a good reason.

is this a school assignment?

@Shakti  Don't cross-post the same question to multiple stacks.  I'm migrating this copy to Arduino.SE .

@Nick How is this Arduino question more then EE? It is pretty valid for any MCU with limited pins available.

please explain why you don't want to use an analog pin and accepted a solution which allows to read analog value with a digital pin

@Juraj I do not want to use analogue due to possible noise and voltage fluctuations that may arise.

And yet you accepted Andyaka's answer, which requires you to generate an analog voltage to control the PWM chip. Do you have a real concern about noise, or are you just being superstitious? Anything involving switches is going to have to deal with debouncing (a form of noise) anyway.

Only digital input is required and not analogue

I'd consider arranging the switches to produce different voltages depending on which button was pressed and feed the resulting analogue signal level into one of these (the MOD input): -

It doesn't need to run at 1 MHz of course; RSET can be chosen to make it free run at (say) 1 kHz. The resulting duty cycle (set by the switches) can be read under software control via a digital input line.

so this shows how to read analog level with a digital pin and this is the accepted answer. then something is missing in the question. it is a X->Y question and we don't know the X problem and why analog pin can't be used

If all switches have one input grounded, you cannot use matrixing.
In any case, the best you could do would be a 2 * 3 matrix, which uses 5 signals, the same as individual switching (though you may be able to share the strobes with other signals e.g. display strobes)
If you are allowed to use an analog input you can pull the input high with one resistor, and allow each switch to pull it low with a different resistance. Then each switch results in a different analog voltage and you can decipher an ADC reading into a switch input. That way, only one input is required.

Assuming no ground connection: You could totally do this with only 2 GPIO pins (with internal weak pullups), 5 switches, 2 diodes, 2 resistors:  One switch to from one each of pins to a resistor to ground (check by checking input voltage) 2 switches between the GPIOs, differentiated only by the direction of their series diodes and one without a diode (check by putting the other pin to output mode, low output voltage, and see whether that changes the "high" state").

If you do not want to use analog input but not opposed to adding one more component then you can get by with 3 digital pins, two connected to shift register (e.g. SN74HC164) and one reading common return from all buttons. Binary counter can also be used, but with rather high latency.
If you are OK with complicating things even more, you can use external logic for initializing the register, in which case two pins would be sufficient - one for clock output and another for feedback input.
Here is a simple circuit that can be extended to scan any number of buttons by chaining registers or choosing chips with more bits.

Unlike the answers stretching "digital input" function (as implied by OP) to include PWM and Serial communication, this method uses simplest digital I/O: one pin cyclically selects the button, another reads whether it is pressed or not.
The same 2-pin principle (selector output + feedback input) can be used in many different combinations. For example, you can have one side of each switch connected to the ground, as you mentioned in your question. The other sides are fed back to Arduino via analog MUX (e.g. 74HC4051). The MUX address is selected by binary counter (e.g. 74HC193) and the counter is reset by its own QD pin when it reaches 0x08.

If you have only one digital pin available, you might consider the 1-wire bus. For example, the DS2408 provides 8 open-drain GPIO pins.

If you can use an analog input pin, then Brian's answer is correct.
Some simple adjustments of the resistor values create equal-size voltage steps for the A/D converter as shown below.

For the 4-switch case, this gives 5V for no switch pressed, and 0-3.75V in approximately equal steps for a switch press. This approach works well up to 16 switches and beyond.
The general approach for calculating the resistor values is as follows:

Select the pullup resistor value; say, 10K ohms.
Decide how many switches are required: N = 16.
The top switch generates 0 volts by shorting the A/D input to ground.
The next switch down will generate Vcc / N volts:
R = 10k × 1/(N-1) = 666.7 Ω
Select the nearest standard 5% value: 680 ohms
Repeat for switches i = 2 through N - 1:

The next switch down will generate Vcc × i / N volts, but you must subtract out the values of the resistors above it. This helps avoid cumulative errors.
R = 10K × i/(N - i) - 680 Ω - ...
Select the nearest standard 5% value.

For the specific example of 16 switches, you should end up with the following resistor values: 680, 750, 910, 1000, 1200, 1500, 1800, 2200, 2700, 3900, 5600, 7500, 13K, 27K and 82K. Even with 5% resistors, all of the resulting voltages are within 0.25% of full scale of their nominal values.