Now that there’s limited success in getting the built-in (4.2) drivers to work with a Spider board and the BT module, I find myself wondering where I can learn more about what’s really happening.
I see the state of the module move around prior to a connect. Then I see data being received that seems to relate to state changes.
Where can I find out what those really mean and what’s happening?
The good place to start would be the source code of the module at codeplex:
http://gadgeteer.codeplex.com/SourceControl/changeset/view/24955#256555
Thanks for the pointer - it explains a few things.
I wonder why the data received call back occasionally has strings like “+BTSTATE:4” in it (and generally, only upon making a connection.
Additionally, I wonder why every time I reconnect (not re-pair) to a windows PC I get asked for the pin code.
any ideas or pointers?
These BT modules aren’t great, they expose an AT command set (old-timers like me will remember that from modems) and there’s not an extensive amount of documentation on the process flow and comms flow needed. The +BTSTATE:4 message is a state message that the driver should have swallowed, if it was expecting a state message (but obviously it isn’t at that time; perhaps that’s the driver, perhaps that’s your code).
The Windows BT drivers will most likely not cause a connection to a BT device unless there’s a reason to - so unless there’s an active app communicating to the port the BT connection is giving, the connection won’t occur. If you look at Eduard Velloso’s code for a PC app you’ll see it has the BT PIN embedded; you can get the same situation to occur if you test out all combinations with your code (my app doesn’t need a PIN - see my codeshare post)