Accessing the Bluetooth COM ports in VB

[Guest]

Bluetooth has no baud rate, partity, etc. Setting one is irrelevent, and I
still think that the problem lies in the driver not properly handling these
settings.


--

Chris Tacke, Embedded MVP
OpenNETCF Consulting
Managed Code in an Embedded World
www.OpenNETCF.com

 

[silverfox]

Bluetooth has no baud rate, partity, etc. Setting one is irrelevent, and I
still think that the problem lies in the driver not properly handling these
settings.

--

Chris Tacke, Embedded MVP
OpenNETCF Consulting
Managed Code in an Embedded Worldwww.OpenNETCF.com

Yeah, I knew that those settings are irrelevant to the BT transceiver,
but I thought that maybe, as one other poster suggested, the interface
between the SerialPort object and the BT stack might need these
settings to be correct. I am groping in the dark here as there is so
much that I do not know about how it all fits together. Just trying
to puzzle it all out.

So, if it is the driver, does that mean that I am out of business?
Honestly, I don't really understand the distinction between the stack
and the driver. There is only one software version listed in the
iPAQ's BT asset listing, and on my machine it is 1.4.1.75, which is
variously referred to on the web as the stack version and as the
driver version. I am still not sure which that version refers to.

Well, I just found this link (http://www.salling.com/forums/
viewtopic.php?p=21525) which is the first indication I have found
that there is a newer stack version available. I think I will give it
a try and see if it helps. Any other suggestions are welcome.

 

[Paul G. Tobey [eMVP]]

OK, I've looked through the old messages and I don't see what the
characteristics of 'msg' are that you are passing to that Write method. You
might try, if msg is a large amount of data, sending something simple, like
a ASCII string (the three bytes 65, 66, 67 would be 'ABC' in ASCII), and
seeing if the other end receives that.

Paul T.

You don't know much about operating systems. What if the application
isn't
running application code at the time of the "stop"? What if it's in the
middle of a driver call? Is the driver left in a bad state? Can the OS
terminate the driver, too? What if another application is also in the
middle of a call to that driver? What if the driver is for the display?
It's not so simple to 'just' terminate an application.

The most-likely place for the bug is your code. I'm not convinced yet
that
you are the source of the problem. The second most-likely is in the .NET
CF, hence the suggestion that you take that out of the loop by using
native
code. The third most-likely is theBluetoothstack, as it was probably
only
tested for the standard communication tasks: headset, ActiveSync and
maybeBluetoothserial for GPS. The lest-likely is the operating system
itself.
It's certainly not bug-free, but it gets used in a lot more different
scenarios than any individual program, driver, or framework.

Paul T.

On Aug 10, 5:29 am, "<ctacke/>" <ctacke[at]opennetcf[dot]com> wrote:
I haven't had a chance to do what you suggest and it will be more
than
a short gentle curve for me to figure out how. But are you saying
that you think that the problem is with the Widcomm stack that HP
ships with all its iPAQs? Isn't that equally unlikely?

Since I know how OEMs tend to test, it's not as unlikely no. It's
also
possible that how they tested the ports differs from how you're trying
to
use them (I can pretty much guarantee they used native code to test).
My
guess is that the serial classes are trying to set up some parameter
that
makes sense in a real serial connection, but HP didn't implement or
implemented incorrectly that same parameter and never bothered to test
what
happens when you try to change it. Good examples might be baud rate,
flow
control, parity, stop bits, timeouts, etc.

Chris Tacke, Embedded MVP
OpenNETCF Consulting
Managed Code in an Embedded Worldwww.OpenNETCF.com

Actually, I was originally referring to the inability to stop the
program once the OS caught an IOException and reported the problem. I
would have thought that the Quit button on the OS-generated dialog box
would have worked at that point regardless of any problem with the
driver. And barring that, the STOP running program in the
System>Memory Running Programs dialog should work regardless of a
problem with a third party driver. And when both of those things fail
that seems like a bug in the OS to me. But maybe that's just me.

So, is it your opinion that HP is at fault here for including a
BlueToothstack that is incompatible with Windows CE, at least with
the SerialPort API? The Widcomm stack is VERY widely used on PDAs
running Windows CE, by the way, and I would be surprised to find that
such an obvious application as serial communications was not tested at
least to the point to see that the Open method didn't fail every
time. But again, maybe that's just me.
You don't know much about operating systems.

Ok, I admit it.

I don't really see how the problem can be in my code, however, since
it consists of only the following two lines:

System.IO.Ports.SerialPort serialOutputPort = New
System.IO.Ports.SerialPort("COM8")
serialOutputPort.Open()

Upgrading to CF2 SP2 got past this problem, however, and as I mention
in another post, it now hangs on the following line:

serialPort.Write(msg)

I

 

[Dick Grier]

Hi,

With BT, the actual port speed is arbitrary. You can use anything that is
supported, with exactly the same result. You would want to use 8 data bits,
with no parity. If the code hangs on Output... I'm confused.
CFSerialIO.dll (from my homepage) use SerialPort.Output(somemessage) syntax.
The SerialPort object in Visual Studio uses SerialPort.Write(somemessage)
syntax.

I have never seen a "hang," though the Output method in my dll is a blocking
method. Thus, if data are not accepted by the serial driver (control must
be returned from the WriteFile API call), then what you are seeing is what
I'd expect. I guess. Windows CE does not support Overlapped IO, so any
non-blocking call to WriteFile requires extra effort -- and I've never seen
the need. If this is the situation, there would seem to be some underlying
mechanism that is the source of the trouble. Just, IMO, from the outside
looking in.

Dick

--
Richard Grier, MVP
Hard & Software
Author of Visual Basic Programmer's Guide to Serial Communications, Fourth
Edition,
ISBN 1-890422-28-2 (391 pages, includes CD-ROM). July 2004, Revised March
2006.
See www.hardandsoftware.net for details and contact information.

 

[silverfox]

OK, I've looked through the old messages and I don't see what the
characteristics of 'msg' are that you are passing to that Write method. You
might try, if msg is a large amount of data, sending something simple, like
a ASCII string (the three bytes 65, 66, 67 would be 'ABC' in ASCII), and
seeing if the other end receives that.

Paul T.

You don't know much about operating systems. What if the application
isn't
running application code at the time of the "stop"? What if it's in the
middle of a driver call? Is the driver left in a bad state? Can the OS
terminate the driver, too? What if another application is also in the
middle of a call to that driver? What if the driver is for the display?
It's not so simple to 'just' terminate an application.
The most-likely place for the bug is your code. I'm not convinced yet
that
you are the source of the problem. The second most-likely is in the .NET
CF, hence the suggestion that you take that out of the loop by using
native
code. The third most-likely is theBluetoothstack, as it was probably
only
tested for the standard communication tasks: headset, ActiveSync and
maybeBluetoothserial for GPS. The lest-likely is the operating system
itself.
It's certainly not bug-free, but it gets used in a lot more different
scenarios than any individual program, driver, or framework.
Paul T.

On Aug 10, 5:29 am, "<ctacke/>" <ctacke[at]opennetcf[dot]com> wrote:
I haven't had a chance to do what you suggest and it will be more
than
a short gentle curve for me to figure out how. But are you saying
that you think that the problem is with the Widcomm stack that HP
ships with all its iPAQs? Isn't that equally unlikely?
Since I know how OEMs tend to test, it's not as unlikely no. It's
also
possible that how they tested the ports differs from how you're trying
to
use them (I can pretty much guarantee they used native code to test).
My
guess is that the serial classes are trying to set up some parameter
that
makes sense in a real serial connection, but HP didn't implement or
implemented incorrectly that same parameter and never bothered to test
what
happens when you try to change it. Good examples might be baud rate,
flow
control, parity, stop bits, timeouts, etc.
--
Chris Tacke, Embedded MVP
OpenNETCF Consulting
Managed Code in an Embedded Worldwww.OpenNETCF.com
Actually, I was originally referring to the inability to stop the
program once the OS caught an IOException and reported the problem. I
would have thought that the Quit button on the OS-generated dialog box
would have worked at that point regardless of any problem with the
driver. And barring that, the STOP running program in the
System>Memory Running Programs dialog should work regardless of a
problem with a third party driver. And when both of those things fail
that seems like a bug in the OS to me. But maybe that's just me.
So, is it your opinion that HP is at fault here for including a
BlueToothstack that is incompatible with Windows CE, at least with
the SerialPort API? The Widcomm stack is VERY widely used on PDAs
running Windows CE, by the way, and I would be surprised to find that
such an obvious application as serial communications was not tested at
least to the point to see that the Open method didn't fail every
time. But again, maybe that's just me.
You don't know much about operating systems.

Ok, I admit it.

I don't really see how the problem can be in my code, however, since
it consists of only the following two lines:

System.IO.Ports.SerialPort serialOutputPort = New
System.IO.Ports.SerialPort("COM8")
serialOutputPort.Open()

Upgrading to CF2 SP2 got past this problem, however, and as I mention
in another post, it now hangs on the following line:

I

I am in fact sending three ascii characters plus a CR.

 

[Paul G. Tobey [eMVP]]

And the result on the sending end is nothing. What is the result on the
receiving end? It sure sounds like no connection is established.

Paul T.

OK, I've looked through the old messages and I don't see what the
characteristics of 'msg' are that you are passing to that Write method.
You
might try, if msg is a large amount of data, sending something simple,
like
a ASCII string (the three bytes 65, 66, 67 would be 'ABC' in ASCII), and
seeing if the other end receives that.

Paul T.

On Aug 10, 9:57 am, "Paul G. Tobey [eMVP]" <p space tobey no spam AT
no instrument no spam DOT com> wrote:
You don't know much about operating systems. What if the application
isn't
running application code at the time of the "stop"? What if it's in
the
middle of a driver call? Is the driver left in a bad state? Can the
OS
terminate the driver, too? What if another application is also in the
middle of a call to that driver? What if the driver is for the
display?
It's not so simple to 'just' terminate an application.

The most-likely place for the bug is your code. I'm not convinced yet
that
you are the source of the problem. The second most-likely is in the
.NET
CF, hence the suggestion that you take that out of the loop by using
native
code. The third most-likely is theBluetoothstack, as it was probably
only
tested for the standard communication tasks: headset, ActiveSync and
maybeBluetoothserial for GPS. The lest-likely is the operating system
itself.
It's certainly not bug-free, but it gets used in a lot more different
scenarios than any individual program, driver, or framework.

Paul T.

news:[email protected]...

On Aug 10, 5:29 am, "<ctacke/>" <ctacke[at]opennetcf[dot]com> wrote:
I haven't had a chance to do what you suggest and it will be more
than
a short gentle curve for me to figure out how. But are you
saying
that you think that the problem is with the Widcomm stack that HP
ships with all its iPAQs? Isn't that equally unlikely?

Since I know how OEMs tend to test, it's not as unlikely no. It's
also
possible that how they tested the ports differs from how you're
trying
to
use them (I can pretty much guarantee they used native code to
test).
My
guess is that the serial classes are trying to set up some
parameter
that
makes sense in a real serial connection, but HP didn't implement or
implemented incorrectly that same parameter and never bothered to
test
what
happens when you try to change it. Good examples might be baud
rate,
flow
control, parity, stop bits, timeouts, etc.

Chris Tacke, Embedded MVP
OpenNETCF Consulting
Managed Code in an Embedded Worldwww.OpenNETCF.com

Actually, I was originally referring to the inability to stop the
program once the OS caught an IOException and reported the problem.
I
would have thought that the Quit button on the OS-generated dialog
box
would have worked at that point regardless of any problem with the
driver. And barring that, the STOP running program in the
System>Memory Running Programs dialog should work regardless of a
problem with a third party driver. And when both of those things
fail
that seems like a bug in the OS to me. But maybe that's just me.

So, is it your opinion that HP is at fault here for including a
BlueToothstack that is incompatible with Windows CE, at least with
the SerialPort API? The Widcomm stack is VERY widely used on PDAs
running Windows CE, by the way, and I would be surprised to find
that
such an obvious application as serial communications was not tested
at
least to the point to see that the Open method didn't fail every
time. But again, maybe that's just me.

You don't know much about operating systems.

Ok, I admit it.

I don't really see how the problem can be in my code, however, since
it consists of only the following two lines:

System.IO.Ports.SerialPort serialOutputPort = New
System.IO.Ports.SerialPort("COM8")
serialOutputPort.Open()

Upgrading to CF2 SP2 got past this problem, however, and as I mention
in another post, it now hangs on the following line:

I

I am in fact sending three ascii characters plus a CR.

 

[silverfox]

Hi,

With BT, the actual port speed is arbitrary. You can use anything that is
supported, with exactly the same result. You would want to use 8 data bits,
with no parity. If the code hangs on Output... I'm confused.
CFSerialIO.dll (from my homepage) use SerialPort.Output(somemessage) syntax.
The SerialPort object in Visual Studio uses SerialPort.Write(somemessage)
syntax.

I have never seen a "hang," though the Output method in my dll is a blocking
method. Thus, if data are not accepted by the serial driver (control must
be returned from the WriteFile API call), then what you are seeing is what
I'd expect. I guess. Windows CE does not support Overlapped IO, so any
non-blocking call to WriteFile requires extra effort -- and I've never seen
the need. If this is the situation, there would seem to be some underlying
mechanism that is the source of the trouble. Just, IMO, from the outside
looking in.

Dick

--
Richard Grier, MVP
Hard & Software
Author of Visual Basic Programmer's Guide to Serial Communications, Fourth
Edition,
ISBN 1-890422-28-2 (391 pages, includes CD-ROM). July 2004, Revised March
2006.
Seewww.hardandsoftware.netfor details and contact information.

Dick, I just sent you a vb file containing the simplest possible
example that hangs my iPAQ on a SerialPort.Write( ). The PDA must be
physically reset after the hang. The program does nothing but create
a SerialPort object with the string "COM8", calls Open( ) on that
object then calls Write("ABC") on it. The program contains calls to
MsgBox( ) before all four operations and after the Write( ). The
last MsgBox to display is the one before the Write( ). The final one
never appears. If anyone would like me to send them a copy of this vb
file, please let me know.

 

[Dick Grier]

See my replies to your email.

--
Richard Grier, MVP
Hard & Software
Author of Visual Basic Programmer's Guide to Serial Communications, Fourth
Edition,
ISBN 1-890422-28-2 (391 pages, includes CD-ROM). July 2004, Revised March
2006.
See www.hardandsoftware.net for details and contact information.

 

[silverfox]

See my replies to your email.

--
Richard Grier, MVP
Hard & Software
Author of Visual Basic Programmer's Guide to Serial Communications, Fourth
Edition,
ISBN 1-890422-28-2 (391 pages, includes CD-ROM). July 2004, Revised March
2006.
Seewww.hardandsoftware.netfor details and contact information.

A few posts back someone said that the SerialPort problem I was
experiencing was most likely due an error in my code. I replied that
my program contained only three significant lines of code and I didn't
see how there could be a problem there. Well, ahem, it seems that I
did screw up one of those three lines of code. The PDA has two serial
ports dedicated to the bluetooth device, one for input and one for
output. And, you guessed it, I switched them. I tried to write to
the input port. 40 years of programming should have taught me that no
matter how small a program, I am capable of getting something wrong.
Donald Knuth, I am not. So, I am sorry for all the bandwidth and time
anyone might have spent reading about or thinking about my problems
with SerialPort.Write( ) hanging my PDA. It works fine when you write
to the output port instead of the input port. My attempts to get
SerialPort.Read( ) to work (yes, on the input port) are still
unproductive, but Richard Grier sent me some information on that
problem and I hope to have the whole thing put to bed soon. Thank you
for your patience and please accept my apologies. And Richard, thank
you especially for your help.