Future plans for moving from SS1 to MS BT stack?

Abaco Inc. said to a customer that our MC70 has issues due to BT Stack and their software works perfect under MS stack.
While issues are being driven by support and Eng. customer still "wants to know" if we can support MS BT Stack or if we have plans to move to MS.
Do we have any official position that can be informed to customer.
Regards,
DIANA Melick
Gustavo: I'm attaching what I

Gustavo: I'm attaching what I received from Jim Fuccello a good while ago. I have nothing more updated since, maybe somebody else does. Hope this helps. Diana (Melick)
Vote: 
Vote up!
Vote down!

Points: 0

You voted ‘up’


Jim Fuccello
    Our strategty is to

    Our strategty is to provide both the Stonestreet One and Microsoft Bluetooth stacks (manually selectable around boot time) in MPA 1.5-based products in a maintenance release (I do not have dates.  It would be best to contact PM's).  MPA 2.0 shall also include both stacks from the beginning.
    I am concerned about the partner saying what they did to the customer.  It may require some firefighting, and a discussion with the partner.  Be that as it may Stonestreet One provides the best support I have ever seen in Bluetooth stacks (including Microsoft).  If there is a SPR associated with this I am sure it will get resolved in a timely manner.  If there is not an SPR then I suggest you open one immediately.  Let me know how it turns-out.

Jim
Vote: 
Vote up!
Vote down!

Points: 0

You voted ‘up’


Richard Linsley-Hood
The main problem with the

The main problem with the Stonestreet stack is that it uses a vast amount of Virtual Memory - in excess of 1.5Mb on most platforms even when nearly turned off completely - just serial IO. This is addition to the built in (and unused) Microsoft stack which is always present. This VM issue has been the cause of a large number of problems with all our terminals goin into premature 'dll crunch'.

Can we be sure that by including both stacks, if one of them is NOT used, it will then have a zero memory footprint or are we going to get the worst of all worlds?

This memory effect will always be critical until we get to CE6/WM7 based OSs.
Vote: 
Vote up!
Vote down!

Points: 1

You voted ‘up’


Jim Fuccello
I would like to clear up some

I would like to clear up some things in the last post:

1.  The Stonestreet stack memory footprint is configurable so that unneeded DLL's are not loaded.  This can be achieved using Start->Programs->BTProfileSelector.
2.  The Microsoft stack is not currently present or loaded in any of our MPA 1.5-based terminals.  Therefore it does not contribute to DLL crunch.
3.  Future terminals that include both stacks will not load components from the unused stack.  There may be some exceptions, but nothing significant.

Jim
Vote: 
Vote up!
Vote down!

Points: 0

You voted ‘up’


Anonymous (not verified)
Thanks Jim, case #1648297 is

Thanks Jim, case #1648297 is what I'm talking about. It does not qualify for an SPR by now. We are constantly updating customer, and he asked the  question about supporting MS BT stack in the MC7090. I understand it's TNT and not MPA 1.5 nor 2.0, so answer is no MS planned for MC7090. I'm I correct?
Vote: 
Vote up!
Vote down!

Points: 1

You voted ‘up’


Richard Linsley-Hood
1). The 1.5Mb footprint is

1). The 1.5Mb footprint is what is left AFTER disabling all that it is possible to disable. This is significant at the times where even a small dll load is important.
2). AFAIK all/most of the Microsoft stack (with the exception of the HCI low level hardware driver which is all we are missing) IS loaded as it is part of the standard Winsock dll.
3). I look forward to this new upgrade.

Why cannot we just create the low level HCI hardware driver so that we can use the Microsoft stack on our existing terminals?
Vote: 
Vote up!
Vote down!

Points: 1

You voted ‘up’


Don Khan
Gustavo,               If all

Gustavo,
              If all goes well we may see the MS stack included at revision B of the MPA 1.5 (MC75, MC55) platform.  No date has been given for the Rev B.  Initially entertained for MPA 2.0; however, I have been pushing to have the MS stack offering at MPA 1.5.

This is un-official, thus, I suggest that you consider the response from tthe respective business unit.
Vote: 
Vote up!
Vote down!

Points: 0

You voted ‘up’


Ashar Mairaj
Can you give detail of the

Can you give detail of the problem seen by Abco? If the problem is being looked at by the engineering and or support, is there a reference number. I will make sure that something similar gets tested during validation cycle.
Thank you
Ashar
Vote: 
Vote up!
Vote down!

Points: 0

You voted ‘up’


Ashar Mairaj
Can you give detail of the

Can you give detail of the problem seen by Abco? If the problem is being looked at by the engineering and or support, is there a reference number. I will make sure that something similar gets tested during validation cycle.
Thank you
Ashar
Vote: 
Vote up!
Vote down!

Points: 0

You voted ‘up’


Khazi-Syed Tahe...
1) When BTE is enabled with

1) When BTE is enabled with all the profiles loaded, the memory consumed by BTE is 0.8 MB.
2) The user has the option to disable the profiles they don’t use via Profile selector application present in the Start->programs folder to save memory.
3) Regarding MS BT stack files, it is just not the HCI lower lever driver that is excluded form the image but also the core key components s like OBEX, SDP,RFCOMM, L2CAP, HCI, HCI transport layer…. are all excluded from the image.
4) When we have dual Bluetooth stacks (MS and SS) in the next generation terminals, and if MS is loaded we have verified that the memory consumed by the SS stack is zero although the SS Dlls are present in the file system.
5) Keep your fingers crossed and stay tuned.
Vote: 
Vote up!
Vote down!

Points: 0

You voted ‘up’


Richard Linsley-Hood
On an MC7094 running 4.39.3,

On an MC7094 running 4.39.3, with all the profiles except serial disabled as recomended, I get the following loaded by the Bluetooth stack.


btexplorer.exe
 0x0103    44Kb  ss1btbti.dll
 0x0104    44Kb  hcicomm.dll
 0x0105    36Kb  ss1vmod.dll
 0x0106    36Kb  ss1mod.dll
 0x0107    40Kb  ss1btmod.dll
 0x0108    36Kb  ss1vndis.dll
 0x0109    52Kb  ss1btpan.dll
 0x010A    48Kb  ss1btobp.dll
 0x010B    60Kb  ss1btsnc.dll
 0x010C    40Kb  btsyncsvr.dll
 0x010D    56Kb  ss1btftp.dll
 0x010E    68Kb  ss1bthfr.dll
 0x0110    92Kb  customerdll.dll
 0x0113    64Kb  ss1bthandsfree.dll
 0x0118   304Kb  ss1btps.dll
 0x0120    36Kb  ss1vcom.dll
 0x0121    36Kb  ss1com.dll
 0x0122    40Kb  ss1btcom.dl
 0x0123    44Kb  hcidrv.dll
 0x012D    40Kb  audexapi.dll


 This in total comes to 1.2Mb of dlls on disk. The total space occupied by these dlls in applications VM is 1.4Mb because each dll space is rounded up to the next 64Kb boundary. Thus 44Kb and 36Kb dlls all occupy 64Kb VM.

I do not know how you got the 0.8Mb that you quote but it is noe one I can understand.

To compare this to other things - this 1.4Mb of VM space for Bluetooth is larger than either the whole of Compact Framework 2.0 of the whole of SQL server Compact edition! To talk to a printer via Bluetooth is more memory hungry that to have a whole database in use!

Richard LH

Vote: 
Vote up!
Vote down!

Points: 0

You voted ‘up’


Khazi-Syed Tahe...
Richard, When BTE is

Richard,



When BTE is enabled with no profiles except for SPP, DLL space consumed is 2.3125 MB. When rests of the profiles were enabled and loaded then DLL space consumed is 3.1875 MB. So 0.8 Mb was the delta I was referring.



Thanks for your input. We will try optimize the memory being consumed by the BTE.


Vote: 
Vote up!
Vote down!

Points: 0

You voted ‘up’


Anonymous (not verified)
Thanks everybody for the

Thanks everybody for the feedback provided.
My crucial question was answered. MC7090 will have nothing but SS1.

I think a new discussion was triggered about the memory and perhaps it worth a full new thred as to be followed.

Regards,
Gustavo,
Vote: 
Vote up!
Vote down!

Points: 0

You voted ‘up’


Log in to post comments