I have had a look about the forums but am still not quite sorted out, I am using WM5. I have a bluetooth printer with no pass key so i am enabling the serial port using dev.SetServiceState(BluetoothService.SerialPort, true); I am then able to get a virtual port and use this with FieldSoftware PrinterCE.NET. It all works well.

The only problem is I cannot print to this com port without enabling the service again. To get round this I added the registry setting for \\SOFTWARE\\Microsoft\\Bluetooth\\Serial\\Ports and added the device in here. Now throught bluetooth manager I can see the device and the serial port looks setup but if the device is restarted even these settings are still there but i still have to create the virtual serial port in code again.

Also if i go into the device properties the serial port service is not checked (it isnt showing until i hit refresh services). Could this be the channel number being set to 1? If i manually pair the device this is a different number. I have been trying to get the channel number using dev.GetServiceRecords(BluetoothService.SerialPort), this has a Debug.Assert failure when parsing the service record - ReadElementUInt16(). I have stepped thorugh the code and the ElementTypeDescriptor (etd) is of type ElementSequence-length 45 and it is expecting an UnsignedInteger or TwosComplementInteger of length 2!!  I can get the unparsed service record but i dont have a clue how to interpret it.

Does anyone know how i can get the channel number from the unparsed service record, and will this enable the com port to be used without setting up the virtual serial port each time?

thanks in advance, ac
 

I don't know much about CE/WindowsMobile etc, so unfortunately I can't really help with that part.  I don't know what's stored in the registry, maybe its the numerical RFCOMM Channel Number, and when the peer device reboots it assigns a new value.  Don't know whether the registry can do a lookup by UUID or ServiceName etc?

I can (should!) look at the SDP Parsing issue.  Let me see the raw record and I'll see whether it is malformed or my parser is wrong.  Either post it here or in a new workitem at http://www.codeplex.com/32feet/WorkItem/AdvancedList.aspx

Thanks for you reply, here is the service record byte [], hope this is what you are looking for:

    [0]: 54     [1]: 0     [2]: 48     [3]: 54    [4]: 0    [5]: 45    : 9    [7]: 0    : 0    [9]: 10    [10]: 0
    [11]: 1    [12]: 0    [13]: 0    [14]: 9    [15]: 0    [16]: 1    [17]: 53    [18]: 3    [19]: 25    [20]: 17
    [21]: 1    [22]: 9    [23]: 0    [24]: 4    [25]: 53    [26]: 12    [27]: 53    [28]: 3    [29]: 25    [30]: 1
    [31]: 0    [32]: 53    [33]: 5    [34]: 25    [35]: 0    [36]: 3    [37]: 8    [38]: 1    [39]: 9    [40]: 1
    [41]: 0    [42]: 37    [43]: 7    [44]: 80    [45]: 82    [46]: 73    [47]: 78    [48]: 84    [49]: 69    [50]: 82

Thanks again, ac

That's a baaaad record.  They have twice wrapped the record in a sequence element rather than once, so the first three bytes are garbage.  If you remove them it works fine:

AttrId: 0x0000 -- ServiceRecordHandle
UInt32: 0x10000

AttrId: 0x0001 -- ServiceClassIdList
ElementSequence
    Uuid16: 0x1101 -- SerialPort

AttrId: 0x0004 -- ProtocolDescriptorList
ElementSequence
    ElementSequence
        Uuid16: 0x100 -- L2CapProtocol
    ElementSequence
        Uuid16: 0x3 -- RFCommProtocol
        UInt8: 0x1
( ( L2Cap ), ( Rfcomm, ChannelNumber=1 ) )

AttrId: 0x0100
TextString (guessing UTF-8): 'PRINTER'

Kudos to them though for finding the one place I don't double check that the element type is as expected.  I've put a fix in so we detect the error rather then fail with an IOOBEx. 

The fault is more apparent when the record is displayed like this:

0x36, 0x00, 0x30,
0x36, 0x00, 0x2D, 0x09, 0x00,  0x00, 0x0A, 0x00, 0x01, 0x00, 0x00, 0x09, 0x00, 0x01, 0x35, 0x03,
0x19, 0x11, 0x01, 0x09, 0x00,  0x04, 0x35, 0x0C, 0x35, 0x03, 0x19, 0x01, 0x00, 0x35, 0x05, 0x19,
0x00, 0x03, 0x08, 0x01, 0x09,  0x01, 0x00, 0x25, 0x07, 0x50, 0x52, 0x49, 0x4E, 0x54, 0x45, 0x52

Note that the first three bytes are a duplication of the next three (with the length value of course changed from 45 to 48, ie 0x2D to 0x30)

Thanks for looking at this, so will your fix mean that it handles a bad service record like this or is there a way i can detect a bad record myself so that it is reusable with different printers?

 

The fix I made now was just to detect the bad format and thus throw a ProtocolViolationException rather than just fail subsequently with an IOOBEx.  I hadn't intended to try to detect any malformed records and attempt to work out what was intended.  Hopefully this is the only device that has such a bad record, so probably best if you can handle it in your app.  Presumably the record byte array is just hard coded with the channel byte written in, so detect that form.  I'll have a look at the spec and see whether there's any allowance for such a form anyway.  What device is it btw for future reference.

 The device is a pentax pocketjet 3 printer, thanks for having a look at this, would never have figured this out otherwise!

So does this mean you've got a working solution?  Its just occurred to ask whether you looked at the BluetoothSerialPort class (http://inthehand.com/library/html/T_InTheHand_Net_Ports_BluetoothSerialPort.htm)?

Well its nearly a working solution. What I am trying to do is allow users to print from my mobile app, the first time they print or if they change printer I provide them a list of found devices, they select printer, give a pass key and thats should be it finished with for the user.

I set the device service state  (dev.SetServiceState(BluetoothService.SerialPort, true);), then create bluetooth serial port from this (BluetoothSerialPort port = BluetoothSerialPort.CreateClient(new BluetoothEndPoint(BTAddress, BluetoothService.SerialPort));). I use this port returned from this to print to.

I was trying to store this information in the registry so that if the user looked in the bluetooth manager everything appeared as though it was manually paired. Also if the device had a serial port setup manually then i could use it, otherwise create a virtual one.(thought maybe if a serial port was manually setup there would have been a way of getting this instead of creating another virtual port?) Not sure how to do this might just have to read the registry. I will leave it at creating a virtual one for now.

 I dont need to parse the service record afterall.
 

Glad to hear its being successful.

Can you do me a favour.  As you've the source downloaded and have been looking at SDP records. :-)  I'm wondering whether the record format discussed above is applied by the Bluetooth stack locally and not by the peer device!  (IIRC the SDP protocol transfers attribute pairs and not the complete record).

Unfortunately I've no PPC device using the MSFT stack to test on.  Can you test for me there, against various devices and see what record formats you get back.  For instance use the SdpBrowserPPC sample, discover devices, then do Query->All_Services for each.  Ideally discover Windows desktop as I know what records are returned by it -- ideally run "Bluetooth File Transfer Wizard" in server mode on it when doing so.