Re: Serial over Blue Tooth
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.
Re: Serial over Blue Tooth
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).
Re: Serial over Blue Tooth
Sorry, autocorrect. :-0
Can you setup your terminal program to receive in hex and capture the repeating string as received?
Re: Serial over Blue Tooth
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
Re: Serial over Blue Tooth
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/u...etooth-module/
Re: Serial over Blue Tooth
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
Re: Serial over Blue Tooth
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 .
Code:
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.
Code:
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)
Code:
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