I'm writing an application for WinCE 5 which need to send/receive data from the COM port. Currently, I've got an USB to serial COM port hooked up to my PC and am using the PocketPC 2003 emulator. I'm using the 'line monitor' that came with my USB<->Serial converter to monitor what is going over the line.

It seems for whatever reason, the PocketPC emulator device only sends 1 character at a time, where as Windows will send a while line. The device I'm sending to, a [url=http://www.weedtech.com]Weeder Tech board[/url], requires the full sequence of text to be sent all at once.

Any idea why the WinCE device is only sending one character at a time?

Sample code to demonstrate the problem:

                OpenNETCF.IO.Serial.Port oSerial;
                oSerial = new OpenNETCF.IO.Serial.Port( "COM5" );

                oSerial.Settings.BaudRate = OpenNETCF.IO.Serial.BaudRates.CBR_9600;
                oSerial.Settings.ByteSize = 8;
                oSerial.Settings.Parity = OpenNETCF.IO.Serial.Parity.none;
                oSerial.Settings.StopBits = OpenNETCF.IO.Serial.StopBits.one;
                oSerial.Open();
                byte[] data = System.Text.ASCIIEncoding.Default.GetBytes( "ACA\n" );
                oSerial.Output = data;
                Thread.Sleep( 1000 * 2 );
                data = System.Text.ASCIIEncoding.Default.GetBytes( "AOA\n" );
                oSerial.Output = data;
                oSerial.Close();

Windows XP line output:
[img]http://home.comcast.net/~bsod2600/winxp_com5.png[/img]

WinCE 5 line output:
[img]http://home.comcast.net/~bsod2600/wince_com5.png[/img]

Figured out why it wasn't working!

It's all about the newline character. I was sending a LF after every command (.NET default), while the board was expecting a CR. Once I realized that and did some more testing, it worked properly. So apparently it didn't really need all the commands sent in one line like I had originally though. The device just expects a "command" to be terminated with a CR. So much of a headache over a small thing!

I spoke too soon about my problems being resolved. Now since I can actually send/receive data from the device, I've got a problem receiving data. Got more sample code which works fine in XP, yet on CE the device is getting confused and throwing back error codes saying it didn't understand what it got.

I've tried running DiscardInBuffer() and DiscardOutBuffer() before sending my next command, yet the device still comes back saying it didn't a understand AND then the data I'm after. Sample code:

static public Int32 TemperatureFahrenheit()
{
    String data;
    Int32 temp = 32;

    try
    {
        Thread.Sleep( SLEEPTIME );
        _port.DiscardInBuffer();
        _port.DiscardOutBuffer();
        _port.WriteLine( THERM_HEADER + "R" + THERM_A_CHN );
        data = Read();

        if ( data.Length > 0 )
            data = data.Replace( THERM_HEADER.ToString(), "" );    //Strip off returned header

        temp = Int32.Parse( data );
    }
    catch (Exception ex)
    {
        Log.Add( ex.Message );
    }

    return temp;
}

The Weedtech board uses simple ASCII commands to get/send data. Here is its [url=http://www.weedtech.com/wttci-m.pdf]data sheet[/url]. Anyways, to read a thermocouple you issue a string containing the device's header, R (to READ) and then the channel (i.e. ERA).

Using the code from above, gives the following output below. Notice the A? is the first thing returned, which means the device didn't understand something on the A header. Yet, I never issued any command to it! The thermocouple board obviously got the proper command, because next is E85, the data I'm after.

Only way I think it could've gotten a command to the A header is that part of the previous command (ERA) contained an A and somehow the buffers chopped it up sending? But how could that happen since I cleared both in/out buffers before sending my command. Reading through the [url=http://www.weedtech.com/an200.pdf]Host Programming Guidelines[/url], I see each data character cannot have more than 833uS between each. I'm thinking maybe the WinCE emulator is violating this.

[img]http://home.comcast.net/~bsod2600/wttci_1.png[/img]