USBH_SerialUSB class isn't working

to communicate with a device, I am using USB - serial-communication. On my Windows7 PC this code is working fine:

            var Port = new SerialPort("com5", 38400, Parity.None, 8, StopBits.One);
            Port.ReceivedBytesThreshold = 1;
            Port.DataReceived += new SerialDataReceivedEventHandler(Port_DataReceived);

I tried to do the same with my gadgetgeer’s usb-host module with this code:

static void DeviceConnectedEvent(USBH_Device device)

            Debug.Print("Device connected");
            //Debug.Print((device.TYPE == USBH_DeviceType.Serial_FTDI).ToString());
            usb = new USBH_SerialUSB(device, 38400, System.IO.Ports.Parity.None, 8, System.IO.Ports.StopBits.One);
            new Thread(new ThreadStart(Listener)).Start();

public static void WriteMessage(String message)
            byte[] bytes = StringToByteArray(message);
            usb.Write(bytes, 0, bytes.Length);

The Code is executed without errors, however I get no response and reaction from my device. What could be the problem? :o

Your code is incomplete. The StringToByteArray function has not been included.

have you used the debugger to see if the data was actually sent?

The Gadgeteer library does not support a USB to serial cable as a USB host module device, so you should not be using the Gadgeteer designer. You should do all of your API work directly to the GHI USB Host library.

Check out GHI Electronics – Where Hardware Meets Software

Normally, the UTF8Encoding class is used to convert from a string to a byte array

From the Gadgeteer source code:

/// This module enables you to use a USB Drive as a storage device, or to use a USB mouse as a pointing device. 
/// Although you can plug other types of USB devices into the USB host module, the Microsoft .NET Gadgeteer software 
/// only responds to these two device types. Other types of USB devices will not raise the events associated with this module.

OK, now I made a simple Console application:

public class Program
        static USBH_SerialUSB usb;
        public static void Main()

            // Subscribe to USBH event.
            USBHostController.DeviceConnectedEvent += new USBH_DeviceConnectionEventHandler(USBHostController_DeviceConnectedEvent);

        static void USBHostController_DeviceConnectedEvent(USBH_Device device)
            //USBH_Device silabs = new USBH_Device(device.ID, device.INTERFACE_INDEX, USBH_DeviceType.Serial_SiLabs, device.VENDOR_ID, device.PRODUCT_ID, device.PORT_NUMBER);
            //usb = new USBH_SerialUSB(silabs, 9600, System.IO.Ports.Parity.None, 8, System.IO.Ports.StopBits.One);

            usb = new USBH_SerialUSB(device, 9600, System.IO.Ports.Parity.None, 8, System.IO.Ports.StopBits.One);
        public static void WriteMessage(String message)
            byte[] bytes = StringToByteArray(message);
            usb.Write(bytes, 0, bytes.Length);
        #region Conversions
        private static byte[] StringToByteArray(string str)
            System.Text.UTF8Encoding enc = new System.Text.UTF8Encoding();
            return enc.GetBytes(str);

        private static string ByteArrayToString(byte[] data)
            return new string(System.Text.Encoding.UTF8.GetChars(data));


But still the same result :frowning:

Are you getting the DeviceConnected event?

Have you tried running the example in the USB_Serial class documentation?

Yes I am getting the DeviceConnected event, the whole code is executed, but I won’ get a response or reaction from my device…
The same thing with example code, it is even sending Hello World, but as well no reaction…

Please try running the USB discovery helper and confirm what is reported back.

[quote][Device, Port 0]
Type: Serial_FTDI
ProductID: 24577
VendorID: 1027
=== Interface ===
Class: Vendor Specific
SubClass: 255
Number: 0
Protocol: 255
Type: 4
– Endpoint –
Attributes: 2
Address: 129
Type: 5
Interval: 0

– Endpoint –
Attributes: 2
Address: 2
Type: 5
Interval: 0

FYI: It’s the RP6 robot from Arexx RP6 ROBOT SYSTEM

The type of Serial_FTDI looks right; there was an issue with SILabs devices but that doesn’t apply to your cable. shows a good example of some things you should do (like verify your newly connected device is a serial_FTDI before you assume it is)

In my view this is a connection issue. So let me clarify, you have a Fez that is connected via USB Host to the FTDI cable. That cable goes to a ? robot? Where does your PC software come into the picture?

Simplest test I can devise for you is connecting your serial connection to the PC and use Tera Term to see what is sent. Because I don’t know what connections your device(s) have, I can’t suggest how you confirm that. To me though the data not getting through means the wires are not connected in a meaningful way. Help explain that more (pictures do help too) and we might be able to show you other issues.

I made a picture of all the components, I hope this could clarify it a bit more. So the robot is programmed via an USB-Interface. When I connect this interface to my PC I the serial communication is working fine. But when I connect it to the USB-host-module it doesn’t.

How can I use TeraTerm?

ok, so let me now confirm. When you’re testing, you’re only testing Fez connected to your Bot, not to your PC. That now makes more sense.

What I was suggesting was that you should basically connect the cable directly to the PC and Fez, and confirm that it works. To do that you would need another USB to serial (TTL) cable so that you could take the TX/RX/Gnd wires on the flat ribbon side of your serial board for your Bot, and have them go to your PC.

Give me a little while, I’ll draw up a code change that I think will help. Do you have a button module?

Simpler than rewriting, here’s what I would do now.

Change the USB host DeviceConnected to NOT write out your command.

Add a ButtonPressed handler and when it is pressed, then write out the command on the USB port.

Make sure your button code works by adding a break point in there and step through. You should make sure you try sending commands multiple times, pressing the button a lot. It’s possible that the FTDI chip is buffering characters, so send it a lot and see what happens.

Can you please confirm if the Bot is ever meant to reply to commands? Do you know if it’s meant to be carriage return delimited? Try adding \r\n to your string and see if that helps?

I tried the button thing and sended a lot but it didn’t help.
Adding “\r\n” didn’t help as well. The bot should boot if he gets the start command, and he does if I send it from the pc. And when he boots he replies to commands…

Hm I just have no idea why it doesn’t work…

Could it there be a problem or bug within the USBH_SerialUSB class?

Maybe, but that is not likely. Very unlikely I would have thought. I don’t have personal experience but I am sure that this would have come up before if there was an issue. This seems very much as though this is a code or wiring issue. The only way to know is to know what data is coming through the wire. Do you have a standard serial port on your PC? Any other USB/serial cables? We might be stuck if you don’t have anything else to help diagnose this…

Well, which cable exactly do you mean? The usb cable, and the connector cable from usb-interface to robot are ok, because they everything works fine if I connect the usb cable from the interface to my computer. the Usb-host module and cable are also working because i’ve already managed to communicate with android devices via this usb host.
So I don’t think that there is cable issue…

Maybe I found the problem.
I did some research and I found out that I have to set the RTS-pin properly!
On regular C# on my Computer I can set it like this

SerialPort Port = new SerialPort("com5", 38400, Parity.None, 8, StopBits.One);
            Port.RtsEnable = true;

How can I set this with Gadgetgeer - code?

I am afraid our FTDI drivers do not support that.

Could you add this feature to your FTDI driver? Honestly I don’t know how much work this would be, but to me it doesn’t sound to difficult?!

Please Please Please :smiley:

Actually it is at least 2 days of work which costs the company a lot of money. But no worries, I have already forwarded this to the right people to look into it.

Ok thank you! This is great support!

RTS, right, that might explain it - do you need it? Perhaps you could set the FTDI chip to not rely on it and simply pass this through. There’s another thread that talked about reconfiguring one but I’m not sure if it could deal with this situation.