serial_send_byte available on which ports?


I’m working with a Mini Maestro 12-Channel USB Servo Controller.

I have a script which runs and gathers inputs and sends them periodically using serial_send_byte so that the application running on a Windows PC can read and respond.

The hope is that we could read this from either the USB command or USB TTL port, but the output of serial_send_byte appears to be available ONLY on the TTL pins, and NOT via either of the USB ports: in Windows Device Manager, shown under Ports(COM & LPT) as Pololu Mini Maestro 12-Channel USB Server Controller TTL Port (COM24), or Pololu Mini Maestro-12 USB Servo Controller Command Port (COM23).

On the other hand, if I send a get position command sequence to the Maestro, I DO receive the position in response. I find this to be true regardless of the program I use: Putty, a VBA application, or Pololu Serial Transmitter v1.3.

Is there any mode where output of the serial_send_byte can be received on the USB ports? (without having to send a command first)

The difference is subtle (perhaps) but important to design, as requiring that we send a command first means the PC initiates the communication, whereas the use of serial_send_byte allows the Maestro to send data unsolicited at regular intervals.

Also - I don’t know that there exists a command which allows me to read memory locations, such as the stack location our script uses to keep a running count of pulses from the speed sensor. If not, then commands from USB won’t address this need - while serial_send_byte (again) does quite well.

Thanks for your help,


Hello, Mark.

The serial_send_byte script command only sends bytes on the Maestro’s TX line, it does not send them to USB. However, you might consider putting your Maestro into USB Dual Port or USB Chained mode and then connecting the Maestro’s TX pin to its RX pin. I haven’t tried this, but it should allow the byte sent with serial_send_byte to get sent on the TX pin, received on the RX pin, and then get sent to computer via USB.

There is no serial command for reading a location in the Maestro’s stack, but there are native USB commands for it. You could run “UscCmd --status” on your computer to see the values in the stack or you could write your own code that accesses the native USB interface using the Pololu USB SDK.


Thank you - I’ll give the TX->RX a try.

Re: the dev kit, is there a pdf in it somewhere that documents available resources / API?



Looping back TX-RX in chained mode seems to solve this: I can both send commands (servo) and receive the unsolicited serial output from the script, all via the single USB command port (23 in this case).

I’d like to find documentation of the API/DLL however, as the dev kit would seem to allow some additional functionality that could be useful.

Thank you,


I am glad you are making progress. The Pololu USB SDK does not come with a PDF but you can read the source code, which includes comments.


I needed a way to communicate using only the USB port. After reading this section of the forum, I confirmed that you can place the Magestro in the USB chained mode and receive bytes from SERIAL_SEND_BYTE. However, at the beginning of each message that my script sends, there are ALWAYS two extra bytes (167 and 2). Can anyone clarify what these are and if they can be eliminated?


It sounds like you might be using the serial_send_byte command within a subroutine that you are triggering with the “Restart Script at Subroutine” serial command. When the Maestro’s serial mode is set to “USB Chained”, the command port transmits to the TX pin, so you are probably seeing the two bytes that you sent to trigger the subroutine (0xA7 and the subroutine number in compact protocol), followed by the byte you are trying to send.

One way you might resolve this is to use USB dual port mode, connect the Maestro’s TX pin to its RX pin, send commands to the command port, and listen for responses on the TTL port.

Alternatively, since you know you will always see the command echoed back, you might configure your software to ignore the command bytes.