Anyone know if this setup will work? (sensors to read current altitude and azimuth for telescope)

[Navi_21]

Hi!

I've recently been researching a project for my Dobsonian telescope. All I want to do is to just get the current altitude ( in degrees ) and azimuth ( also in degrees ) of my telescopes current position, then print it out to a small display.

So I've found a sensor, the Adafruit BNO055 which I'm not even sure how to convert the data, and if I can.
Link: https://www.adafruit.com/product/4646 ( this is the plug and play version )

And here's the cables I'll be using:
Link: https://www.sparkfun.com/products/14988

Also, I don't plan on motorizing this btw. And the RPi model is the RPi 3 Model B V1.2 from 2015.
So my question is, will all of this work? Is all the hardware compatible? Thank you so much!

[LTolledo]

if wired and coded properly.... it might work

[cleverca22]

personally, i would use an accelerometer (the adafruit IMU includes one) to measure altitude

but i'm not sure how much i would trust it for azimuth, the accel/gyro stuff will have drift over time, and magnetic sensors just dont seem accuate enough to me (more a gut feeling)

i would add in an encoder of some kind, to measure the rotation of the telescope mount, and then zero it out as usual when you set it up

[thagrol]

i would add in an encoder of some kind, to measure the rotation of the telescope mount, and then zero it out as usual when you set it up

Do that for both axis. That's how most GoTo scopes work. Or use a pair of absolute encoders with sufficient precision but I'd expect that to be the expensive option.

[amcdonley]

Yes, but...

I use the BNO055 on my robot and find the instantaneous rotational accuracy of the BNO055 IMU to be very good, but the drift over longer periods is real and significant. My physical encoders (0.5 degree precision) are rock solid and end up being as accurate or better than the IMU. Both end up with around 4-5% error over time.

Another issue with the BNO055 is that it needs clock stretching I2C which the Raspberry Pi default I2C drivers do not sufficiently implement. Even with well coded clock-stretching, my IMU setup results in non-fatal I2C read errors: (last column)

Code: Select all

2020-07-27 18:54|[imulog.py.logCurrentIMU]heading:   359.9  rotation:     0.0 motion:     0.0 sec errors: 25  imu reset
2020-07-27 21:21|[imulog.py.logMotionStop]heading:     0.1  rotation:     0.1 motion:     2.7 sec errors: 41
2020-07-28 03:04|[imulog.py.logMotionStop]heading:   178.2  rotation:   178.1 motion:     2.4 sec errors: 78

I would guess that over the course of a one hour viewing session, the setup will be satisfactory if you are hoping for 1 degree accuracy. If you want better, you may need to recalibrate periodically by slewing to physical stops at known angles (perhaps you have an 0 alt 0 az lock?).

The BNO055 also suffers somewhat from influence of nearby ferrous metal, and magnetic variance, you may find that rotating through 90 alt and 360 az requires maintaining a correction table. The sensor attempts to self calibrate, but my robot environment probably presents a bigger challenge than the typical wood Dobsonian mount.

The BNO055 is also not inexpensive.

Given all this, for less money you probably could build a very nice optical encoder disk with an infrared sensor on the the outer edge of the disk that could give you rock solid, precise information for your RPi to display, with human readable degree indicators for when you forgot to charge the RPi battery before going out.

Something like these edge detectors and using a large clear acrylic disk with a pattern printed on "overhead projector print stock" (clear) would allow you to design the precision you want:

https://www.robotshop.com/en/cytron-sim ... r-kit.html

https://www.robotshop.com/en/encoder-pa ... arbox.html

[cleverca22]

i would add in an encoder of some kind, to measure the rotation of the telescope mount, and then zero it out as usual when you set it up

Do that for both axis. That's how most GoTo scopes work. Or use a pair of absolute encoders with sufficient precision but I'd expect that to be the expensive option.

i looked into how my old DS-60EC scope works, and yeah its pretty much that
each motor unit has a pic16 with an encoder, and uses i2c to talk to the hand control box
the hand controller comes in several models, either just a dumb speed controller, or full goto
and the pc link port is just 2 pins routed to the hand controller, for either rs232 or i2c

but now that i know all of that, i could replace the controller with a pi, and just i2c both motor units directly, if i knew the protocol

[thagrol]

Are you sure it's I2C? Both my scopes use serial to communicate between the handset and motor controller in the mount (Skywatcher synscan).

I2C for comms to a PC is unlikely as few, if any, PCs can talk I2C to the outside world so an active cable would be required.

Last I looked, the protocols used for handset to PC and handset to mount comms were available on the skywatcher downloads page.

[cleverca22]

Are you sure it's I2C? Both my scopes use serial to communicate between the handset and motor controller in the mount (Skywatcher synscan).

I2C for comms to a PC is unlikely as few, if any, PCs can talk I2C to the outside world so an active cable would be required.

Last I looked, the protocols used for handset to PC and handset to mount comms were available on the skywatcher downloads page.

i saw i2c mentioned in a few threads, and there is some kind of special adapter to convert the i2c to rs232
one old thread also said that windows XP bit-banging i2c over the serial port was part of the performance limit

that aux port is also on what may be gpio of the main controller, which could just change modes

i need to power up the hw, and start poking it with a scope to confirm what ive been finding on http://www.weasner.com/etx/autostar_info.html and related sites