Serial Buffer very laggy! Can you explain why?

Hello all,

I am using APM 2.5 with the 3DR radios. I am running the system at 100Hz with a BAUD rate of 57.6kbps
When I send messages from quad to a ground station PC I am able to attain almost flawless communication (only drawback about 100ms lag). However, when I send messages to the quad is when I encounter problems. Through various experiments (which I can detail if anyone is interested) I have already confirmed that the radios can handle the data rates I impose. But when I access the serial buffer by issuing the command serial.available() I noticed that the data doesn't show up in consistency with what I expect. More clearly, we send 11bytes packets every 10ms, but the bytes available on the serial buffer on the APM looks something like this (an abstraction): 
bytesAvail: 11 0 22 0 0 33 8 14 11 ...

here bytesAvail are the bytes available on the serial buffer each time the main loop runs; btw whenever there are bytes available I read them off the buffer. As you can see no information is actually lost but the data doesn't show up when expected. For example from time index 4 to 6 I sent 3 messages each sample time and I only received them all lumped up at time index 6. 

Where do you think this lumped buffering is happening. I looked at SoftwareSerial.cpp .h and at UARTDriver.cpp .h but I didn't see any unneeded buffering. Could this be hardware. If so would it be on the radio side or on the APM side? Can this be fixed?

You need to be a member of diydrones to add comments!

Join diydrones

Email me when people reply –

Replies

  • Hi,

    You do know the radios break the byte stream into frames and can send only whole frames, right? The 3DR radios can be set to look at or not look at the MAVLink message boundaries when doing this, in order to avoid splitting MAVLink messages over several frames (wasting one if the other is lost etc). It probably may well put multiple messages into a single frame.

    If you replace the radios by a serial cable (but, for experiment's sake, not the USB one), what happens then?

    Regards

    Soren

    • Hi Soren,

      thank you for posting.

      Using 3DRRadioConfig v1.0 I deselected the Mavlink checkbox when I configured the radios. By the way I just tried it with it selected and still no go. You say the radios break down the byte stream in whole frames. What is the size of this frame? Can I custom create a frame of my own? How?  Right now, on the ground-station side, I have a PC building 11byte messages (2header bytes + 8bytes actual message + checkSum). I then dump this message every 10ms on the COM port where the radio is connected. I know that there is no issue with the software on the PC because I connected two computers together using the 3DR radios and I get impecable communication (i.e. no unnecessary buffering). Also the software comes from a very reputable company and has been proven to be very reliable (Quanser/QUARC).

      I don't have a pure serial cable on hand but using the USB cable that we use to flash the APM, I also observe perfect data transmission. Meaning, I see 11 bytes available every cycle.

      Below is a fragment of code similar to what I am using to see how many bytes I have available each cycle through the main loop running at 100Hz. This is simplified a lot and showing only the basics operations.

      Many thanks,

      Remus

      \[code]

      static unsigned char buffer[256]={0};
      int number_of_new_bytes = 0;
      int bytesAvail = hal.uartA->available();
      number_of_new_bytes = bytesAvail;
      if (bytesAvail > 0)
      {
       int i=0;
       while(bytesAvail > 0){
         buffer[i] = hal.uartA->read();
         bytesAvail--;
         i++;
       }
      }
      hal.uartA->write(number_of_new_bytes);
      \[code[
This reply was deleted.

Activity