[Tom]

Bluetooth data on the BlackBerries is certianly possible.

Read this article:

http://www.blackberryforums.com/viewtopic.php?p=30399

[thriller]

Very intersesting until i see if myself i can only hope

[neutral]

I would love to be able to use the blackberry tethered to my ipaq. I've only had my 7100t for 1 day, and browsing from the blackberry is growing on my, but for a long time I was using the ipaq.

Hopefully this will be possible

[MadMedik]

Sync via bluetooth would be great. I still can't understand why they integrated bluetooth hardware into the device, and failed to integrate the OS capability to create a serial connection over the link...

MM

[Mark Rejhon]

Don't forget http://www.redskymobile.com and their Bluetooth GPS for BlackBerry.

[Pstmstr]

Is this available yet for the 7290?

[mk1151]

Not sure I would be too optimistic...

GPS and Barcode scanners both use serial communications, not true "data" transer (OBEX) - they could just be setting up a silent modem-emulation interface to get the bits they need between devices.

Would like to see which BT stack/protocols they are using, but I can imagine that both GPS and Barcode scanners could be supported by doing nothing more that opening the modem port and TX/RX. Not to say that this method couldn't be used for transmitting data, but it certainly wouldn't provide the speed that you would expect from a true OBEX BT connection...

Thoughts?

[rcbjr]

Originally Posted by mk1151

Not sure I would be too optimistic...

GPS and Barcode scanners both use serial communications, not true "data" transer (OBEX) - they could just be setting up a silent modem-emulation interface to get the bits they need between devices.

Would like to see which BT stack/protocols they are using, but I can imagine that both GPS and Barcode scanners could be supported by doing nothing more that opening the modem port and TX/RX. Not to say that this method couldn't be used for transmitting data, but it certainly wouldn't provide the speed that you would expect from a true OBEX BT connection...

Thoughts?

Having lurked here for several weeks, this first line of this posting gave me the impetus to register and make my first post.

So serial data as provided by GPS receivers and Barcode readers is not “True Data”, in that they don’t use the OBEX protocol. By the way Bluetooth is a serial data transfer wireless bus. I don’t know what the protocol overhead percentage of OBEX is but I can’t imagine that it could be less than the minimal protocol overhead required to transfer NIMA data or that used by barcode readers. I know that I once had a barcode reader the connected into the keyboard bus of my PC to use as an input device. Now that’s minimal protocol overhead, one parity bit.

A stream of pure data transferred over a reliable connection, has a much higher data rate than one split into multiple packets, each with its own protocol header and administrative add-ons. The larger the data block per packet and the smaller the header, the faster the throughput, unless the connection is unreliable and packets must be sent multiple times. Then the smaller packet has a greater chance of making it through without error.

Just a short rant.

[mk1151]

Originally Posted by rcbjr

Having lurked here for several weeks, this first line of this posting gave me the impetus to register and make my first post.

So serial data as provided by GPS receivers and Barcode readers is not “True Data”, in that they don’t use the OBEX protocol. By the way Bluetooth is a serial data transfer wireless bus. I don’t know what the protocol overhead percentage of OBEX is but I can’t imagine that it could be less than the minimal protocol overhead required to transfer NIMA data or that used by barcode readers. I know that I once had a barcode reader the connected into the keyboard bus of my PC to use as an input device. Now that’s minimal protocol overhead, one parity bit.

A stream of pure data transferred over a reliable connection, has a much higher data rate than one split into multiple packets, each with its own protocol header and administrative add-ons. The larger the data block per packet and the smaller the header, the faster the throughput, unless the connection is unreliable and packets must be sent multiple times. Then the smaller packet has a greater chance of making it through without error.

Just a short rant.

Well, welcome aboard!

Glad I snared ya -

Perhaps I should have assumed that everyone knew that BT was a serial transfer protocol, but there was a lot of hope that the BB with BT would support file sync and file transfer between devices, so the point of my post was to simply say that the ability to gather streamed data from a terminal-type device (GPS/Barcode/etc) is very different from supporting OBEX type operations...

Sorry that wasn't clear.

Sheesh - everybody's a critic 8)

[rcbjr]

I understood the difference, just trying to point out that anything transfered over a databus is data and that just because protocols that pass formating information take up a portion of the available bandwidth, slowing down the total throughput, although it does make postprocessing easier on the developer. And to the guy lost in the woods, with a broken leg trying to tell the resque squad where he is, the NIMA data is definitly \"TRUE\" data. No smiley available to add from my 7290.



Posted wirelessly from a BlackBerry using wap.BlackBerryClub.com

[barjohn]

Below is the Bluetooth compliance data for the 7250 & I think the 7290. Can anyone confirm that the 7290 is FCC code RAL? I know the 7250 is FCC Code RAR



Annex A
Compliant Portion
See separate declaration.
Pre qualified components
CSR BC2-Audio version EK-E4, Bluetooth ID B00746
CSR HCI Stack version 17.3.4, Bluetooth ID B00169
Extended Systems XTNDAccess Blue SDK version 1.4.1, Bluetooth ID B00150
HW and SW version combinations for the various products
Model HW SW
RAL11IN ASY-07729-001 Rev. 1B 1.4.0.20_4.0.0.126/b4.0.0.145,
1.4.0.29_4.0.0.178/b4.0.0.211
RAR20CN ASY-07338-001 Rev. 1A 2.0.0.28_4.0.0.200/b4.0.0.237
Revision history
Revision Date Changes
1 November 18, 2004 First release
2 January 17, 2005 HW/SW combination table created, New Product ID,
New SW version

Bluetooth Profiles
1. Part K:1: GAP conformance as defined in the Bluetooth Profile Specification, version
1.1 including all mandatory features and all optional/conditional features except:
K:1.1/2, K:1.1/4, K:1.1/6, K:1.3/2 and K:1.3/6.
2. Part K:5 SPP conformance as defined in the Bluetooth Profile Specification, version
1.1 including all mandatory features and all optional features. Both device roles are
supported.
3. Part K:6 HS interoperability as defined in the Bluetooth Profile Specification, version
1.1 including all mandatory features and the following optional/conditional features:
K:6.2/4 and K:6.2/9-11. Only the AG role is supported.
4. HFP: HFP interoperability as defined in the Hands Free Profile specification version
1.00m including all mandatory features and the following optional features: Table 2;
Items 5 and 18a. Only the AG role is supported.
Note that the following test case waivers are applied: TCW_14/03.