Serial Communication

[neoncathedral]

Hello, thank you in advance for taking the time to read through this and try to help! I'm trying to connect an Arduino Mega to a ToF Laser Range Finder that communicate via hardware UART (Serial1). The datasheet from the manufacturer is riddled with typos and the test code that they sent me was not functional so this has been quite the struggle since I'm a bit of a noob with serial communication.

I've been attempting to write one_shot_auto and then read from reply_measurement_results. I've been able to isolate the header AA consistently with previous attempts at test programs, but never am able to capture AA 0 0 22 (register location that should be where the data should be placed after performing a measurement.) consistently. If I were able to, then it's simply a matter of grabbing the next few bytes (payload count, payload, signal quality, and check sum).

I will attach the user manual as well as the serial monitor output. Any and all suggestions are massively appreciated, I've been spinning my wheels on this for almost a week now.

The main problem I'm having is purely just getting consistent, synchronized communication between these two devices, to where I can then begin to do data manipulation to separate out the payload count, payload, signal quality, and check sum.
LRF_DataCaptureTHISTIMEFORSURE.ino (2.4 KB)
U81 Laser Distance Sensor USER MANUAL.pdf (3.1 MB)

[ruilviana]

Post your code too.

[neoncathedral]

I did, it's the "LRF_DataCaptureTHISTIMEFORSURE.ino". Thanks in advance for your help

[ruilviana]

Have you read the material on this site?
"https://www.waveshare.com/wiki/TOF_Laser_Range_Sensor

PS;
"https://www.waveshare.com/wiki/TOF_Laser_Range_Sensor#Working_with_Arduino

[alto777]

@neoncathedral

I did,

No, we mean post your code. Here.

a7

[neoncathedral]

I have not, it seems to be pretty different in terms of the underlying structure of the embedded system despite them both using serial communication. I'll give it a read through though, thank you for linking that.

[neoncathedral]

Hello again a7

LRF_DataCaptureTHISTIMEFORSURE.ino (2.4 KB)

LRF_DataCaptureAndProcess.ino (2.2 KB)

These have been my two most recent sketches. If there's anything you notice as a silly mistake, or a misunderstanding of how to go about this process please let me know if you notice anything! Thanks for all your help

[alto777]

Sry, TBC:

Copy the code and paste it here using the <CODE/> tool in the message composition window.

You may want to run the IDE Autoformat tool on it.

You were previously working with a very small sketch, did you get that to function as you intended?

You may need to start thinking about using a serial comms monitoring program so you can watch the two lines and see what is exactly being said by whom and when they do.

It's very easy, conceptually anyway.

a7

[qubits-us]

I'm thinking the same..
open up that .ino, copy it then paste it into the code tags so we can see it here on the forum..

~q

[neoncathedral]

OH, my mistake I misunderstood!
Here's that sketch:

// No need to include SoftwareSerial library, as we will use hardware UART (Serial1)

// COMMANDS FROM DATASHEET
byte auto_baud = 0x55;
byte one_shot_auto[9] = { 0xAA, 0x00, 0x00, 0x20, 0x00, 0x01, 0x00, 0x00, 0x21 };
byte reply_measurement_results[13] = { 0xAA, 0x00, 0x00, 0x22, 0x00, 0x03, 0x00, 0x00, 0x00, 0x00, 0x01, 0x01, 0x00 };
byte laser_on[9] = { 0xAA, 0x00, 0x01, 0xBE, 0x00, 0x01, 0x00, 0x01, 0xC1 };
byte laser_off[9] = { 0xAA, 0x00, 0x01, 0xBE, 0x00, 0x01, 0x00, 0x00, 0xC0 };

// VARs FOR WORKING WITH DATA
unsigned long Data = 0;
byte Read[32];

//==========

void setup() {
  // Establish baud rate
  Serial.begin(115200);
  delay(1000);
  Serial1.begin(115200);
  delay(1000);
}

//==========

void loop() {
  for (int i = 0; i < 2; i++) {
    Serial.println("====================");
    Data = 0;
    delay(500);

    // Send command to start measurement (write to register 0x0020)
    Serial.println("Sending Measurement Command...");
    Serial1.write(one_shot_auto, 9);

    // Wait for a brief moment to allow measurement to complete
    //delay(100);

    // Send read command to retrieve measurement result from register 0x0022
    Serial1.write(reply_measurement_results, 13);

    // Read the response from the laser range finder
    while (Serial1.available() < 13) {
      // Waiting for a complete response
    }
    Serial1.readBytes(Read, 13);

    // Look for the header "AA 0 0 22"
    while (Serial1.available() > 0) {
      byte currentByte = Serial1.read();
      if (currentByte == 0xAA) {
        Read[0] = currentByte;

        // Check for the rest of the header "0 0 22"
        if (Serial1.available() >= 3 && Serial1.read() == 0x00 && Serial1.read() == 0x00 && Serial1.read() == 0x22) {
          Serial.println("Header found. Capturing data...");

          // Capture the following data
          for (int j = 4; j < 13; j++) {
            while (Serial1.available() == 0) {
              // Waiting for more data
            }
            Read[j] = Serial1.read();
          }

          // Display captured data
          Serial.print("Data: ");
          for (int k = 0; k < 9; k++) {
            Serial.print(Read[k + 4], HEX);
            Serial.print(" ");
          }
          Serial.println();

          break;  // Exit the loop after capturing the data
        }
      }
    }

    // Display captured data
    Serial.print("Raw Data: ");
    for (int i = 0; i < 16; i++) {
      Serial.print(Read[i], HEX);
      Serial.print(" ");
    }
    Serial.println();

    delay(1000);
  }
}

Your feedback on my previous sketch helped me reevaluate my approach and got me a lot closer, but still not working. Is there a software you would suggest for doing that?

[alto777]

@neoncathedral

OH, my mistake

THX. Now I can read it here under the umbrella.

I can't give this the attention I'd like, I will try when I am in the lab.

But I do see you using Serial.available() in multiple places a short distance apart from each other in the code

Your earlier approach, I believe, was superior.

Use one test for availability of single characters. Stash or ignore all the characters as they come in. Try to decode a packet once you have 0xAA in Read[0] and 11 (or was it 12 ) more characters.

Doing it your new way, sorta on the fly recognition and reaction, is fraught.

It seems odd to read and throw away three characters, then need to deal with what's happening at Read[4] and up.

I also recommend copious verbosity by way of Serial.print(). It was key to my progress with the other issues.

Anyway, I would work on that before getting out the side issue of serious monitoring, but the short version is…

You can use a terminal emulator program like PuTTY or CoolTerm, and use just the RX inputs on two open windows, which RX inputs can be attached one to the TX->RX line and the other to the RX<-TX line.

Just a window each for listening what's going to your device, and what's coming back.

Obvsly you have to be in the same standard, so this works if everyone is RS-232 or if everyone is TTL serial.

It works because listening will work on both lines and will not have any effect on the traffic.

Like I say, concept easy, practice enough of a headache that we do simpler things first.

a7

[alto777]

It also should be said that CoolTerm at least, and I would be surprised if not also PuTTY, can be configured to send an arbitrary string of characters.

So you can write and send a perfect stream.

This is not what I did on the other thread, but could have.

You can get your code working with this tricked simulation of the packets, just based on the documentation.

Then real life should follow the same process and work. If it does not, you have a different place to look than your own code.

A hardware matter: Loose or incorrect or dodgy wiring. Noise and electrical issues. You seem to be getting the characters sometimes, that rules out a bunch of hardware/protocol issues.

A software matter. The document you are working from is not accurate or is incomplete. Not the first time that happens.

HTH

a7

[neoncathedral]

okay, thank you for looking at my sketches again, greatly appreciated. I'll probably circle back to my initial approach as you suggested, and try to simplify the process as much as possible and then utilize one of the pieces of software that you suggested to try to make some headway.