BlueSMiRF bluetooth change baud problem

[Admin]

I am using SparkFun's BlueSMiRF and having problems changing baud.

I can get a perfect working connection at the default baud, 9600. So I can send data no problem at 9600 using my ATmega168. However, I want to increase baud to 38400.

Reading the manual on changing baud, it says send two commands:

Code: [Select]

rprintf("+++\r");//go to command mode
delay_cycles(3 seconds);//wait for an 'OK', but Im too lazy so I wait
rprintf("ATSW20,157,0,0,0\r");//157 for 38400bps, 39 for 9600bps
delay_cycles(3 seconds);//wait for an 'OK', but Im too lazy so I wait

Running my hyperterminal at 9600bps, I see those command outputs, sort of:
ÓlÓ×+++
ATSW20,157,0,0,0

I have no idea where those random ÓlÓ× characters come from . . . but its consistent. After all commands go through, the baud never changes and my mcu still passes data at 9600bps.


But the mystery deepens!
Looking at this page:
http://www.lynxmotion.com/images/html/build117.htm
It gives a slightly different set of commands on step 11 and 12, with three commands:

Code: [Select]

rprintf("+++\r");//go to command mode
delay_cycles(3 seconds);//wait for an 'OK', but Im too lazy so I wait
rprintf("AT\r");
delay_cycles(3 seconds);//wait for an 'OK', but Im too lazy so I wait
rprintf("ATSW20,157,0,0,0\r");//157 for 38400bps, 39 for 9600bps
delay_cycles(3 seconds);//wait for an 'OK', but Im too lazy so I wait

Anyone with ideas?

[dunk]

i've no idea where you are picking up the "ÓlÓ×" part.
have you tried sending a newline character before you enter command mode?
something like printf("\r+++\r").

i can explain your 2nd query though.
your modules appear to be using a subset of the Hayes command set.
http://en.wikipedia.org/wiki/Hayes_command_set
the "AT" command is just a query command to make sure you are in command mode. the device you send an "AT" to should reply with an "OK".
so in your 2nd code snippet, the extra AT command should make no difference.

dunk.

[reSpawn]

have you changed the atmega's baud too?

[paulstreats]

maybe you need to send the ascii characters for newline / return carriage - I think its something like 0x0a 0x0d
Hyperterminal and notepad understand \r \n but the bluesmirf might not.
dont forget to disconnect the blue smirf and restart it so it can re-initialise at the new baud rate

[Admin]

Still no luck . . .

have you tried sending a newline character before you enter command mode?
something like printf("\r+++\r").

No matter what I send, I still get some random characters, although now its being less consistent.

Playing around with it a bit, I have a theory on the random characters. They only appear the first time I send something out of my UART after a restart. I assume there is some buffer not cleared on initialization or something . . . I'm going to assume it is harmless . . .

maybe you need to send the ascii characters for newline / return carriage - I think its something like 0x0a 0x0d
Hyperterminal and notepad understand \r \n but the bluesmirf might not.

I looked it up, Carriage Return (ascii 0x0d) and Line Feed (ascii 0x0a).
I tried this:

Code: [Select]

rprintf("+++0x0d");and all it would do is print out "+++0x0d"

have you changed the atmega's baud too?

I get good data at 9600, and the data goes random if I change the ATmega baud to anything else . . . makes sense cause the bluesmirf is still 9600.

dont forget to disconnect the blue smirf and restart it so it can re-initialise at the new baud rate

It doesn't need a restart (I tried anyway, just in case). The baud should change immediately, and I even have the option to make it permanent or have it revert back after a power cycling.


So I tried a few more things typing text into hyperterminal. I sent 'AT' and pushed enter, but nothing happened. Then I pushed '+++' and enter and it immediately replied back as 'OK' (so something is working!). Then I tried the change baud command 'ATSW20,157,0,0,0' but the baud remained at 9600.


I just went through 4 pages of bluetooth related posts on the sparkfun site, with no luck:
http://forum.sparkfun.com/search.php?search_id=938964971&start=0
(some people seemed to have the same problem, but not sure, and no solution was given)

[DomoArigato]

Have you checked the error at those baud rates?  Maybe the error is too high.  There is error from both the AtMega and I think the bluesmirfas well.

[Admin]

Have you checked the error at those baud rates?

Yeap, this is why I chose 38400bps baud. At 38400, its .2% for the ATmega168 and -.18% for the BlueSMiRF. The baud just wont change from 9600bps . . .

I have a few more ideas I'll try out tonight when the batteries recharge . . . but I'm hopping on my last leg . . .

[paulstreats]

It seems that the text you are sending isnt working, but the symbols are (like "+++" works but "AT" doesnt) maybe you need to try sending the text characters as lower case like "at" instead of "AT", the different casing has different hex values. The example on the website you showed earlier looks like it is maybe using a terminal that uses uppercase only (but maybe transmits lower case)

[DomoArigato]

There are two versions of the bluesmirf, maybe you have the mitsumi one and you are using instructions for the new version?

[Admin]

Ok I got it to work . . .

Apparently you must send '+++\r' first before sending 'AT' or 'at' to get the 'OK'

Also, strangely, the BlueSMiRF appears to understand all baud rates . . . like I configure it to 57600, yet it can still recieve and send commands through hyperterminal that is set up at 9600. Apparently it was working all this time but I thought it wasn't because it understood my 9600 commands . . .

I realized this when I sent it the 'ATSI,8\r' command which has it return the baud rate to me.


Next step, wireless bootloading . . .