BT Explorer Survey

Team: We are faced with a trade-off due to development time and expense for BT Explorer on the WT40X0.  Do you see BT Explorer ON THE WT40X0 (not for any generic Symbol product - please answer with only the wearable in mind) as needing to be:

1.) A tool that developers need in order to play with connecting a device, but then they would use the API set to build the BT connection & re-conenction process into an application?  (we would be able to provide a version of BT Explorer to do this)

OR 2.) a tool that customers would expect end-users to use?  In other words, they would expect a warehouse worker to use BT Explorer to connect to the printer to print bar codes? (if it has to be THIS user-friendly, it would be challenging - possible impossible, which is why I ask)

If there is some other purpose for BT Explorer, please elaborate.

Thanks!

Luis Rios Chiquete
Option 2 works for quick

Option 2 works for quick demos, showing customers that we are able to print.

In practice, the same customers expect everything to work without user intervention, that is, application controlled (or automatic configuration by any other mean).

So just provide some quick working demos and a good documented API. No BT Explorer GUI is even needed, our customers still require and like full screen applications...

Vote: 
Vote up!
Vote down!

Points: 0

You voted ‘up’


Jeff Crosby
Thx for asking. Option 1 is

Thx for asking.

Option 1 is my vote.  This is what my development partners have been dying for.

thx

jeff

Vote: 
Vote up!
Vote down!

Points: 0

You voted ‘up’


Don Khan
Option 1 would permit

Option 1 would permit confirmation on the ability of the devices to, at minimum, be able to pair. This is a "must have".  The extent of the APIs would have to cover; pairing, profiles, and connection management.  BT printing, scanning, and the inevitable voice on the wearable are to be considered.
Vote: 
Vote up!
Vote down!

Points: 0

You voted ‘up’


Barry Ure
My first inclination was

My first inclination was "both", but that defeats the purpose of the survey.  I would prefer the API set, especially for voice picking applications.

But the bottom line is that I soon as we tell customers we have a bluetooth interface, they will expect to be able to use it, along with a choice of profiles.

I choose Option 2...Final answer.

Vote: 
Vote up!
Vote down!

Points: 0

You voted ‘up’


Lawrence Annunziata
Option 1 makes sence but an

Option 1 makes sence but an option for a com port assignment in the bluetooth manager should not be overlooked in addition.
Vote: 
Vote up!
Vote down!

Points: 0

You voted ‘up’


Juan Luis Navarro
Option 1 is my vote. That's

Option 1 is my vote. That's what the partner has been asking for in the past beta project.

Regards,

Vote: 
Vote up!
Vote down!

Points: 0

You voted ‘up’


Philippe Piemont
Hi Juliet, Having the

Hi Juliet,

Having the Bluetooth explorer has for me 3 interests:

- as a presales being able to demonstrate the BT via the "generic" BT explorer is a quick win (I saw that yesterday night in a warehouse).

- The BT explorer is a de facto standard and everybody expect to find this functionnality in the current products. Not having that makes the WT 40X0 different (difficult??).

- Being able to associate in a simple way a BT device (printer, ...) to a WT40X0 makes life easier for the people that use that product in production.

Hope that helps.

Philippe

Vote: 
Vote up!
Vote down!

Points: 0

You voted ‘up’


Joseph Fydrych
option #1.  It's best to take

option #1.  It's best to take end users out of options. 
Vote: 
Vote up!
Vote down!

Points: 0

You voted ‘up’


Kjell Lloyd
Option 2 my vote... A tool

Option 2 my vote...

A tool that is easy to use for connecting to a BT scanner or a BT Headset for voice picking.

Vote: 
Vote up!
Vote down!

Points: 0

You voted ‘up’


Horst Anderlohr
I vote for option one. We

I vote for option one. We need to have a BT Explorer for testing and we need to have an API using this for software development. A user should not operate the BT Explorer. The functionality should be integrated into the application software.

!!! It would help to have the API´s for .NET and a released C++ API on hand !!!

Vote: 
Vote up!
Vote down!

Points: 0

You voted ‘up’


Hector Meza
 Juliet, due to the specific

 Juliet, due to the specific nature of the wearable and the limited user interface, I feel it would be sufficient to provide a tool for developers.  Applications that require a BT connection to devices such as printers should be controlled by the application interface and be made user friendly.  I would not see a lot of demand for AdHoc BT connections with this device.

HM

Hector Meza

Sr. Systems Engineer

Vote: 
Vote up!
Vote down!

Points: 0

You voted ‘up’


Peter Arcuri
Virtual com port must be

Virtual com port must be available particularly for the BT enabled ring scanner. Simplifying the process of bonding and pairing is critical expecially for TN application. If we're to release an initial feature, I'd would go with option 2. The full feature set of option 1 is also a must, but could be supported later via the SMDK.
Vote: 
Vote up!
Vote down!

Points: 0

You voted ‘up’


Mark Mann
Juliet, I believe some

Juliet,

I believe some customers would like to have a tool that is user friendly and very simple that would allow them to have the user's pair devices when needed (head sets, printers or scanners). 

 

Mark

Vote: 
Vote up!
Vote down!

Points: 0

You voted ‘up’


Keith Larkin
Option 1 - The majority of

Option 1 - The majority of requests that we have seen in the past for bluetooth functionality has been in the form of APIs. I would think this would be consistent moving onto this new platform as well.
Vote: 
Vote up!
Vote down!

Points: 0

You voted ‘up’


Anonymous (not verified)
Option 2 - at least we need

Option 2 - at least we need simple and user friendly tools for pairing/bonding/COM-port mapping.
Vote: 
Vote up!
Vote down!

Points: 0

You voted ‘up’


Meredith Davison
I have a need today to allow

I have a need today to allow a bluetooth 2D scanner to pair to the WT40x0. That does not mean the end user needs the ability to do this (in fact, I would think this would be an exception), but at least the sw developer or those supporting the device need to have a way to easily pair. I'll assume this is BT Explorer, so I guess Option 1 fits this requirement.

MD

Vote: 
Vote up!
Vote down!

Points: 0

You voted ‘up’


Neville Harty
Option 1 - for all the same

Option 1 - for all the same reasons mentioned by the other respondents.
Vote: 
Vote up!
Vote down!

Points: 0

You voted ‘up’


Afshin Mansoorieh
The wearable has a higher

The wearable has a higher likelihood of being used for voice picking than other terminals. It is conceivable that users would want to use BT headsets.

If option 1 would allow partners like VoxWare or Vocalect, to adapt their application for use with BT head-sets, then it should be sufficient => Option-1
Vote: 
Vote up!
Vote down!

Points: 0

You voted ‘up’


Dimitri Zantidis
Hi, I also think option one

Hi,


I also think option one should have priority, considering the current limitation in developing a fully functional BT Explorer.


Most of the ISVs will be able to abstract some of the underlining complexity, at least as a temporary fix.
However, we should not compromise in providing fully functional samples on several types of bluetooth connections to the developers.  I had some involvement is some testing of the Beta version of the Bluetooth SDK and partners complaint we did not provide help on how to set up the environment and make the tests run successfully.


Regards,
Dimitri Zantidis

Vote: 
Vote up!
Vote down!

Points: 0

You voted ‘up’


Log in to post comments