Bluetooth controlled stepper driver

With the ongoing integration of gadgets like cellphone, PDA, photocamera, etc. it becomes much more feasible to use a pocket planetarium application to directly control your telescope. Most of these handheld systems have a Bluetooth interface, supporting the Serial Port Profile (SPP). The design presented on this page makes use of this feature, by offering an SPP interface to transport control commands. The control interface I selected is LX200 compatible, which is a widely supported proprietary Meade standard.

The hardware and software design, plenty of background information and a working prototype is described in the PDF document, which can be found here.

Design overview

The image below shows the system design of the Bluetooth controlled solution.


The system consists of three parts: a controller and two current drivers. The controller takes care of user interface, coordinate transformations and sending out pulses to advance the steppers. The current drivers convert the step pulses into the corresponding current to drive the actual stepper motors.
The purpose of separating controller and driver is to decouple the implementation of the controller form the actual AC needs of the stepper motors. The driver can be optimized for the steppers selected to move the telescope. Stepper drivers which have a step-pulse control interface are commercially available from various sources.
The controller has two serial interfaces. The first runs over a Bluetooth link, using the Serial Port Profile (SPP). This interface is used to link to external applications by means of the LX-200 control protocol. The second serial interface is wire based, and can be used for autoguider or possibly a hand paddle.
The controller is powered by for example a car battery. The current drivers will have their own supply which depends on the selected units (probably also car battery).

The controller is built around a Microchip dsPIC 30F4011 digital signal controller. This controller has built-in DSP functionality, such as a MAC (Multiply and ACcumulate). Such a MAC provides a single cycle fixed-point mutiply instruction, which is good for coordinate transformations.


The Bluetooth interface is implemented with an RN41 module by Roving Networks. This module provides a serial port to the PIC, and requires only a few simple controls. The wired serial interface is implemented with a MAX232 compatible level shifter, and the interface towards the current drivers is using a 74244 TTL transceiver.

The plan is to use a pair of SparkFun Easy Driver modules, which are based on an Allegro A3967 driver chip. This chip can drive steppers between 7..30V with a max current of 750mA. An alternative for more demanding stepper motors could be an M415C, obtainable from stappenmotor.nl. Another possibility is to roll your own, for example based on the new L6470 by ST-Microelectronics.

Prototype

A prototype of the controller has been built according to the the plan described in section 1. The image below shows this prototype and indicates the interfaces and the PIC DSC.


The total cost of this prototype is about €50, the RN41 Bluetooth module being the cost driver. As can be seen, with a little effort it would be possible to squeeze on some more components, or to shrink the PCB. The final design could also increase the use of SMT for passive components. All in all, the current prototype is foremost meant as a platform for experimentation and software development. The main challenge will be to squeeze it all in the tiny memory, measuring 48kB of Flash and 2kB of RAM. Furthermore, the clock speed is quite low, only 40MHz with a non-pipelined instruction rate of 10MHz.

Hardware

The schematic shows the parts that form the business logic of the prototype:

  • the 30F4011 processor,
  • the RN41 Bluetooth module and
  • the RS232 interface.

Of both communications interfaces (RN41 and MAX232) only the dataleads are used. The RN41 by default has a bitrate of 115k2, which is a tad high for the 4011. For that reason the prototype has a modification to force the bitrate to 9600 by pulling PIO7 HIGH (i.e. pin4 to 3V3). Apart from the dataleads, two control lines are passed from RN41 to 4011:

  • PIO2, for indication of 'connected' state, HIGH when connected, LOW otherwise
  • RESET, to enable forced reset of the RN41 from SW.
The B3 (port B, bit3) pin of the 4011 has been connected to a LED, which is used by the SW to indicate whether it is alive. For this purpose it is flashed by the Xform task, every time it runs (once a second).
Port E of the 4011 is connected to the current driver interface, for stepper pulses and direction.
Finally, a programming interface is connected (PGC, PGD, Vpp).

The board layout shows the placement of the various components. All user interfaces (except the ICD2 program/debug interface) are on one side, which should ease the integration in a box. Notice the absence of ground plane around the antenna area of the Bluetooth module. The PCB should for the same reason be put in a non-conducting enclosure.

Software

The most demanding task for the controller will be the generation of stepper pulses. This happens in an interrupt servioce routine (ISR) triggered by a hardware timer. Considering the instruction clock of 10MHz and a 10kHz step pulse frequency, there are about 500 instructions between timer interrupts. The timer interval is 50 microsec (instead of 100) because each pulse has a rising and a falling edge. This is not a lot, but luckily the ISR task is very simple, counter update a conditional toggle of the pulse bit.

The software structure is as shown in the above diagram. There are three operational tasks that run concurrently, and optionally (not drawn) a fourth monitoring the RS232 guide-port for configuration commands or autoguider input. Operational tasks:

  • LX200 interpreter: Interprets the LX-200 control protocol over the Bluetooth interface to PC or PDA. This task also executes the calibration functions, which are in fact initiated by some of the LX-200 commands. It is the least time critical task, so it runs at lowest priority.
  • Transform: This task calculates every (sidereal) second what the Target Horizontal coordinates on the next tick should be. This calculation relies on the availability of a valid transformation matrix. It converts the Target Equatorial coordinate input from the LX200 task and the current LST into Target Horizontal coordinate.
  • Speed Control: This task calculates 10 times per second what the stepper speeds should be, based on the difference between Actual and Target Horizontal coordinates and the current speed. The calculation takes into account the acceleration and speed limits. It has a higher priority than the Transform task.
Finally, the Stepper Control task is implemented as an Interrupt Service Routine (ISR) because it has a very strict timing requirement. Since it is an ISR it automatically gets higher priority than any regular task.

Testing

In order to test the controller prototype, a pair of steppers and a pair of current drivers have been purchased from Spakfun (items ROB-09402 and ROB-09238). All system components are mounted on a wooden board, together with a quick and dirty power supply.
This setup can not really be used for testing the transformation algorithms, but still some important parts can be tried out. First thing is to tune the current drivers in such a way that dissipation is minimized and speeds up to 5000 steps per second are possible. Then of course the functioning of ISR and also of the speed control algorithms can be verified.