78 replies to this topic

[Speo]

I am sharing with you all the details of my arduino WiFi / Bluetooth Digital Setting Circles project I put together in April 2020 and tested dozens of times since then.

 

I designed it for communication with SkySafary and it worked flawlesly from day one.

 

The code was written with focus on speed, reducing as many lines of code as possible. SkySafary can poll the DSC 10 times per second with the encoders geared for 1:40000  without breaking a sweat.

 

Below you will find the list of parts, the wiring diagram, the arduino code, the Gerber file I used to order PCBs for fabrication and few pictures of my 12" dobsonian with the system installed.

 

Parts list (available on eBay):
ESP32 board $8 (check pinout in the attached pictures)
Level Shifter $2 (check pinout in the attached pictures
Encoders $10 (any encoder 5-24V, 600 pulses with 2 channels)
GT2 pulleys and belts as per your need (or direct drive, 1:1 gearing)

 

Since the ESP32 board is 3.3V (5V tolerant) and the encoders are 5V, I felt a level shifter should be used to convert the encoder signal from 5V to 3.3V. Also, the level shifter has some resistors that act as pin - pulling resistors. Level shifters and ESP 32 boards with different pinouts can be used, but they must be wired  accordingly.

 

The wiring and board pinouts are in the attached file named "wiring.png"
The code for wifi version is attached in the file named "dsc_wifi.ino.txt"
The code for bluetooth version is attached in the file named "dsc_bluetooth.ino.txt"

The gerber file I used to order the PCBs at the factory in China is attached in file "Gerber.zip"
I also fabricated my own PCB using attached PDF file "pcb.pdf"

 

The code is attached as txt files because .ino is not allowed to upload. Download the files and remove the .txt part, then open them with the Arduino IDE.

 

Once the project is built, you can install the bluetooth or wifi version of the code, depending on your preference. Keep in mind, bluetooth does not work on IOS.

 

Some people prefer bluetooth because they use Android devices and want to keep wifi for using the internet while observing, I prefer wifi because it works on Android and IOS and i don't need internet when I observe.

 

Gearing:
The encoders are 600 pulses per revolution, programmed in quadrature for 600 x 4 = 2400 pulses
If you gear 1:1, you set up 2400 in Sky Safari (more details about settings later)
If you gear 1:2 you gear 2400 x 2 = 4800 in SkySafari (more details about settings later)
If you gear 1:10, you gear 2400 x 10 = 24000 in sky safari (more details about settings later)

Whatever gear ratio you use, multipli it with 2400 and that's what you use in SkySafari settings

I tested gearing ratios between 1:1 and 1:20 and all worked OK, obviously, the higher the gearing, the smoother the movement and the better the accuracy ,but 1:1 still worked.

 

Here is a movie of Alt gearing 1:1 and Azimuth gearing 1:3.75, so you can see the difference in smoothness between the 2 axes.

https://www.youtube....h?v=_xI3exGk98o

 

Settings:

After powering up by USB, the system creates a new network named "stargazing". From the mobile device, connect to it using the password "orionnebula". To change the network name or password, edit these 2 lines of code:

 

const char *ssid = "stargazing";
const char *password = "orionnebula";

 

After you connect the mobile device to the new network, you start SkySafari and go to telescope settings and set the following:

• Equipment Selection/ Scope Type = Basic Encoder System​
• Equipment Selection/ Mount Type = Alt-Az Push To
• RA/Azm = 2400 (multiply this number with your gear ratio for Azimuth or leave 2400 if yo have gearing 1:1)​
• Dec/Alt = 2400 (multiply this number with your gear ratio for Altitude or leave 2400 if yo have gearing 1:1)
• Get Automatically = No  (disable)
• Communication Settings / IP Address = 192.168.4.1
• Communication Settings / Port Number = 80
• Communication Settings / Set Time & Location = Yes
• Communication Settings / Readout Rate = 10 per second
• tap on Done

When the telescope menu settings closes, you should see at the bottom of the app a telescope "Connect" button. Tap on it and wait for the sytem to connect. Once connected, you should see the crosshairs in the app moving in sync with your telescope movement.

 

Now the scope is not aligned. Point it to a star you recognize in the sky, then tap on the star in the app and tap "align" and then "confirm alignment". Done, you are aligned, but it is a one star alignment and not very accurate, especially if the base is not horizontal. To improve the alignment, perform few more alignments on different stars.

 

After alignment, you should be able to easily find stars, planets, DSOs, or satellites. The system is so accurate, that my kids point it on the path of the satellites and wait to see them zipping across the FOV.

 

Few extra details on the project can be found here: https://astrostuff.w...com/magic/magic

 

Feel free to ask any questions, I will do my best to answer.

 

The WiFi version of the code is below, if you prefer the bluetooth version, you can find it attached.

 

String firmwareVersion = "2.0";
#include <WiFi.h>
#include <WiFiClient.h>
#include <WiFiAP.h>

const char *ssid = "stargazing";
const char *password = "orionnebula";

WiFiServer server(80);
WiFiClient client;

#define enc_az_A 27                       
#define enc_az_B 26                       
#define enc_al_A 25                       
#define enc_al_B 33                       

volatile int lastEncodedAl = 0, lastEncodedAz = 0;
volatile long encoderValueAl = 0, encoderValueAz = 0;

void setup()
{
  delay(1000);
  pinMode(enc_al_A, INPUT_PULLUP);
  pinMode(enc_al_B, INPUT_PULLUP);
  pinMode(enc_az_A, INPUT_PULLUP);
  pinMode(enc_az_B, INPUT_PULLUP); 

  attachInterrupt(digitalPinToInterrupt(enc_al_A), EncoderAl, CHANGE);
  attachInterrupt(digitalPinToInterrupt(enc_al_B), EncoderAl, CHANGE);
  attachInterrupt(digitalPinToInterrupt(enc_az_A), EncoderAz, CHANGE);
  attachInterrupt(digitalPinToInterrupt(enc_az_B), EncoderAz, CHANGE);
 
  //Serial.begin(115200);
  //Serial.println();

  WiFi.softAP(ssid, password);
  server.begin();
}

void loop() {
  client = server.available();   // listen for incoming clients

  if (client) {

    while (client.connected()) {            // loop while the client's connected
      if (client.available()) { 
        int c = client.read();
        if (c == 81) {
         printEncoderValue(encoderValueAz);
         client.print("\t");
         printEncoderValue(encoderValueAl);
         client.print("\r");          
        }else if(c == 86) {
         client.print(firmwareVersion);
         client.print("\r");
        }
      }
    }
    // close the connection:
    //client.stop();
   //Serial.println("Client Disconnected.");
   //delay(50);
  }
}

void EncoderAl() {
  int encodedAl = (digitalRead(enc_al_A) << 1) | digitalRead(enc_al_B);
  int sum  = (lastEncodedAl << 2) | encodedAl;

  if (sum == 0b1101 || sum == 0b0100 || sum == 0b0010 || sum == 0b1011) encoderValueAl ++;
  if (sum == 0b1110 || sum == 0b0111 || sum == 0b0001 || sum == 0b1000) encoderValueAl --;
  lastEncodedAl = encodedAl;
}

void EncoderAz() {
  int encodedAz = (digitalRead(enc_az_A) << 1) | digitalRead(enc_az_B);
  int sum  = (lastEncodedAz << 2) | encodedAz;

  if (sum == 0b1101 || sum == 0b0100 || sum == 0b0010 || sum == 0b1011) encoderValueAz ++;
  if (sum == 0b1110 || sum == 0b0111 || sum == 0b0001 || sum == 0b1000) encoderValueAz --;
  lastEncodedAz = encodedAz;
}

void printEncoderValue(long val)
{ 
  unsigned long aval;

  if (val < 0)
    client.print("-");
  else
    client.print("+");

  aval = abs(val);

  if (aval < 10)
    client.print("0000");
  else if (aval < 100)
    client.print("000");
  else if (aval < 1000)
    client.print("00");
  else if (aval < 10000)
    client.print("0");

  client.print(aval); 
}

Attached Thumbnails

• 

Attached Files

•  Gerber.zip   36.5KB   109 downloads
•  PCB.pdf   47.3KB   146 downloads
•  dsc_wifi.ino.txt   2.83KB   105 downloads
•  dsc_bluetooth.ino.txt   2.6KB   108 downloads

Edited by Speo, 01 February 2021 - 11:07 AM.

[Speo]

Potential issues, testing and few more pictures.

 

The board in the pictures below was fabricated using the gerber file attached in the first post.

 

Potential issues

 

1. SkySafary cannot connect to the telescope
2. SkySafary can connect to the telescope, but the telescope is not responding
3. Crosshair in SkySafari is moving the opposite direction of what you expect
4. SkySafary connected to telescope, but does not detect encoder movement

1. Sky Safary cannot connect to the telescope

    Cause: your mobile device is not connected to the network created by the DSC

    Fix: go to the device settings and connect to the network

    Tip: if your settings allow, set the device to connect automatically to the DSC network and disable autoconect for other networks.

2.  Sky Safary can connect to the telescope, but the telescope is not responding

    Cause 1: wrong telescope settings in skySafary

    Fix : make sure you set the telescope settings in skysafari as per the indications in my first post

  

    Cause 2: not investigated yet, since there is a workaround. Even with correct settings, the system might need 3-4 tries until it successfully connects. Just wait 5 seconds and try again, Once connected, it will work flawlessly. I did not bother to investigate further, because tapping "connect" button 3-4 times to connect does not bother me.

 

3. Crosshair in SkySafari is moving the opposite direction of what you expect

    Fix option 1: For that encoder, swap the encoder connections of Channel A and B

    Fix option 2: In SkySafary where you set the telescope pulses for that encoder (2400 for example) change the sign of that number to the opposite. If there is no sign in front of the number, add a minus, if there is a minus, replace it with a plus) 

 

4. SkySafary connected to telescope, but does not detect encoder movement

    Causes (from left to right in the wiring diagram):

• the encoder is bad    
• encoder is not properly wired to the level shifter
• level shifter not properly connected to ESP
• ESP32 is bad
• code was changed and it is not using the same pins as the diagram 

 

      Check if the problem is a bad encoder,  a bad wiring of the encoder, or the rest of the project: 

1. disconnect both encoders
2. If you are gearing up a lot and use numbers a lot higher than 2400 for pulses, change it to a lower number for testing purpose
3. zoom in the application A LOT, until you'll be able to see one possible encoder pulse as a movement of the crosshairs (until crosshairs is as big as the screen should be good) 
4. looking at the telescope crosshairs in Sky Safari, use a wire to connect HV4 to GND for 1 second, then disconnect it. This simulates one encoder pulse, corresponding to a very small encoder move. If you saw a small jump of the crosshair in the Altitude direction, then the channel 4 of the level shifter is good, channel 4 is wired correctly to ESP32 and the ESP32 pin for channel 4 is also good and the problem is in the encoder or encoder wiring for channel 4. If there is no jump in Altitude, then the channel 4 of the level shifter could be bad, or channel 4 is wired wrong to the ESP32 or the ESP32 pin is burnt.
5. Repeat step 4 for all the remaining channels: HV3, HV2, HV1
6. If all channels are testing good, the problem is either a bad encoder or bad encoder wiring
7. If any channel tested bad, check the level shifter wiring for that channel to the ESP32, check that ESP32 pin is good (by running a blink led sketch on it)   

Attached Thumbnails

• 
• 
• 
• 
• 
• 

Edited by Speo, 01 February 2021 - 11:15 AM.

[tommm]

Thank you speo!  Very nice work!

[Edward E]

Outstanding project!  Thank you for all your work and making it available to the community.

 

Any chance you would add an optional gerber file that eliminates the screw terminals and replacing them with 6P4C RJ connector?  As it is now, the screw terminals make the project simple so anyone can build it.  Adding an optional design with 6P4C connectors would make it easier to connect long connector runs between the encoders and the box at the expense of complicating the build.  It would also make connecting/discounting the encoders/box easy for those that have to fully dismantle their scopes for transport.

[Speo]

Outstanding project!  Thank you for all your work and making it available to the community.

 

Any chance you would add an optional gerber file that eliminates the screw terminals and replacing them with 6P4C RJ connector?  As it is now, the screw terminals make the project simple so anyone can build it.  Adding an optional design with 6P4C connectors would make it easier to connect long connector runs between the encoders and the box at the expense of complicating the build.  It would also make connecting/discounting the encoders/box easy for those that have to fully dismantle their scopes for transport.

Good idea. I see some potential issues with people having different wiring on the 6P4C than what I will set up, and different footprint for the 6P4C, but I will try and see if I can come with a solution that will work for any wiring.

 

Maybe use a very comon 6P4C  from DigiKey and wire these to some tabs, but not to the screw terminals. Every person that will build one will have to solder wires between those tabs and the screw terminals, in any configuration necessary so that the RJ connectors will have the correct pinout? Like some jumpers beween screw terminals and RJ.

Edited by Speo, 09 February 2021 - 03:32 PM.

[Edward E]

Actually, after thinking about this some more, there is no need to have an optional design.  If I, the builder, would like to use a 6P4C connectors, then all I need is a pair of 6P4C breakout boards like these  (work with  either 6P4C & 6P6C connectors).  Issue solved without a redesign. 

The only issue I can think of is if there is enough space on the end of the PCS to mount 2  breakout boards.  Is the extra length & width of your PCB board enough to populate it with 2 of these boards, Spedo?

[Edward E]

The again, one can use these 6P6C/6P4C connectors with wires.  The builder just needs to cut out a slot in the case.  The slot does not need to be pretty, just mechanically solid to work properly.  Not sure what gauge wire these use.  If the wires are too small to make a solid connection in the terminals, one can splice a large gauge wire on to work.

[Speo]

Actually, after thinking about this some more, there is no need to have an optional design.  If I, the builder, would like to use a 6P4C connectors, then all I need is a pair of 6P4C breakout boards like these  (work with  either 6P4C & 6P6C connectors).  Issue solved without a redesign. 

The only issue I can think of is if there is enough space on the end of the PCS to mount 2  breakout boards.  Is the extra length & width of your PCB board enough to populate it with 2 of these boards, Spedo?

There is plenty of space there to mount few 6P4C connectors.

[Edward E]

Will this DSC work on a GEM or is it Alt/AZ only?

[Speo]

Will this DSC work on a GEM or is it Alt/AZ only?

Yes, it should work with GEM too.

 

I did not try it on a GEM, but he only difference should be the settings in Sky Safari: instead of selecting the telescope mount as "Alt-Az push to", you should select "Equatorial Push To"

Edited by Speo, 11 February 2021 - 12:13 PM.

[Edward E]

That's what I was thinking.  Thanks!

[Starsareus]

Wow, Thanks for all your time & effort. i like these projects, but for people like me (72 & 2 courses of BASIC in the 70s), looks nice, but not doable & Commercial ones are doable, but too expensive !  I'll keep waiting ......

[gspeed]

Great job and great piece of code!

[Skymart]

Fantastic project ,Just what I’ve been looking for.
Have built and tested the circuit and all working well.
I have a couple of questions re using it on our clubs scopes.

1.

On some of our scopes the encoder will need to be fitted using a small wheel on the encoder pushed onto a larger disc fitted to the scope which means the step count cannot be worked out.
Once fitted I could turn the scope through 360° Azm and 90°Alt accurately.
  Would it possible for you to write a piece of software to count the number on steps moved in each axis?

2.

As a club with more then one scope is there a way of storing the step count on the esp32 for each scope and use the get count function on skysafari .
We could have a different Wi-Fi name for each scope and wouldn’t need to remember the step count for each scope?

[Speo]

Fantastic project ,Just what I’ve been looking for.
Have built and tested the circuit and all working well.
I have a couple of questions re using it on our clubs scopes.

1.

On some of our scopes the encoder will need to be fitted using a small wheel on the encoder pushed onto a larger disc fitted to the scope which means the step count cannot be worked out.
Once fitted I could turn the scope through 360° Azm and 90°Alt accurately.
  Would it possible for you to write a piece of software to count the number on steps moved in each axis?

2.

As a club with more then one scope is there a way of storing the step count on the esp32 for each scope and use the get count function on skysafari .
We could have a different Wi-Fi name for each scope and wouldn’t need to remember the step count for each scope?

Thanks for taking the time to build it.

 

1.

For a PC, use the code I attached in the file "counter_1.0.ino.txt". Upload this firmware instead of the Magic DSC firmware and look in the serial monitor to see the number of steps. Make sure you set the serial monitor sped to 115200. After you find out your numbers, upload again the Magic DSC firmware.

   

For the mobile device, you don't need a counter software, you can see the steps count directly in the Magic DSC firware, using  a free app called "TCP/IP to serial terminal" for IOS or "Serial WiFi terminal" for android. Instead of connecting to the DSC from SkySafari, you connect from the "Wi-Fi serial" app using the same IP and port number - please see the snapshots below.
After you connected from the app, the app can "talk" to the DSC sending specific instructions and receiving responses:

 

  - send "Q" and the Magic DSC will respond with the position ( number of steps). The response will look like this "-00971 +01913" this means 971 steps on azimuth in the negative direction and 1913 steps on altitude in the positive direction. If you set the resolution to 2400, the possible values will go between -1200 to 1200 , half of the resolution in one direction and half in the other direction. This is how Sky Safary expects the steps.

 

  - send "H" and the Magic DSC will respond with the resolution you chose in the code. For example, if you set the resolution to 2400 on az and to 4800 on alt, it will respond "2400-4800"

 

  - if you send "V" it will return the version of the Magic DSC firmware. You currently have 2.0 and the one I attached to this post that includes resolution set in the code will be 2.1

  

 

2.

I attached the code with the modification you requested. Rename it from WiFi_skySafari_2.1.ino.txt into WiFi_skySafari_2.1.ino and upload it.

 

To set the resolution in code, edit these two lines and enable resolution reading in skaysafari:

        const long resolution_az = 2400;
        const long resolution_alt = 4800;

 

Each telescope can have a different wifi name and password. Changes these two lines for each telescope:
       const char *ssid = "stargazing";
       const char *password = "orionnebula";

 

I noticed that sometimes, when changing these 2 lines, and the new password is too short, the password will not be changed. If you run into this issue, change the password length

Attached Thumbnails

• 
• 
• 

Attached Files

•  WiFi_skySafari_2.1.ino.txt   3.3KB   45 downloads
•  counter_1.0.ino.txt   1.92KB   31 downloads

Edited by Speo, 14 February 2021 - 09:17 PM.

[Skymart]

Thanks for the modified code. Will give it a go over the weekend. 

[ledzeplant]

Hi,

This is my first post on this forum. I'm back in astronomy after a pretty long hiatus, but I've had this interest from my early childhood.

 

I recently added Arduino/esp32 and other microcontrollers as a hobby of mine and became very interested in adding a Pushto system to my 8" F6 Dobson. My search led me here.

I plan to add a 2 encoders system but I'm not sure if I want something with a phone and SkySafari, or something else with a remote for searching a catalog of objects, like a Nexus or Intelliscope (I'm not sure if such a project exist, but I suppose it does). I must say that I'm good with coding, very new and not knowledgeable in electronics and very bad at building or repairing things,so I guess the Skysafari  option (the object of this thread) would be the best for me.

 

The context is that I'm canadian, and I live in the pretty cold city of Quebec. I know that I don't like to use my phone for a long period outside during the winter. It's hard not to wear gloves most of the time. It's probably tough for electronics, LCD or OLED screens too. That's why I thought that maybe a keypad with big buttons and a small LCD could be easier to use. I'm just not sure.

 

Maybe it should be the topic for another message, but what's your opinion about using such systems in colder places? Is there a problem for LCD screens? OLED? Encoders? Battery?

 

And by the way, this forum is absolutely great and this topic is particularly interesting. I would'nt have this project without the knowledge of everyone here.

 

Thanks a lot.
Alain

Edited by ledzeplant, 17 February 2021 - 11:13 AM.

[Speo]

My reply might be biased, so, take it with a grain of salt.

 

I owned two Intelliscope systems and after using them for a little bit, I decided to build my own push to system.

For me, navigating through menus on devices with 2 lines of text and having to constantly keep an eye on the numbers and tiny arrows while "pushing to", was a nightmare. A nightmare compared to using sky safari. My experience with intelliscope could have been exacerbatedby the fact that I needed glasses when looking at the remote, but not needed glasses when looking through the telescope or at the tablet.

 

Can you use a tablet stylus, instead of touching it with the finger? Never tried in cold temps. 

 

If you want to touch the tablet less often, you can lock the crosshairs in the center of the image and when you push the telescope, the map underneath will move, keeping the crosshairs in the center. If you set up a proper zoom, you don't need to touch the tablet that often, all you have to do is push the telescope all over the sky and the objects you point at will show up under the crosshairs. You might need to zoom in/out from time to time (if you are zoomed in too much, you loose orientation).

 

You can keep the tablet warm by adding hand warmers underneath the tablet and you can wear sniper style gloves and take only few fingers out from time to time to zoom in/out.

 

Again, in my opinion, looking at two lines of text and tiny arrows, versus looking at the sky map is quite a diference.

Attached Thumbnails

• 
• 

Edited by Speo, 17 February 2021 - 04:51 PM.

[ledzeplant]

I think I’ll go that route and use your solution. I just ordered 2 encoders. I’ll slowly look at everything else, Arduino side, while waiting for them  to arrive.  Is SkySafari as good on Android that it is on iOS? I wrongfully bought the regular version on my iPhone not knowing that I needed the Plus version. And I’m still reticent to use my iPhone or iPad outside by minus 20. l might also buy a cheap Android tablet for that. 
 

Thanks a lot Speo!

[ledzeplant]

I checked the Gerber files included here and briefly tried the purchase option at easyeda.com . I still have not order anything yet. Just to be sure, as I'm really new in everything electronics, I just have to upload the files, pay the fee (2$ before shipping) and they send the board? I suppose that it's then like an Ebay transaction and I have to wait a month or two (or three)? Is there a good similar service in Canada, even if it's more expensive? The board really have a clean design and it would make things easier. I'm ready to try on a breadboard, but I just miss the encoders...Well, I suppose that while waiting, it's time for me to clean my scope mirrors and collimate it. It's never been done in 20 years...

[Speo]

I did not notice any difference in performance between Android and IOS.

 

Yes, you create an account, upload the gerber zip, pay and wait for delivery. I used a different service,  JLCPCB. They have  a minumum of 5 boards I think and faster delivery in 5 days, but shipping is $20.

Edited by Speo, 18 February 2021 - 02:47 PM.

[David Stevenson]

Great work

[ledzeplant]

Yes, you create an account, upload the gerber zip, pay and wait for delivery. I used a different service,  JLCPCB. They have  a minumum of 5 boards I think and faster delivery in 5 days, but shipping is $20.

Thanks Speo. I finally ordered the 5 boards from JLCPB, so i'ts just a matter of waiting now.
 
I'm trying to see how I will put everything in place. All the electronics, the wiring and coding are not a problem, but the physical attachment of the encoders is where I'm not sure. I miss the terminology to do a proper search. It's a very dumb question, but here's a picture of my mount:

Now I believe the encoder has a 6mm shaft (a). This shaft must be attached to (b) where a screw in place right now ©. The screw is there only to support the spring that gives more stability to the scope. Sometimes, I don't even use the springs, so I'm not sure if they are very necessary. I dont know the screw thread either. What I know, is that I have to find an adapter for the encoder shaft and I have to fix it at the pivotal point. All the terms I used in my Google search led me nowhere so far. I must say that I will not use pulleys, as I ordered 2000 p/r encoders. Any suggestions would be welcome. My goal is not to have someone do it for me, but just to find a lead. That's what I meant in my first post when I said that I was not good in building and repairing things :-)

 

Thanks a lot!

Edited by ledzeplant, 20 February 2021 - 02:32 PM.

[Speo]

I prefer using belts and I will explain you why, but, if I wanted to attach the encoder directly to the altitude rotating shaft, I  would try to use these flexible couplings:

 

https://www.bearings...ahoCadIQAvD_BwE

 

The reasons why I prefer belts are:

- it's easier to install the encoder because the encoder shaft and the altitude shaft don't need to be aligned  that precise. The belt will allow a small misalignment - when shafts are not perfectly parallel.

- since there is only 90 degrees of maximum movement on altitude, i could use a disc without teeth and attach the belt to the disc with screws, like in the pic below - the blue wheel has no teeth and the belt is attached with 2 screws. I can position the screws in such a way that 90 deg movement will allow this solution

 - using a plywood wheel and bolting the belt to it allows to use the springs as well

 

 

 

Attached Thumbnails

• 
• 
• 

[ledzeplant]

Thanks Speo for the very valuable information. I’ll check all that a bit more in detail soon and I will see what I do. It’s probably going to be as you suggest.
Bye!