Re: rs232 reading problem explanation

• Previous message: Paul G. Tobey [eMVP]: "Re: rs232 reading problem explanation"
• In reply to: Jes?s Trigo CPS - University of Zaragoza: "rs232 reading problem explanation"
• Messages sorted by: [ date ] [ thread ]

Date: Fri, 17 Dec 2004 08:53:20 +1300

Hi,

> With regard to UNICODE: i understand (and correct me if i am wrong,
> please) that the bytes
>
> that arrive to the serial port of the pda are simply bits, no more, it
> doesn't matter if they
>
> are ascii or unicode, is this correct??
>

Yes it is. I don't know what your problem is, but binary data is binary
data - same on ce as desktop. UNICODE is only required for api calls and I
don't think thats your problem here. Apart from the sizeof problem that Paul
mentioned it doesn't matter if you write ascii error messages to a file as
long as the reader expects ascii.
Have you tried receiving test data from some other device e.g. a PC via
Hyperterminal to check out if your problem is a hardware or software issue?

Cheers

Doug Forster

"Jes?s Trigo CPS - University of Zaragoza" <ecgpda@yahoo.com> wrote in
message news:282d4657.0412160926.7f71cf59@posting.google.com...
> First of all, i want to thank you all for your quick reply and your
> good advices.
>
>
> ////////////////////////////////////////////////////////////////////////
>
> I think that i have to explain better my project: i have a device that
> acquires
>
> Electrocardiograms. My finally objective is to draw these ECG's on a
> PDA. The acquirer device
>
> sends the data via rs232. It is always sending what it acquires (so,
> if you don't connect the
>
> electrodes to a body, you get noise). I have analyzed the protocol
> with a rs232 sniffer in my
>
> PC and i've got something like this:
>
>
>
> when electrodes connected:
>
> 3F 62 40 FA 3F 64 3F 88 3F 9A 3F 70 3F EE 3F 9B
> 2C 3F 2C 40 B4 3F 0C 3F 54 3F 54 3F 0A 3F B6 3F
> 6F 44 3F 28 40 D2 3F 02 3F 3A 3F 6C 3E EA 3F 9A
> 3F 59 89 3F 5C 40 F4 3F 28 3F 66 3F 6A 3F 2A 3F
> C0 3F 85 50 3F 4A 41 04 3F 60 3F 70 3F 72 3F 4E
> 3F A8 3F 93 ED 3E F0 40 B0 3F 10 3F 2C 3F 4A 3F
> 04 3F B0 3F 6F BF 3F 48 41 04 3E F6 3F 3C 3F 4E
> 3E E4 3F 62 3F A5 51 3F 60 41 68 3F 5A 3F A0 3F
> B4 3F 80 3F C4 3F 81 CB 3F 1A 41 20 3F 4E 3F 8A
> 3F A0 3F 6A 3F D0 3F B5 65 3F 20 41 4A 3F 72 3F
> 82 3F 9E 3F 3A 3F AA 3F 6F B7 3F 30 41 58 3F 6A
>
>
> This ECG acquisitor sends 8 leads, 16 bits/sample. You can see "3F 62"
> would be the first
>
> sample of the first lead, "40 FA" the first sample of the second lead,
> and so on... until "3F
>
> 9B" which would be the first sample of the 8th lead. Then you have
> "2C" which is a byte of
>
> sincronism, and after that, all repeated : "3F 2C" would be the SECOND
> sample of the first
>
> lead "40 B4" the SECOND sample of the second lead, and so on... until
> "3F 6F" which would be
>
> the SECOND sample of the 8th lead. And then the sincronism byte "44".
> And that's the way it
>
> works.
>
>
> I can draw beautiful ECG's in my PC with matlab following this
> protocol. :·)
>
> It is easy to notice that the more significant bits of each sample are
> always around 40 (3F,
>
> 41...)
>
>
>
>
> Well, when i test the code i've written on visual studio all works
> fine, as i said, because i
>
> can read from serial port and write data in a file and i can see so
> much 40's in that file
>
> and i can after draw beautiful ECG's in matlab with that file.
>
>
> But when i try the same code on the PDA all i get is something like
> this:
>
> 65 E9 00 AB 61 FF F8 22 D8 F9 8D FC 0D FA 3D 1B
> D6 90 01 F8 76 8A F6 63 D8 A7 60 C7 6D FC FD FE
> 2D 1A 56 2A 01 FC 27 89 5B F8 60 CF 77 FE 9D 83
> 0F 06 36 29 00 E3 0E 67 06 4B 81 1F 7F 93 FE 3D
> 05 DB 32 2C 90 06 E0 BF 83 27 81 CB 81 5B FA 9D
> 7F BB FE AD 05 0B F9 00 47 0E 7F 02 AF 7F D7 FD
> FB 9D FC FD 19 96 EC 00 3F 12 67 F8 4B B0 F8 0B
> FE 5D F9 3D 1B 56 26 05 E0 4F 85 37 06 A3 02 97
> FE 1D F8 FD 09 36 04 2B D6 03 F8 4D 02 73 02 BF
> 81 53 FA 2D 7F CB 02 17 02 8D 63 00 17 85 1F 02
> 8B 7F EF 7D DE CD F9 ED 0B D6 8A 03 F8 7F 12 02
> 8B 7F 23 5F F3 A7 57 06 51 02 00 E7 89 9B 83 53
> FE 5D EB AD FD 5D F8 6D 1B D6 21 13 80 27 85 3F
> 06 3B FE FD 7D A3 7F 6B FE ED 81 B5 91 00 63 02
> 23 81 AB 81 27 FA 0D 7F B3 02 93 02 29 69 00 3F
>
>
>
> and i can assure you that i get no one 40 in 3 seconds (18.6 KB) and
> only a few 3F's.
>
>
>
> so, i wonder where's the problem.
>
>
>
> ////////////////////////////////////////////////////////////////////////
>
> I am going to put some data that could help:
>
> - in 3 seconds, with visual studio and the PC, i get a file of 35.6 KB
> --> and works fine !!
>
> - in 3 seconds, with evc++ 4.0 and the PDA, i get a file of 18.6 KB
> --> i suspect there's a
>
> data loss.
>
> - in 3 seconds, with evc++ 4.0 and the PDA, and removing from my code
> the ClearCommError call
>
> (therefore reading only 1 byte each time i call ReadFile) i get a file
> of 3.61 KB --> so i
>
> understand than my serial port actually supports the ClearCommError
> call, am i correct?? and
>
> in that way... if i remove ClearCommError, how can i know the number
> of bytes recieved while
>
> i have been writing the last ones in the file?
>
>
>
> I have take 3 seconds, and i could take other time, but i certainly
> cannot wait the thread to
>
> finish becuase it never would finish. The acquisitor is always sending
> data, and the
>
> readthread is always receiving, so i have to stop it in some moment,
> am i correct?
>
> ////////////////////////////////////////////////////////////////////////
>
>
>
> With regard to UNICODE: i understand (and correct me if i am wrong,
> please) that the bytes
>
> that arrive to the serial port of the pda are simply bits, no more, it
> doesn't matter if they
>
> are ascii or unicode, is this correct??
>
> but i want to write in a file the bytes (in hex) i read ... well, I
> recognize that i am a
>
> little bit lost in this topic and i will investigate about unicode and
> BOM.
>
>
>
>
> ////////////////////////////////////////////////////////////////////////
>
> incidental question:
>
> why can't i read from serial port when usb is connected to the PC?
>
> ////////////////////////////////////////////////////////////////////////
>
>
>
>
> I hope that my explanation would help you to understand my project.
>
> Once more time i want to thank every one of you that make an effort
> for the good operation of
>
> this newsgroup.
>
>
> Thanks a lot.

• Previous message: Paul G. Tobey [eMVP]: "Re: rs232 reading problem explanation"
• In reply to: Jes?s Trigo CPS - University of Zaragoza: "rs232 reading problem explanation"
• Messages sorted by: [ date ] [ thread ]