[fluffyrobot]

Hi...

I am developing a MIDP2.0 application to talk to a device via Bluetooth/RFCOMM and whenever I do a read of the associated InputStream on the 6620 the application exits without an Exception being thrown. The same app works fine on the 6600.

Can anyone tell me if there is a solution to this problem?

Thanks

[jxt]

I don't know if I can help, but I'm having similar difficulties with a 6620 reading GPS data using RFCOMM. Sometimes the app works fine, but it always eventually fails, often as you have seen -- just quits without throwing any exception. I'm wondering if the Bluetooth stack in the 6620, or perhaps the Bluetooth chipset, is faulty.

I've also seen missing characters in the datastream coming from the Bluetooth GPS receiver once that data is received by the 6620 Bluetooth stack.

Alas, I don't have a 6600 to test it on. But I have run essentially the same app on a Bluetooth iPAQ without any spontaneous exiting and without any missing data, all when using the same Bluetooth GPS receiver.

If you gain any insight into this problem, I would appreciate it if you would share it.

Thanks.

[fluffyrobot]

I am now quite sure that the Nokia btssp or RFCOMM implementation on the 6620 is the cause of my headache. I was talking to another person who had this problem and he abandoned it in favor of L2CAP. I am now working on this idea as well, but have not been able to establish a connection yet on the 6600 or 6620.

Jxt, if you try L2CAP and manage to get it to work please post your solution. I will also keep this thread up to date with my findings.

[jxt]

Using L2CAP is a good idea which I've already tried. Alas, both of the GPS receivers I have use only btspp (aka RFCOMM). Asking for an L2CAP service (UUID 0x0100) and then calling getConnectionURL() always returns a btspp:// URL, the same as when asking for an RFCOMM (0x0003) service. So I'm stuck with RFCOMM.

How have you become so convinced that the 6620 is bad? I only *suspect* that it is bad from rather circumstantial evidence.

If it is bad, does anyone know how to tell Nokia of the problem and how to get a fix, via firmware upgrade perhaps?

Thanks.

[fluffyrobot]

Jxt, I have exactly the same experience: I ask for L2CAP devices during discovery but when I pass the ServiceRecord to getConnectionURL() I get a "btspp://....." url and not a "btl2cap://...." url. When I make my own L2CAP url open() throws an exception "SymbianOS error -34" which means could not connect.

I may be a bit foggy on this but...since I can get a RFCOMM connection don't I automatically have a L2CAP connection. I thought that the stream-like RFCOMM mechanism was just an interface to the lower packet based L2CAP. In other words all communication is actually L2CAP but you have RFCOMM on top of it for people who like a stream API.

Maybe someone can clear this up for me?

[lbauer]

For what it's worth, I've encountered the same problem with RFCOMM. I posted about it on this board several months ago. I never found a workaround, but L2CAP was sufficient for my purpose.

-Lujo

[jxt]

To fluffyrobot: I'm quite foggy too. I think you're essentially correct. RFCOMM is built "on top of" L2CAP. But apparently both of the devices that I've tired to use offer only RFCOMM and do not offer direct access to the underlying L2CAP.

To lbauer: Can you help us out here? Is there anyway to "force" an L2CAP connection when a device offers only RFCOMM. Or were you just lucky in the sense that your devices responded with L2CAP when requested?

Thanks.

[lbauer]

jxt: We don't do service discovery, but instead manually construct a btl2cap:// URL. I don't know whether that would work in your case. I believe I have experienced cases (I could be wrong) where a device reported a btspp:// URL when I expected l2cap, and manually swapping the btspp of the btl2cap worked.

-Lujo

[seppo_fn]

There is a known issue with Bluetooth streams related to Java MIDP applications. You can find further information about it at forum.nokia.com | Resources | Technical Library.

-seppo
Forum Nokia

[dcowing]

Lujo,
In manually constructing your url, how do you deal with the channel?
-Dave

Originally posted by lbauer
jxt: We don't do service discovery, but instead manually construct a btl2cap:// URL. I don't know whether that would work in your case. I believe I have experienced cases (I could be wrong) where a device reported a btspp:// URL when I expected l2cap, and manually swapping the btspp of the btl2cap worked.

-Lujo