Main menu

Bluetooth Digital Setting Circles

This variation on my Digital Setting Circles project was created by Craig Combes. He provided the following content so others could recreate his version. Thanks, Craig!

Many people use Dave’s serial DSC board with a serial to Bluetooth adapter and that can get quite pricey, large and power hungry. So I adapted Dave’s design to skip the RS232 circuit and go straight to Bluetooth. In the process, I decided to change the PIC to a less expensive, and more recent chip: the 16F628A, which Dave had code for already. I made some minor tweaks to the code to eliminate some pull up resistors.

The new design uses a 5 volt regulator (to make sure the encoders are happy) and a 3.3 volt regulator to supply everything else (the Bluetooth module needs 3.3v). I used a MOSFET for polarity protection to reduce the input voltage requirement. I also replaced the oscillator module with a crystal to reduce cost and power consumption. The Bluetooth module is a surface mount device and the boards I created have 11 pads to solder for this device. Most of the other components (not the PIC) are surface mount also, but there aren’t many of them and their are only a few pins maximum per component to solder, so it’s not difficult.

The Bluetooth module is the RN-42 from Roving Networks, which only uses 30ma when transmitting, 3ma when “sniffing” and 26ua when sleeping. I have it configured to communicate at 9600 baud. For more info on the RN-42, you can go here:

D1 is the power on indicator LED. SW1 is the reset button for the RN-42 and the PIC. D2 is the status indicator light for the RN-42. D2 blinks until connected, then it stays on.

I do have boards made for this circuit and I will eventually make them available through FAR Circuits, like Dave’s original board. I am open to suggestions for improving the design/board. Just send me a note here.

29 thoughts on “Bluetooth Digital Setting Circles”

Will the hardware be able to handle that frequency of clicks. For a push-to telescope, I guess the max rate will be 1/4 revolutions per second = 16K per second. Considering two encoders, that would be net 32K per second.

Not only frequency, would the protocol support that man bits for reporting the current click-count?

For the client software I don’t worry much, because I will be writing my own software. Just as long as the protocol allows it.

Harshad, the max my circuit can handle 64K quadrature tics per revolution. If the gear ratio between the telescope axis and the encoder is 1:1, then that means that your encoder must not be more than 16K CPR (because 1 CPR = 4 quadrature tics). If the gear ratio is different than 1:1, adjust accordingly. The limit is due to the fact that the decoder box uses only 16 bits to store the current encoder position.

That being said, there is little to be gained by exceeding 10-20K encoder tics per revolution. I usually recommend getting 1000 or 1024 CPR encoders (again, assuming 1:1 gear ratio). That gives you a resolution of about 0.1 degrees. Any additional encoder precision is wasted on mount errors, alignment errors, slippage, etc.

I’ve never been able to make my decoder box miss counts when using ~ 4000 tics/rev (1000 CPR). I’m not sure what the upper limit is for not missing counts–you might be able to do as high as 10,000 counts/sec, but that’s probably stretching it.

Craig replaced the 16F84 with the 16F628, but he’s still clocking it at the same rate because the PIC code depends on a 4-MHz clock rate (for timing of the serial communications at 9600 baud). So, the max rate will be the same as before.

i have a question about the use of the pic16f628:
on the schematic adapted for the bluetooth communication it appears that you still connect rs232 (TX/RX) communication line to pins RA1 and RB0. But the pic16f628 have dedicated USART pins (RB1 and RB2). Is the schematic wrong or is it by purpose? Are
the hex file (the bluetooth one and the normal one ) compatible with the two microcontrollers?
Thank you!

Joel, the schematic is correct. I did port the code over from the 16F84 to the F628, but didn’t change it to use the 628’s onboard UART. The only reason I ported it was because the 628 is cheaper than the 84. When Craig did the BT version, his code changes were done simply to eliminate some pullup resistors. I don’t think his hex code is compatible with the 84.

I have finally finished my DSC based on this circuit but with a wifi-rs232 module (roving network RN-XV or RN-171 or equivalent) instead of the bluetooth.
The “road” was a little bit tricky, but now it works. So i can connect to my dsc with an iphone/ipod touch and skysafari for example!!!
Somethink to know, is that by default these wifi modules send to the local uart (wired) some messages which are creating troubles and prevent the good function!These messages are HELLO at the connection, and OPEN and CLOS each opening/closing of the ports (which is done by the iphone/ipod software,each query…)). So before doing anything it is mandatory to setup the module with null messages for that (quite simple: in command mode, send “set com close 0” then “set com open 0”, then “set remote 0” then save to the module!! it is well documented in their datasheet)

by the way, with skysafari, it doesn’t look to be possible to program the resolution in the encoder (skysafari do not send resolution setting queries). So i have to write it in “hard” so to speak in the encoder code. Can you tell me where they are located in the hex file, so that i can modify it easily with my own values?
REgards
Joël

Joel, the easiest way to get the encoder resolutions into the box would be to use my testing program (EkBoxTester.exe). The resolutions are stored in EEPROM, so once they’ve been sent to the box once, they’ll remain in the box even when powered off (or until different resolutions are sent).

hi
I was wondering what about the CTS & RTS on the rn-42
do they need to be connected to something in order to transmit and receive data by Bluetooth
and please I want to ask does it matte if am using a different PIC micro controller
in my project am using PIC16f877A and I want to interface it to the rn-42 HID module does it have the same interface ?

The PIC chip used in my interface doesn’t know about the RN-42 module at all. It’s simply transmitting serial data at TTL voltage levels (the same data/voltages that go into the MAX232 chip to be converted to RS-232 levels in the serial version of my board). The only thing that should be necessary is to make sure the RN-42 baud rate is set to the correct rate coming from the PIC (in the case of my circuit, 9600 baud).

Can anyone supply schematic to use the RN-171 with the DSC so i can connect to my iStuff?

I bought a completed bluetooth dsc from Craig and it works great with my windows laptop, but won’t pair with my iPhone or iPad.. actually they don;t even see it.. anyways, i’d like to build one using the wifi module and need help.

there is a small module by roving network (RN-XV) which is doing a serial to wifi convertion. (see my message of 26 may 2012 above. It is working almost ok with a board close the one of craig (replace the bluetooth by the RNXV, not pin to pin compatible, but wiring should do the job).
Joël

Question … I would like to add encoders to an altaz mount (DM-4) and interface this to my Nexus-7 tablet which I just got. It has Bluetooth support. I installed Sky Safari Plus which I like.
Can I just add this board and that’s it? Do I need anything else (besides the encoders)?

You should be able to use that module for BT, but I don’t know if you can modify the USB board for that. It works better to build the serial version of the board and then adapt that to BT. If you want to use the USB board, you’ll have to unplug the USB cable and then add a voltage regulator to the circuit.

I built the BDSC and it works so far also quite good, but unfortunately I have a few problems at a higher resolution.
I use the following encodershttp://www.digikey.com/product-detail/en/AMT102-V/102-1307-ND/827015
These have a maximum resolution of 2048 PPV ie 8192 tics
But if I set about 512PPV it starts to jump,
Mounted these are direct to the axes of my Dobson
About the technology

What do you mean when you say “it starts to jump”? Are you talking about the cursor on the screen on SkySafari that is supposed to show you where you telescope is pointed? If it’s moving erratically, then the problem may be between your BT module and the tablet. I haven’t used that particular module so I don’t know what might cause that, but if communications between the two aren’t smooth, you might see that as a result. The first thing I’d do is check all soldering and connectors to make sure you don’t have any poor electrical connections. After that, make sure you’ve interface the HC-05 correctly and that its internal settings (baud rate, stop bits, parity, etc) are correct.

I’ve used SkySafari in the past with the serial version of my DSC board and a commercial serial-to-BT adapter, and it’s worked fine. So I think SkySafari is up to the task.

Other thoughts: the DSC board checks the encoders at a high enough rate that it should not be missing any encoder tics due to rapid revolution of the encoders. I’m more suspicious of either the encoders themselves (I’ve never seen a type like this before so I don’t know how reliable they are), or it’s possible that your connections between the board and the encoders are not good (maybe a poor solder joint or connector).

I think you’d have to add some additional circuitry, or do some extra work of some sort, to program this encoder prior to using it in the circuit. It’s not a drop-in replacement for the US Digital optical encoders that I recommend.

Can’t replace a standard DSC e.g., Argo Navis DSC with this Bluetooth Bbox, without rewiring the RJ45 connector (the “J1” circuit encoder inputs), being the encoders are swapped, and the Channel A and Channel B are also swapped.