Setting up Blue SMiRF on a Mac

[joe61]

I love my Mac, but it can be really irritating some times. I can get it to say it's connected to my smirf, but the serial port it creates for it won't connect.

Anyone have a Mac who's had more success with it?

Thanks

Joe

[joe61]

Is there anything special about a connection to Blue SMiRF that requires Blue Soleil or some special software? I can connect to mine using a serial communication program, but I get no response to it. I've tried this on both Mac and Windows, each of which says the smirf is connected, and the serial program connects, but I get no response at all.

Thanks

Joe

[rbtying]

A BlueSMiRF acts like a serial cable. Unless you're accessing the internal utilities, it won't respond (and those aren't that easy to get to).  Try connecting the RX_I and TX_O pins together to make a loopback connection, and see if you can get any data.  Also, try a variety of different baud rates: it's supposed to be 115.2kBaud, but it may have accidentally been changed. 

[joe61]

A BlueSMiRF acts like a serial cable. Unless you're accessing the internal utilities, it won't respond (and those aren't that easy to get to).  Try connecting the RX_I and TX_O pins together to make a loopback connection, and see if you can get any data.  Also, try a variety of different baud rates: it's supposed to be 115.2kBaud, but it may have accidentally been changed. 

I can see what I type echoed back after doing that, but typing '+++' doesn't get me into command mode. It doesn't do anything but echo stuff back.

My part has RTS and CTS also brought out. Do I need to do something with them? Seems like I saw something about that, but can't find it now.

Thanks

Joe

[rbtying]

If you can see what you type echoed back to you, your BlueSMiRF is working (this is a good thing.)

If you don't have a device with hardware flow control attached to the BlueSMiRF, or you want to use software flow control, you need to bridge RTS and CTS (just solder a wire across). 

The inability to enter command mode is probably because of the flow control thing - fix that first.  Worst case, it's still quite usable without the command mode (I have yet to use command mode for anything, since my uC can handle 115.2kBaud serial).

[joe61]

If you can see what you type echoed back to you, your BlueSMiRF is working (this is a good thing.)

If you don't have a device with hardware flow control attached to the BlueSMiRF, or you want to use software flow control, you need to bridge RTS and CTS (just solder a wire across). 

The inability to enter command mode is probably because of the flow control thing - fix that first.  Worst case, it's still quite usable without the command mode (I have yet to use command mode for anything, since my uC can handle 115.2kBaud serial).

Bridging RTS and CTS didn't do it. However, setting the program on the MCU (a Baby Orangutan from Pololu) to use 115200 for the speed did. This is on Linux, Mac is pretty much useless for all things serial, and I never got it to work on Windows either. That's fine with me as linux is my preferred environment for this programming.

Next I have to try to get into command mode and change the MCU/SMiRF speed to something lower, still can't get into command mode.

Thanks for the input, I thought the default speed was 9600, switching to 115200 made the difference.

Joe

[rbtying]

Great to know that at least the basic functionality is working.  Also nice to find another linux programmer on these forums - it's my preferred working environment as well. 

If there's no particular reason to use a lower baud rate, it's my personal preference to leave it at 115200 baud, since the actual serial part is handled in hardware, and doesn't make a significant increase to the CPU load.  Higher speeds generally mean that the write/read calls block for shorter periods of time, and help with timing in general. 

[joe61]

If there's no particular reason to use a lower baud rate, it's my personal preference to leave it at 115200 baud, since the actual serial part is handled in hardware, and doesn't make a significant increase to the CPU load.  Higher speeds generally mean that the write/read calls block for shorter periods of time, and help with timing in general. 

Right now I'm just using it to drive a robot with a camera around. I just send characters like 'f' for forward, 'l' for left, etc. And all the baby-o does is adjust speed and driver the motors. So nothing much going on at this point.

My biggest problem now is that the connection keeps dropping between the smirf and my laptop. It takes a while to reconnect each time because I haven't figured out how to make the smirf reconnect by itself.  I have a pretty cheap dongle though. I probably will invest in a type 1 stick.

Thanks again

Joe