Xtend seems slower in API than transparent mode

XBee & XBee Gateway XTend
, ,
1

When downloading a file (about 400k) from a device connected in transparent mode to a RS-232 XTEND modem configured at 115200, I noticed that it is significantly faster (about 40s or 10kB/s) in transparent mode than in API (about 75s or 5.3kB/s). Is this expected or is there something I’m missing?

I increased the speed of the receiving interface (ATBD) to 230400 to make sure it was not the verbosity of the API mode that was causing a buffer override - no change.

The snippet of code I used to compare both methods is provided below. The only things that change are the master modem configuration (ATAP0 or ATAP1) and the way the request for file download is composed and transmitted to the slave. Characters reception remains the same in both cases.

Model: XT09
Firmware version: 2067

Thanks,

Dave


int main()
{
  int i;
  char c;

  // Open connection with modem
  int m_fd = open("/dev/ttyS4", O_RDWR | O_NOCTTY);
  if(m_fd == -1)
  {
    throw std::system_error(errno, std::system_category());
  }

  // Configure io
  struct termios newtio;
  bzero(&newtio, sizeof(newtio));
  newtio.c_cflag = B230400 | CS8 | CLOCAL | CREAD; // Interface set to 230k 8-N-1
  newtio.c_iflag = IGNPAR;
  newtio.c_oflag = 0;
  newtio.c_lflag = 0;
  newtio.c_cc[VTIME]    = 10;   /* timeout of 1s*/
  newtio.c_cc[VMIN]     = 0;   
  tcflush(m_fd, TCIFLUSH);
  tcsetattr(m_fd, TCSANOW,&newtio);

  // SCPI string sent to client.  This forces the download of the log file
  string str = "mmem:data? system1.log
";

  // Construct API packet
  TxPacket pack(1, 9, true);
  pack.addData(str);

  // Transmit packet (AP=1)
  /*for(unsigned int i=0; i!=pack.size(); i++)
  {
    c = pack.getByte(i);
    write(m_fd, &c, 1);
  }*/

  // Transmit string (AP=0)
  for(unsigned int i=0; i!=str.size(); i++)
  {
    c = str[i];
    write(m_fd, &c, 1);
  }

  // Read all characters and print only text ones.
  int n = read(m_fd, &c, 1);
  while(n>0)
  {
    if(c=='
' || c=='\r' || c=='	' || (c>=32 && c < 128)) cout << c;

    // Read next character
    n = read(m_fd, &c, 1);
  }


  close(m_fd);
}
2

Hi Dave,

How big is the data in each transmit request? It looks like they can be a max size of 2k. Assuming you are doing that, the overhead of processing an API frame shouldn’t be too bad.

If not, then your reported results don’t surprise me. While I can’t provide hard numbers it does make sense. API mode is going to involve more steps to send data. The module has to translate the API frame and then can transmit. transparent mode

3

Thanks kjensen8. Packet size (ATPK) at the transmitter is set to 512 bytes. I did a check with another piece of code and packets come in at 521 bytes in API which make sense because there is 512 bytes of data + 9 bytes overhead(delimiter (1), size(2), api id(1), address(2), rssi(1), opt(1) and checksum(1)).

>> API mode is going to involve more steps to send data
This surprises me actually. I assumed the unit always transmitted packets this way over RF, thus, not having to convert them into clear text at the receiving end should have been faster. This is assuming the interface is fast enough to take the data out, which is why I switched to 230400 on the receiving end.

Just to clarify - the transmitter is always in transparent mode and responds to the “mmem:dat…” command by pushing the 400k file at the limit of the serial interface using hardware hanshaking.