PDA (Pocket PC) Serial Read ERROR

[Controlink_Systems]

I have developed some routines for the PDA to read and write ASCII text files over the serial port. I am communicating with different pieces of equipment with various COM parameters (baud rates, data bits, stop bits, parity, etc.)

Everything is working fine except my PDA can not correctly read the serial port (receive a file) when the parity is set to even (I have validated this using a varity of different communication parameters - everything works great until the parity is set to even regardless of baud rate and/or other settings). The PDA can correctly send a file using even parity but it can not recieve one.

The Number of Bytes at serial port seems to be correctly reported and no errors are generated when trying to read
the bytes. However, when parity is even, the retrieved buffer is usually empty or very small. If I change the parity to none (as an example), and modify the equipment's settings as well, the file will be correctly received.

I have used two seperate computers to act as sending units (I can completely control the COM paraters with them) and all works great until setting parity to even. The parameters that I would like to use, because the field equipment uses them by default, are (4800,7,2,even).

I am using an IPAQ Pocket PC (Model 4150). I suspect something is wrong with the way the bytes are being converted as a function of parity within the serial read VIs. However, I need someone to validate this concern.

FYI: I have attached a serial read test program for the Pocke PC. Press [READ], it will init the port and read/display text until [Stop Read] is pressed. You can change COM paramters and tap [READ] to try varied settings.

TIA,

Guy

[ScottieB]

Hello Guy,

I believe that you initiated a phone support request for this same issue; I will be working with the other engineer on this issue as well.

This should not happen, and it seems as though you've tested it thoroughly. I will try to reproduce your issue here with another PocketPC to see if this is something specific to your model or not.

Can you perform a loopback test on the PocketPC with even parity, or does that fail as well? Set it up for no flow control and short pins 2-3 on the serial port. Let me or your phone support engineer know the results of this test.

Scott B.
Applications Engineer
National Instruments

[Controlink_Systems]

Hello Scott,

I created a simple loop back test using 4800,7,e,2 and it worked perfectly. The test VI wrote a message onto the port, waited 2 seconds, requested the number of bytes on the port and then read that number of bytes from the port. It worked as expected...

I then further investigated my problem and found that in every case, when even parity is used regardless of baud rate, only the first character of the sent file is retrieved. The correct number of bytes shows up but when requested, only 1 character is returned (for even parity only).

I then used hyperterminal (4800,7,e,2) and noticed that every character I typed from my computer was correctly displayed on the PDA. Based on this finding, coupled with the fact that only the first character is correctly displayed, I used a character delay and found that if when sending the file to the PDA I pause 25 msecs between each character (a character delay) that the entire file could be correctly received by the PDA at even parity. The character delay method begins to simulate typed characters since a delay exits between each character.

Additionally, going back to the loop test, once the bytes are written to the buffer it is no longer active (data is not being written to it during the read). I tried to simulate this by initializing the PDA port and letting it set idle, I then sent over a file (112 bytes) from another computer, then I tapped read on the PDA, it found the 112 bytes and then tried to read them. This should simulate the loop test, unfortunately, only the first byte is returned although the correct number of bytes was found and requested.

So, in conclusion, I can correctly read a file sent at 4800,7,e,2 as long as during the transmission, a delay of about 25 msecs is created between writing each character. Additionally, the PDA can correctly recieve a file duing a loop-back test. Also, I receive the same incorrect behavior using the PDA Serial Example VI. It finds the right number of bytes but when that number is requested, only 1 character is returned?

I am not sure what all of this means but I wanted to pass along my findings. It appears that the problem may be with my PDA but it is still very difficult to know for sure. I am hoping that you could somehow validate correct behavior at NI using a method different from the loop test.

Regards,

Guy

[Controlink_Systems]

Hello Scott,

I was able to configure a Terminal Session on my PDA and it correctly received a very large file at 4800,7,e,2 without any trouble.

This may show that my PDA is working correctly?

Regards,

Guy

[Controlink_Systems]

Hello Scott,

Speaking with Ryan King at NI, he suspected a "framing" error. After having successfully recieved the file on the PDA at (4800,7,e,2) using the PDA's Terminal Program, I tried modifying the COM parameters within my LabVIEW application to see if a particular combination would work.

I fixed the sending unit to 4800,7,e,2 and changed only the PDA parity settings. I initialized the port using 4800,7,2 and changed only the parity. I found that if I set the paritiy to odd (on the PDA) that the entire file was correctly recieved when sending with even parity.

Hence, I believe my PDA is "OK" (primarily because the Terminal program receive the file correctly) and that a framing error exists meaning that when I initialize the port w
ithin my LabVIEW application the parity isn't being set correctly. The loop-back tests work, in my opinion, because the port, once initialized, doesn't change (hence the error does not show). However, when connecting to external devices which actually send data using even parity, the error is seen.

Your thoughts are appreciated.

Regards,

Guy

[ScottieB]

Hello, Guy.

I appreciate you posting your findings here. I will be communicating with you via KD, your original support engineer from now on.

Scott B.
Applications Engineer
National Instruments

[Ben]

PLEASE do not take this convesation off-line!

Others are listening.

Ben

[Controlink_Systems]

Hello Ben,

FYI: An NI error report, concerning the described behavior, has been prepared and will apparently be addressed with a future release...

Until then, I will modify the field unit communication parameters to 8,N,1 when possible.

Regards,

Guy

[Ben]

Thank you sir!

Ben

[arvin_labrat]

Hey Guy

Could you tell me which version of the PDA Module you are using?  I'm tring to do something similar to your PocketPCTest3.exe but my exe hangs when I try to transmit a null character (0x00)  I ran yours and it works fine.

Thanks for your time.

Eric