I am not sure if there is a more appropriate place to post his so my apologies in advance if this is not the correct place...

I am using a Teensy board which is an arduino variant and has the capability to communicate with a PC's USB COM port once a sketch is running but I am having some problems sending commands to it from my PC.

On the Teensy board and using the Arduino IDE, there is a set up in the tools drop down for the COM port serial monitor which I am using to view the serial data.

I can send an r, s, g, or h from the COM 3 Serial monitor which sets my leds on and off as they should per the code but the next step is to get the PC to communicate these characters to it...

I made a winbatch script that I am using to send these characters out to the Com port 3 and I have these logged in a log file and they appear to be sent to the serial port without a problem but the teensy board is not seeing these nor is the Com3 serial monitor.

Why can't the arduino pick up on this data sent to it with the winbatch script?

Is there any other way to test this such as sending a character to the com port from the command line prompt?

After much investigation, it turned out Winbatch has a bug where it erroneously sends the break signal when opening any serial port.

Teensy uses the break signal as its command to reboot, so every time Winbatch tried to open the port, Teensy would reboot. Because it's native on-chip USB instead of a USB-serial converter, the port would disappear right as Winbatch was opening it. The Arduino serial monitor and other terminal emulators would work fine.

On a normal Arduino, DTR from the USB-serial chip reboots the processor. That obviously isn't an option for Teensy since rebooting means also rebooting the USB stack, so the break signal was used instead.

It also turns out the Mac OS-X USB serial driver has a bug where it can't send the break signal. You can call tcsendbreak() and OS-X returns a success status code, but nothing is actually transmitted. So to make OS-X work, reboot upon setting the baud rate to 134 bits/sec was implemented.

In the latest "experimental" 0.9 Teensyduino code, I have switched Windows and Linux support to use 134 baud setting instead of the break signal, and the reset-on-break behavior has been removed.

This should allow Teensy to work with Winbatch, or any other programs that unexpectedly sends the break signal. Just don't set the baud rate to 134. On Teensy, the data transfer is always native 12 Mbit/sec with native flow control, no matter what the baud rate setting in software.