3pi-serial-slave controlled by Processing through FTDI

I’m having trouble debugging what this. The problem is that when I send the signature command I get the signature back, but also get a “Bad cmd: FF” on the 3pi. The commands to set the motors work without error.

To connect to the 3pi via pd0 and pd1 I am using the USB Bub from moderndevice.com. I have connected tx, rx, and gnd.

The first sample is the Processing code to control the 3pi serial slave (used the example program without modification).

The second sample is Arduino code loaded on an Ardweeny. This works fine. I just want to show that it seems like the code should work.

SAMPLE ONE: Processing code (fails on signature)

import processing.serial.*;

// The serial port:
Serial myPort;       

void setup() {
  myPort = new Serial(this, Serial.list()[0], 115200);

void draw() { 
  delay(200);  // for possible initialization delay

  myPort.write(0x81); // request_signature();

  myPort.write(0xC1); myPort.write(20); // request_m1_forward();

  myPort.write(0xC1); myPort.write(0); // request_m1_stop();

SAMPLE TWO: Ardweeny Code (works)

void setup()

void loop() {
  Serial.write(0x81); // request_signature();

  Serial.write(0xC1);  Serial.write(20); // request_m1_forward();

  Serial.write(0xC1); Serial.write(1);  // request_m1_stop();




Are you running the BUB at 5V or 3.3V?

Can you add a delay before the signature command so that you can check whether the bad command was caused by that or caused by some kind of port initialization?

If you want further help, please simplify your code as much as possible (down to just a few lines that demonstrate the problem) and use the Code button to format it nicely - otherwise it is really hard for us to figure it out.


Paul, thanks for your reply. I’ve changed the code in my original post per your suggestion.

I am running the BUB in 5V. Blurb from the instructions below.

The delay did not work and I continue to get the same command error (with beap) on the 3pi every time the signature is requested from the PC through the BUB via Processing. Works fine if I run the Ardweeny directly connected PD0 -> PD1 and PD1 -> PD0


Are you sure you are at 5V? Can you test it?

I do not know anything about this board, but the product page says:

Also, I am skeptical about how you added such a short (200ms) delay to the beginning of the loop, without any indicator that the loop is beginning. How can you tell that request_signature is causing the error rather than something before the start of the loop? If you comment out the request signature line, does the error go away? Can you disconnect the TX line of the 3pi to make sure that the response to the request signature command is not causing the program?

The easiest way to figure out what is going on here would be to check the actual signals on an oscilloscope. Since you have both working and non-working devices supposedly sending exactly the same byte (0x81), you should be able to compare them and see exactly what is different. Do you have access to a scope somewhere? If you bought the 3pi with Pololu USB Programmer, you could even use the built-in SLO-Scope feature, though you would have to slow down the baud rate quite a bit to see it well.


Paul, thanks so much for your knowledge. It works great when I use a 5V logic level on the BUB. I used the Slo-SCOPE and determined that the default logic level of the BUB is 3.3V. I had to add a header onto the BUB which allows me to jumper between 3.3V and 5V logic level.

Can you tell me how to determine the appropriate logic level of a UART for a processor? I looked throughout the AVR 328P data sheet (full 500+ pages) and could not find anything specific to the UART TX/RX.

Thanks again!

Great, I am glad that it works for you!

The parameter you need is the minimum voltage guaranteed to read high for an input pin, which is given on page 316 of the mega328p datasheet, in Section 28.2 - DC Characteristics. I think you want the one called “Input High Voltage, except XTAL1 and RESET pins”, which has a minimum specified as 0.6Vcc when operating at 5V. That evaluates to 3.0V. That sounds good, since it is under 3.3V, but keep in mind that the 5V regulator on the 3pi and the 3.3V regulator on the FTDI chip might both be slightly off, the output voltage on the FTDI’s I/O is going to be a little below its Vcc, and any kind of noise could easily push you under that threshold, especially at a high baud rate. So I am not surprised that you had trouble!