Lower 7bits = 0x0A

I am trying to control servo with pololu maestro and serial communication from linux. When I try to set target which lower 7 bits is 0x0A the servo moves to Maestro lower limit (which I set in windows). It does not make difference what the higher 7 bits are, only lower 7bits = 0x0A cause this behavior.
This behavior is completely weird because it works OK on my laptop with the same OS (OpenSuse 11.2). When I tried to upgrade the firmaware to v1.01 my maestro died (not recognized as USB device anymore) - but I had two of them so my pain can continue. And Pololu do not return any error. Also when setting the value from Control Center in Windows it is OK. I can probably fix it by avoiding such values but that is insane …

This is small piece of code that cause that described above, the 0x31 value can be replaced for anything else - it will still goes to the limit on my desktop.

#include <fcntl.h>
#include <stdlib.h>
#include <stdio.h>
#include <termios.h>

int main()
  int fd = open("/dev/ttyACM0", O_RDWR | O_NOCTTY);
  char message[] = {0x84,0x00,0x0A,0x31};
  //char message[] = {0x84,0x00,0xB,0x31};
  //char message[] = {0x84,0x00,0xb,0x31};
  unsigned char buf[2];
  struct termios options;

  tcgetattr(fd, &options);
  options.c_lflag &= ~(ECHO | ECHONL | ICANON | ISIG | IEXTEN);
  tcsetattr(fd, TCSANOW, &options);



If anyone have some idea of what could be the problem, that would be highly appreciated.



On some computers, when you open a serial port and send a Newline (0x0A), the default behavior is to convert that byte in to something else, such as Newline+Carriage Return (0x0A, 0x0D). This results in an incorrect series of bytes being sent to the Maestro.

Based on what I read about the termios struct, I think you can turn off this behavior by clearing the ONLCR and OCRNL bits in the c_oflag field. So try adding this to your program:

options.c_oflag &= ~(ONLCR | OCRNL);

Let us know if that works for you!


Thanks David,

with your magic line it works as expected!