Serial over Blue Tooth

[Scampy]

I'm updating a project that currently uses standard serial port to communicate to an application on the PC. I actually use a USB to serial FTDI breakout board to make connectivity more straight forward as modern PC's seldom come with RS232 serial ports these days. However as part of my "revamp" I want to replace this connection with a blue tooth option, and have purchased a couple og the HC-06 modules with back board attached and a decent Belkin BT dongle.

Rather than swap out the USB board and then hope for the best that it works and is a direct replacement I thought I would do some simple testing.



ASM

__CONFIG _CONFIG1H, _OSC_HSPLL_1H
__CONFIG _CONFIG2L, _PWRT_ON_2L
__CONFIG _CONFIG2H, _WDT_ON_2H & _WDTPS_512_2H
__CONFIG _CONFIG3H, _PBADEN_OFF_3H
__CONFIG _CONFIG4L, _LVP_OFF_4L & _XINST_OFF_4L

ENDASM

DEFINE OSC 40
ADCON1 = $0F
clear

;----[Hardware USART defines]---------------------------------------------------

DEFINE HSER_RCSTA 90h ' Enable serial port & continuous receive
DEFINE HSER_TXSTA 24h ' Enable transmit, BRGH = 1
DEFINE HSER_CLROERR 1 ' Clear overflow automatically
DEFINE HSER_SPBRG 86 ' 115200 Baud @ SPBRGH = 0
BAUDCON.3 = 1 ' Enable 16 bit baudrate generator

RCSTA = $90 ' Enable serial port & continuous receive
TXSTA = $24 ' Enable transmit, BRGH = 1
SPBRG = 86 ' 115200 Baud @ -0.22%
SPBRGH = 0
BAUDCON.3 = 1 ' Enable 16 bit baudrate generator


main:
HSEROUT ["Hello"]
Pause 1000
goto main


Nothing taxing, just a simple "hello world" example. Compiled and loaded the code to the PIC (18f4580) - and tetsed using the existing USB and a windows terminal program... sure enough "Hello" was repeatedly displayed line by line with 1 second intervals. OK over the the BT device. Installed the drivers, and then searched and found the HC-06, connected and paired successfully. Opened the windows terminal program and selected the com port and settings - I get a listing, but it's just a 1 in the ascii dump and FB in the hex window.

I know i've got the correct port as I can remove the connection wire between the PIC and the HC-06 and it stops scrolling. This would also suggest that data of some kind is being sent wireless over the dongle.. but why does it not display "hello" in the ascii dump

[Tabsoft]

Swampy,

Isn't the default baud rate for the HC-06 9600?

If so, try setting the HSER port baud rate on the PIC in PBP to 9600.

[Scampy]

Swampy ??? SWampy !! - actually I quite like that for a user name :)

Doh ! Re-compiled with settings for 9600 (need more sleep !!), didn't get "Hello", looks more like Klingon but had more bytes (80,98,9E,E0,FE,9E was the most common).

[Tabsoft]

Sorry, autocorrect. :-0

Can you setup your terminal program to receive in hex and capture the repeating string as received?

[Tabsoft]

For the 18F4580 @ 40MHz you have several options for 9600. I would try option 1 with the best %error rate.

1. Synch = 0, BRGH = 0, BRG16 = 1, SPBRG = 1040 (dec) 0.06% error rate

2. Synch = 0, BRGH = 0, BRG16 = 0, SPBRG = 64 (dec) 0.16% error rate

3. Synch = 0, BRGH = 1, BRG16 = 0, SPBRG = 25 (dec) 0.16% error rate

4. Synch = 0, BRGH = 0, BRG16 = 1, SPBRG = 259 (dec) 0.16% error rate

[xpa999]

Remember the hc-06 is a 3.3v device, so the pic has to be 3.3v or you need to convert levels.

I found this website for some great info

http://mcuoneclipse.com/2013/06/19/using-the-hc-06-bluetooth-module/

[ardhuru]

Here's an easy way to test your HC-06, and the comms with the host/client. Just short its Tx and Rx, power it up (3.3 or 5, depending on whether you have the bare version or the one on a backpane).

Anything you type on your terminal should echo back whatever you type. A simple test, no pic involved, no baud rate issues.

Incidentally, you could also test on an Android, instead of a Windows machine. There's a beautiful terminal emulator called Blueterm on the playstore.

Regards,

Anand

[Scampy]

Thanks guys for the inputs.

I remember that I was playing with the AT commands and seems I set the baud rate to 38400 !! - I went through the process of changing baud rates in the windows driver and the software until it responded to the AT prompts with an OK. I then re-compiled the test code with the hardware settings for 38400 and once loaded connected via the terminal program --- bingo, or should that be "hello" :)

I then changed the serial defines in my main code and have the PIC responding over BT when using the terminal program, IR send Q for queries and all the date for the current prob readings and setting are streamed to the PC. Only problem is that the PC app crashes and screws up the sub system so I need to restart the PC .



Error log timestamp Monday 29/06/15 19:03:38

Runtime error: Element not found.

Error(Exception)>>defaultAction
Error(Exception)>>activateHandler: <anUndefinedObject>
Error(Exception)>>handle
Error(Exception)>>signal
Error class(Exception class)>>signal: <'Element not found.'>
BasicRunProgram(Object)>>error: <'Element not found.'>
BasicRunProgram(BasicProgram)>>terminateRun: <anError>
[] in BasicProgram>>errorHandlerBlock
ExceptionHandler>>evaluateResponseBlock: <aBlockClosure> for: <anError>
[] in ExceptionHandler>>handle:
ProtectedFrameMarker(BlockClosure)>>setUnwind: <aBlockClosure>
BlockClosure>>invisibleEnsure: <aBlockClosure>
ExceptionHandler>>handle: <anError>
ExceptionHandler>>findHandler: <anError>
Error(Exception)>>activateHandler: <anExceptionHandler>
Error(Exception)>>handle
Error(Exception)>>signal
Error class(Exception class)>>signal: <'Element not found.'>
BasicRunProgram(Object)>>error: <'Element not found.'>
BasicRunProgram(BasicProgram)>>runError: <'Element not found.'>
BasicRunProgram(BasicProgram)>>handleComError: <'Element not found.'>
SerialDevice32(SerialDevice)>>error: <'Element not found.'>
SerialDevice32>>openError: <1168>
SerialDevice32>>openError
SerialDevice32>>open
SerialDevice32(SerialDevice)>>open: <'COM4'>
BasicCommStream>>from: <'COM4:115200,n,8,1,ds...'> mode: <'RANDOM'> handle: <'#1'>
BasicRandomFile class(BasicFile class)>>from: <'COM4:115200,n,8,1,ds...'> mode: <'RANDOM'> handle: <'#1'> owner: <aBasicRunProgram> length: <128>
[] in OpenCommand>>using:
[] in BasicRunProgram>>begin
ExceptionHandler>>evaluateProtectedBlock: <aBlockClosure>
[] in ExceptionHandler>>activateDuring:
ProtectedFrameMarker(BlockClosure)>>setUnwind: <aBlockClosure>
BlockClosure>>invisibleEnsure: <aBlockClosure>
ExceptionHandler>>activateDuring: <aBlockClosure>
ExceptionHandler class>>handle: <anError class> with: <aBlockClosure> during: <aBlockClosure>
BlockClosure>>on: <anError class> do: <aBlockClosure>
BasicRunProgram>>begin
BasicRunProgram(BasicProgram)>>gotoAndIfStoppedBegin: <'[IoWait]'>
BasicRunProgram(BasicProgram)>>handlerName: <'[IoWait]'> evaluate: <aBlockClosure> callParameters: <anOrderedCollection>
BasicRunProgram>>handlerName: <'[IoWait]'> evaluate: <aBlockClosure> callParameters: <anOrderedCollection>
BasicRunProgram(BasicProgram)>>submitHandlerName: <'[IoWait]'> evaluate: <aBlockClosure> callParameters: <anOrderedCollection>
BasicRunProgram(BasicProgram)>>submitHandlerName: <'[IoWait]'> callParameters: <anOrderedCollection>
TimerTopPane>>wmTimer: <333598> with: <0>
TimerTopPane(Object)>>perform: <#wmTimer:with:> with: <333598> with: <0>
NotificationManager>>notify: <aWinMessage>
NotificationManager>>notifyRecursive
NotificationManager>>recursiveMessage
SystemDictionary>>recursiveMessage
SystemDictionary>>launch


The error message is stated above, and there are references to 115200 baud, but I've tried running the application from within the KDE and it still errors. My guessing is that it's something to do with the port handling in Liberty Basic as it works fine with real RS232 connection and when I use a couple of FTDI USB to serial boards, being direct connections. Although the BT dongle produces a virtual com port and this is detected by the initial windows that scans for open ports, it fails to detect the controller (sends out "C" and expects "R" in return) and then crashes and has to be end tasked. At this point the BT pairing drops and wont re-connect and the PC has to be re-booted with both dongles powered down at the time.



FOR TempWD = 0 TO 1000
IF RCIF=1 THEN GOSUB coms ; Check to see id PC application connected
PAUSE 1
NEXT TempWD


This section above checks the buffer to see if something is deposited into it (so I was told)



coms:

HSERIN [nTest]
SELECT CASE nTest
CASE "C" ; if C then application checking for controller
goto respond
CASE "Q" ; if Q then send data to PC
Goto Term_TX
CASE "S" ; if S then receive data from PC
goto Term_RX
return

respond:
Hserout ["R"]
goto main


then the coms section responds, and initially sends data to the PC and then waits for the next "Q"ueriy or receipt of updated data "S"ent from the PC application.

http://www.micro-heli.co.uk/newapp.png