GetCommModemStatus always returns status 0

[Brane Brodnik]

Hi!

I want to monitor status inputs CTS, DSR, RLSD and RING on serial port in my
PocketPC.

DWORD mstatus = 0;
if (GetCommModemStatus(hPort, &mstatus)) {
// mstatus is always 0 here.

}

Why I always get 0 in mstatus althought
WaitCommEvent returns me notification about particular signal changes and
I'm sure status really changes.

Can anybody explain me this and help me to get information about RS232 input
signal states?
Is there anybody there who can get from GetCommModemStatus anything else
than 0?

Thanks,
Brane Brodnik

 

[Brane Brodnik]

Thanks, Dick,

but it still doesn't work for me. I downloaded your assembly for
CFSerialTerminal, added reference to CFSerialClass.dll (since source was not
available to me), built and deployed. I connected serial cable to modem and
ran CFNETTerm on my PocketPC. Everything else works fine, sending,
recieving, setting DTR and DSR, except all input signals are all reported as
False.

Since I can't see source I couldn't debug detailes, but in my source sample
I've got correctly reported changes to input signals through WaitCommEvent,
so I'm sure there is nothing wrong with hardware nor with port handle.

Do you or anybody have an idea what else could be an issue?

I work on model iPAQ H3850.

Thanks for any help,
Brane Brodnik

 

[Richard Kucia]

Brane,

My apps have a similar problem. See the discussion in this group titled
"Initial State of Serial Port". As far as I can tell, the PDA won't report
the correct input signals until it gets an appropriate interrupt. Try these
steps in order: disconnect the serial cable, soft-reset the PDA, connect the
serial cable, and run your app. If your apps work like my apps, the signals
will now be reported properly -- at least once. It seems that the act of
connecting the cable is required to get the signals sensed properly.

In my working environment, the input signals do not vary during the lifetime
of the app. I have no idea whether the signals will be reported properly if
they change while the app is running.

Dick Grier believes that the built-in serial port (COM1 is more likely to
experience this problem than add-on serial ports since COM1: may be affected
by ActiveSync.

For what it's worth, I do not see this problem when I am using the emulator.
GetModemStatus always reports correctly. This may be related to the
ActiveSync interaction mentioned above.

I have a little PortTester app (with source) you're welcome to try; just
send me an email request.

Can we get Microsoft's point of view on this problem? Is this an ActiveSync
issue, a CF issue or the responsibility of the PDA vendor?

Thanks.
Richard Kucia

 

[Dick Grier]

Hi,

This must be a hardware issue (IMO). Is this an internal serial port? You
have to understand that the internal serial port is designed for
ActiveSync -- and the manufacturer may have made some hardware compromises.
If I had your actual PPC, I could test it. However...

BTW, have you double checked to make sure that the cable or null-modem
adapter that you are using is wired to pass these signals?

Dick

--
Richard Grier (Microsoft Visual Basic MVP)

See www.hardandsoftware.net for contact information.

Author of Visual Basic Programmer's Guide to Serial Communications, 3rd
Edition ISBN 1-890422-27-4 (391 pages) published February 2002.

 

[Dick Grier]

Hi Richard,

I'm 99% sure (one can never be 100% sure of anything) that it is hardware.
These things work perfectly (for me, at any rate), with a Socket Compact
Flash serial RS-232 adapter.

I think that using the ActiveSync port is practical for certain things. For
example, I use it with a magstripe reader with no trouble. Also, I use it
with a MagTek Check imager, and with two different barcode readers. None of
these devices require RTS or DTR (DTR cannot be controlled on the internal
port), nor does my software for these monitor DSR, CTS, CXD or RI. When I
use these inputs, I rely on my Socket adapter.

Dick

--
Richard Grier (Microsoft Visual Basic MVP)

See www.hardandsoftware.net for contact information.

Author of Visual Basic Programmer's Guide to Serial Communications, 3rd
Edition ISBN 1-890422-27-4 (391 pages) published February 2002.

 

[Brane Brodnik]

Hello again!

Thanks, Richard, for very valuable tips. I don't know, what is meant by
"soft-reset", so I treat it here as switching PDA to stand-by and back to
on-line (with power button) and "hard-reset" resetting it by reset button.

After soft reset GetCommModemStatus reported correct state. I even didn't
have to force the transition of signals by reconnecting cable. It worked
fine and without any problems as far as ActiveSync was not involved. After
connecting to PC (by ActiveSync through USB), behaviour became less or more
undefined. Sometimes it seems to work, sometimes not. After it stops work,
reset is the only way it starts again. If application is active and port
opened during connection to PC it seems it works properly after, too. But it
definitely never worked if application was ran in debugging enironment.

Yes, Dick, it is internal port COM1:. I don't know if there is a hardware
issue, but it seems it must be an ActiveSync issue, too.

For now, thanks to Richard, I'm able at least run my application after it is
deployed. But for now, I'm not able to debug it under visual studio
environment, what is also essential to me.

Thanks to anybody in discussion for your effort and wellcome with any new
issue about solving the problem.

Brane Brodnik

 

[MattG]

I am having this exact problem with a program that I am working on. Resetting the PC did not it like it did in these posts. I am running XP. Does anyone have any more information on how this can be solved? I have searched the net and found this problem reported in other places but haven't found a solution. This post also refers to another post called "Initial State of Serial Port" which I can't find. Is it possible to restore it?
Just to summarize, the problem is that GetCommModemStatus always returns a constant value instead of reporting the state of CTS.
Thank you for any help you can provide.
Matt