April 28th, 2013
… well, here we go again … just like with the necessary bt module powercycle …
before we go into details we would like to provide a few links and documents we have gathered related to the documentation and datasheets of these bt modules … 3 days of work …
one of the 1st useful links was http://byron76.blogspot.com/
a link to one of the manufacturers of these module in china http://www.bolutek.com/
here is a pretty comprehensive datasheet outlining the differences of slave vs master / slave module EGBT-045MS-046S Bluetooth Module Manual rev 1r0
the led assignment in the above doc show errors on the slave device, the 1st pict and pin description (pin 24) is right pict 2 and 3 are wrong (show pin 23).
as a summary for the software setup we can say again that power cycling the module after the unpairing (remove module with ms-bt-stack) in case of difficulties was a key to success … the bt module led just happily flashing along did not mean that it was still working and responding correctly to the os’s bluetooth driver.
please continue to read since everything is not as easy as it sounds and this article explains in details on how to do it and more important, what’s not working right now
the other part was the use of a terminal program (br@y++) which had problems receiving from the bt serial port driver … also the com port number limit of 10 lead us to change com port assignments, which seems not recommendable with virtual serial com ports on bluetooth (hangs the whole bt serial service search) … more testing is necessary
now, that we know the right paths and tools, we were able to link to the bt-module (after bt-module power cycle) almost blind folded even in xp32 sp3 with the ms-bt-stack running as a guest os in a vmware 7.16 implementation on a kubuntu natty host using a csr based usb to bt radio … a few days ago this was a big big deal
what can be said at this point is that the module works as far as we tested it until now pretty good, but the steps in the “Using Bluetooth Experiences” need to be observed
a few more words about the hardware aspect of the modules … plural, since the different firmware on them affects their behavior and the pinout assignment on the gpio pins
all we had connected was RxD TxD 3.3V and GND, plus 2 additional leds where only one seemed useful for the slave devices firmware.
also most docs found currently on the web talk about 2 firmware versions, one for the master / slave and one for the slave being linvor V1.6 … our units have linvor V1.8 … whatever this means ??? so far it acts like described in most slave based descriptions … asking for an update sheet (preferably in english) for the differences for it is probably like asking to visit the forbidden city in Beijing to have a quick coffee there
we need to now continue with a high speed setup at 57600 baud … more to follow …
well, here we go … set the baud rate to 57600 bd and the communication stopped, most likely due to the asymmetrical wave form caused by our optos at high speed.
the board seems non responsive with garbage on both ends after the terminals were set to 57600 bd … well … our fault … we set the baud rate on cutecom to 576000 by accident and it took the scope and a whole bunch of jumper wires to go around the optos on the opto serial to usb adapter to the RxD and TxD signals … then, with the scope, we found out that the set baud rate is 10 times the expected one … changed the settings to the correct 57600, removed the jumpers and plugged the bt module back the original way into the opto board and now everything seems happy again … i suppose that this is an everyday example how things can go wrong with not seeing the extra 0 (57600 vs 576000) on the dropdown choices …
below is a 1st draft of a base board schematic holding either the slave board or the master / slave version … keep in mind that only the loaded firmware is responsible for it’s gpio based utility pin functionality, like led assignments and m/s key input. please also it’s only an initial drawing, the layout has not been sent out for fabs yet.
we need to change the TPS73633 to a TPS73033 … less current capability which is not needed and less expensive, same footprint.
we use http://www.pcbexpress.com/ for our prototypes … so far reliable, affordable, reasonably fast … any other choices are more then welcome
after all these boring screw-ups and hardware details, we have finally some exciting xp32 bluetooth setup documentation …
a screenshot of the device manager shows the generic bluetooth radio device and the microsoft bluetooth enumerator … they will only show up if your internal bluetooth module is enabled (switched on) or an external usb to bluetooth radio is plugged in.
in case that theses two bluetooth items or two functionally similar items are not visible in the device manager it does not make sense to continue … it’s mandatory to have a bluetooth radio and enumerator present
the bluetooth hardware dialog also confirms the availability of the bluetooth radio and the bluetooth enumerator.
the bluetooth devices tab showing a blank devices dialog with no devices previously added , but we’re gonna change it
that’s the way the bluetooth options dialog should look like
also, since there is no com port device paired and selected, we can skip the empty com ports tab.
this “add bluetooth device wizzard: dialog opens after pushing the add button in the bluetooth device window. make sure your bt module is powered on (ready) and set the check box for it. pressing next will get the bluetooth device discovery process started
this dialog opens during the search, discovery process
and finally the bluetooth devices window shows up again with all devices currently available within bluetooth’s reach
pressing next will get the pairing and connect process started
select item 2 and enter the correct passkey. this will get the loading of the bluetooth serial service drivers started.
and finally the add bluetooth wizzard shows the completion of it’s installation process
now the bluetooth devices window shows all bluetooth paired devices.
the bluetooth com ports window shows success for the serial device pairing and service loading by indicating the, to the bt module, assigned outgoing and incoming com ports.
now, the sequence of the following 3 status messages in the bot right corner show the bluetooth serial com port driver installation process, one 3 step sequence for each com port.
this concludes the successful installation of the bt serial module in xp32.
the com port to use is the outgoing one with the ‘Dev B’ designation
follow the steps outlined in the win 7 terminal operation in “Using Bluetooth Experience Part 2″
by now we are almost able to do it blindfolded, but 3 days ago it looked very very depressing, trying and trying and the missing link was to powercycle the bt-module after unpairing it. we were fooled by the still proper serial communication responses (AT commands) and the success pairing all day long if necessary and the still innocently flashing led on the module indicating an assumed i’m bluetooth ready status, while the module was probably in a state of no longer properly responding to the bluetooth driver. it’s also possible that the driver left the module in a certain state and continued in a way the module did not understand and by doing so they got out of sync. is’t beyond the scope here to diagnose the why and how, as long as we know a way to handle and avoid the problem to begin with
… that’s it for now … we still need to solve the android issue with the samsung tablet not finding a matching serial port service / profile for it after a successful pairing operation …
thanks for your patience reading all this stuff … to us it was very very vital … how about to you ???
the previous parts can be found here Using Bluetooth Serial Port Experiences Part 2
and the very 1st part of this series at Using Bluetooth Serial Port Experiences Part 1
this might be of your interest as well Binary Data Packages and Bluetooth Serial Parts
thanks for reading out techie blog, the efiHacks engineering team