Problem SerialUSB.Read

I am porting my Domotica windows service application from a net book to the Cobra.
Until now I succeeded to overcome the big thinking into them small thinking for NETMF. So I have a X10 power line I/F, tcp/ip webcam support taking pictures in case of alarm from a door sensor or PIR sensor, control of lights, heating, curtains, sun screens, a c# alike scripting parser and a scheduler and mail service. The Cobra is a tcp server and I have a windows client for configuration and remote control. So far so good but for the RF 434 communication, receiving Oregon weather sensors, X10 RF… I have an USB RFXCOM receiver. Inside the receiver is an FTDI USB chip and this is recognized by the FEZ.

For reading I start a Thread with HandleUSBComm. The RFXCOM is sending blocks of binary data and the first byte is the length. No protocol.
When I do this on my Domino it works fine but on the Cobra I am missing data starting with eg 220240 hex and I start receiving package of 8 bytes with 3810 3820 coming from no ware ( fyi start with 60 and 50 is an Oregon weather station)

605A6D008B34216045A3C15ECB
605A6D008B34216045A3C15ECB
3810000000000000
501A2D1060312210662CEE
501A2D1060312210662CEE
3820000000000000
3800010000000000
3808000000000000
3802000000000000
3800080000000000
3802000000000000
3808000000000000
3802000000000000
3800020000000000
38FE000000000000
38007E0000000000
3800010000000000
3820000000000000
38007E0000000000
3840000000000000
501A2D1060312220662DD1

First thought was it is recognizes 2202 as an escape sequence or something but why?
Does anyone have an idea?


        private void HandleUSBComm()
        {
            try
            {
                // Event for receiving data
                int erc = 0;
                int bytesRead = 0;
                byte[] buffer = new byte[256];
                while (true)
                {
                    bytesRead = m_SerialUSB.Read(buffer, 0, 256);



                    if (bytesRead == 0)
                    {
                        Thread.Sleep(500);
                    }
                    else
                    {
                        Debug.Print(buffer.ByteToHex(bytesRead));

                        for (int i = 0; i < bytesRead; i++)
                        {
                            erc = ProcessReceivedChar(buffer[i]);
                        }
                        // Checksum error or conversion error
                        //if (erc == 2 || erc == 3)
                        //{
                        //    // Clear buffer
                        //    break;
                        //}
                    }
                }
            }
            catch (Exception ex)
            {
                TraceLog.WriteLine(m_Tag, ex);
                DisconnectUSB();
            }
        }

Have you tried a simple program which just reads the data from the RFXCOM? This would help in isolating the problem.

Hello Mike,

Yes, just did removed everything but same problem.

In the meanwhile I found that when I set the readtimeout to -1 the data with 3800 … disapears OK.
Maybe problem in the USB Host driver?

But still not receiving data starting with 22 hex

Wow Aurelia,

looks like you are at a very nice step in your domotica application. I’m building one myself too. Would you be interested in joining forces or sharing some code? You can contact me by email: eric at vdbnet dot net

Regarding your serial issue, at what baudrate are you having issues? I had also issues when using the max 115200 speed. Reducing that to 57600 solved my issue on the cobra.

Hello Eric,

Yes I will contact you for codeshare…

About baudrate only 4800 parity none stopbits one.

And I am using the latest firmware on Cobra and Domino in case somebody will ask.

(ps Nice new update tool from GHI !)

Have you tried to loopback (TX->RX) the USB to serial adapter and write a small program to send and receive data?

What have you attached to the Cobra? If you are using an LCD, and powering via USB, are you attached to a powered USB hub? The LCD takes a bit of power, and with other things attached, you might have a power issue if you are not using a powered USB hub or external power source.

Thanks Mike,

Good Idea only the connection is inside the device but I also have a FTDI usb serial cable so I will check connecting TX RX tomorrow to eliminate a driver problem.

I have the LCD not connected, the RFXcom gets its power from te Cobra but when I measure the Voltage it is not dropping down and there are only the FTDI chip and a pic controller inside.

Update: connected USB-Serial cable with RXTX loopback.
Zend data also starting with hex 22 no problem.

Opened RFXCom receiver removed receiver part created RXTX loopback no problem.

Added the receiver print and the problem is back again.
I will try to connect a oscilloscoop next week maybe the data is a bit noisy.

Let you know the result.

You should also try connecting the receiver to a PC with the USB cable to see if the problem appears.

Hi Mike, The receiver is connected to my PC for 2 year now without problem.
And also connected to the Domino is without problem. Two weeks ago I wrote a small programm to use the Domino as usb-tcp converter and connected the Cobra with tcp to the Domino.
But this is plan B in case A fails :wink:

Update: Inside the RFXCom receiver is a Pic controller with serial output and a FTDI serial USB chip.
I created a small test program displaying the received data from a serial port and the USBSerial port on my Cobra and connected the RFXCom receiver with USB and serial direct on the Pic… Now I am receiving the data from the Pic twice but with wrong data in between. When I only start serial receiving it works perfect but as soon as I start USBSerial.Read the problem begins after a read timeout. Connected a scope to the RX TX signals this shows nice clean shapes. I have the feeling it is some mismatch between the 2 USB devices. But since the serial is working fine I will but the Pic controller board from RFXCom on my Cobra extension board and connect it with a serial port. For me the subject is closed.

Thanks for the help from Mike!