Re: Bluetooth Serial Port Profile and Tcl communications

On Dec 8, 1:01 pm, Alexandre Ferrieux <alexandre.ferri...@xxxxxxxxx>
wrote:
On Dec 8, 9:13 pm, sv <nathan.sel...@xxxxxxxxx> wrote:



Hello all,

Serial port communications I thought should be fairly straightforward,
but it appears not to be - at least in what I am experiencing. Any
help rendered to get me past this would help. Thanks.

I have a BT-module (Roving Networks RN-41) connected to a processor's
UART. Data is transmitted by the processor and the RN-41 BT module
acts as a pass-through. The data is received over RF by a BT USB
dongle (Dlink DBT-120) connected to a PC running Windows XP SP3).
Under device manager in XP, I see that the RN-41 is recognized as
having a Serial Port profile and assigned a COM number.

When I open Docklight or RS232Comm, I can open the COM and talk to the
remote BT device (query status/address/baud settings, etc.) and also
transfer data bi-directionally. So all appears good there.
I think that validates all aspects of the BT stacks,drivers and
communication channel. I can do this at various baud settings and
everything works just well.

An important point to note here is that I can disconnect and connect
as many times as I want and no problems are noticed. In fact on my BT
module there's a 'link' green LED. When I connect, it comes on green
and goes off when I disconnect. So visually I can tell when the COM
port is opened or closed.

Now when I try this through Tcl ("open COMx: r+" or "open \\\\.\\COMx r
+" or variants of this), I observe a bizzare behavior:

3 out of 5 times, I get either of the following two message screens:
          couldn't open serial "\\.\COMx": invalid argument (or)
          couldn't reopen serial "\\.\COMx": invalid argument

And the other 2 out of 5 times the following is observed: The device
connects (green LED ON), disconnects immediately (green LED OFF),
connects again, disconnects again and finally connects (green LED ON)
and stays solid. Sometimes this toggling is not 5 times as above, but
only 3 times…ON, OFF, ON.

Now if I try to connect again, 9 out of 10 times, I get a message like
this:
          couldn't reopen serial "\\.\COMx": invalid argument
There's no way for me to recover from this, except by power cycling
the BT module (leaving the dongle as is).

Interestingly, there's a very similar (I would say, identical really)
behavior observed by someone using JavaApps (not Tcl). The link is:http://groups.google.com/group/trackbot/browse_thread/thread/89910d2c...
and he is using a completely different BT USB adapter (dongle) and BT
module.

Any pointers on where I ought to look?

Incidentally, I had an off-line discussion with a member of this group
Rolf Schroedter and he rightly suggested that I move this discussion
to this board for getting more people involved and preserve this for
the public should there be others with similar issues. (Thanks Rolf!)
His Tcl serial port monitor (http://www.rolf-schroedter.de/moni/)
also exhibits a similar behavior as what is detailed above.

Thanks,
-sv

Not sure whether you only omitted to mention it, but when using a BT
device you must at least select the device you want to connect to
(even if it's the only one within range). I have very little
experience in this, but I seem to remember the BT USB dongle I was
using shipped with a specific GUI doing exactly that.

Once the device becomes visible in the list, you select it, and tell
the GUI to connect to it. Then, and only then, does the channel become
a COMx. You may then open and close it many times on the COM side,
this will not change the connected status at the BT level.

Sorry if this is obvious, but from your description the separation
between the two levels was not clear.

Also, check out the COM-specific settings like baudrate etc. Make sure
there is agreement between what's configured at the COM emulator level
and what your Tcl script [fconfigure]s.

One last shot in the dark: why are you trying various decorations of
"COMx:" ?

-Alex


Alex,
Yes, the dongle and BT module are paired up first over Windows 'My
Bluetooth Places'. I had left that detail out as I assumed it was
implicitly stated given that I can connect up using terminal-like
programs Docklight and RS232Comm, but thanks for asking nevertheless.
Can't overlook any detail!

And as for why various COMx? BT module comes up in Windows with high
integer COM (e.g., COM11 or COM21 or similar) and many Windows COM
related sites refer to constraints in Windows to serial ports between
COM1-COM4 or COM1-COM9. So just to be sure, I have tried reassigning
port values down to COM2/4, etc. and have also left them at the values
that widows automatically assigns.

-sv
.

Relevant Pages

  • Re: Bluetooth Serial Port Profile and Tcl communications
    ... but it appears not to be - at least in what I am experiencing. ... dongle connected to a PC running Windows XP SP3). ... His Tcl serial port monitor ...
    (comp.lang.tcl)
  • Re: Bluetooth Serial Port Profile and Tcl communications
    ... Serial port communications I thought should be fairly straightforward, ... but it appears not to be - at least in what I am experiencing. ... dongle connected to a PC running Windows XP SP3). ... An important point to note here is that I can disconnect and connect ...
    (comp.lang.tcl)
  • serial port too fast for Core Duo?
    ... I have an oscilloscope with a 19200 bps serial port on it. ... It works fine with my old Windows 2000 computer. ... But it will not work with the on-board serial port on my shiny new HP DC7900 with Fedora 10! ... Using a USB-to-RS232 dongle works, presumably because the dongle has a larger buffer than the normal 16 byte UART. ...
    (Fedora)
  • Re: Flow Control on Serial Device
    ... I found out that if I just reboot my pc from Windows to Linux ttyS0 behaves ... Then I see in Linux the same status as in WT: rts on, ... means your serial port is not active... ...
    (comp.os.linux.networking)
  • Re: Multimedia Timer
    ... First, as already observed, WIndows is *not* a real-time system, and 20ms events are ... Does the recipient of the serial port data need to receive one "chunk" ... delete buffer; ... That's because I need those 20ms delay between two requests. ...
    (microsoft.public.vc.mfc)