30 replies to this topic

[mlord]

Time for a new HomeBrew project!

For this, we'll be going over to the Dark Side, creating an HBG3-Relay variant for SkyWatcher/SynScan mounts!

What does this mean, exactly?

 

Well, Celestron's parent company also owns the SkyWatcher brand, but the two product lines have completely different interfaces and protocols.  And in particular, the SkyWatcher/SynScan stuff doesn't have anything like the ubiquitous AUX Bus that Celestron mounts have, so they are lacking in plug-in accessories that integrate nicely with those mounts.  Eg. Focus Motors, Smart Dew Controllers, third-party GPS receivers, Bluetooth interfaces, StarSense AutoGuider, and the ever-so-handy Nunchuck interface.

 

This project aims to correct that deficiency, by creating an Open Source hardware/software combo that can act as an invisible protocol bridge between SkyWatcher/SynScan mounts, and the growing number of Celestron AUX peripherals and software.  This project is here in the Celestron forums, because it builds upon the existing HomeBrew projects for Celestron, and will be working with all of those and various other Celestron accessories.

 

But.. wait, you say.  Doesn't Celestron already have a product that does something like this?  Well, kind of.  They have the "StarSense For SkyWatcher" product, which consists of a standard StarSense AutoAlign Camera and Hand-Controller, packaged with a special interface box.  That box has one 8-pin port for connection to a SkyWatcher mount, and provides three Celestron AUX compatible ports.  But Celestron limits use of this box to only the StarSense AutoAlign system, and (optionally) a "SkySync" GPS receiver.  And the interface box is not normally available separately, though it has appeared in some markets recently. This box is visible at Right, in the photo below.

 

 

The existing HBG3 accessory can actually plug into that interface box, and already provides working WiFi, Bluetooth, GPS, Nunchuck, etc.. for a SkyWatcher mount, so long as the StarSense HC is also plugged in.  But we can do much better than that here!

 

This new project aims for an alternative to that box, which will work with all Celestron AUX accessories, including the Nexstar+ hand-controller, and with CPWI software, the SkyPortal app, and as a "Celestron WiFi" scope for SkySafari +/pro.

 

This will begin with building an electrical interface for the existing HomeBrew Gen3 (HBG3), to permit connection via an adapter cable to the hand-controller port of a SkyWatcher mount.   The HBG3 processor will also offer AUX port connections, and translation between the two interfaces.  After that, as they say, it's only firmware.

 

But LOTS of firmware.. essentially adding full Celestron Nexstar mount emulation inside the HBG3, and then adding a translation back-end for the SynScan protocol to that.

 

More as I hook these up and learn about them.

 

Cabling:  A new SynScan hand-controller will include appropriate cables with purchase.  But for the Celestron Interface Box by itself, one may need to make up a suitable cable.  For the EQ mount 8-to-8 pin port, use a standard 8P8C/R cable: https://www.cloudyni.../#entry12924605  For AZ mounts, the 6-to-8-pin wiring is shown here, using five wires between the two ends:

 

 

Neither of the cables described above are usable with the HBG3 directly to a SkyWatcher mount though.  I will be following up here with appropriate cable/circuitry for this purpose.  Stay tuned!

Edited by mlord, 27 April 2024 - 05:34 AM.

[mlord]

The existing Celestron interface box is not part of, nor required, for this project.  But since I have one on hand, here's a peek inside:

 

 

As expected, the PCB has a 5V power supply, with a LV125 buffer chip for the AUX bus, and a PIC processor to handle protocol translation.

 

Edited by mlord, 26 April 2024 - 03:07 PM.

[mlord]

Time for some signal traces to/from the Interface Box.  As expected, Celestron is using 5V signalling on the AUX bus, seen here on a scope:

 

 

For the SkyWatcher mount interface side, it's a different story.  Here's a command being sent to the mount, using 5V TTL signalling:

 

 

But the response from this AZ-GTi mount instead uses 3.3V signalling:

 

 

So.. Celestron assumes any SkyWatcher mount will be 5V-tolerant, meaning one can use either 5V or 3.3V signal levels for transmissions to the mount.   But depending upon the mount, it may respond either with 3.3V (as here), or with 5V signalling.

 

This is great news for the new project here, as it could be quite simple to adapt the existing HBG3 to plug directly into the SkyWatcher mount.  All that might be needed is a passive adapter cable for the AUX port of the HBG3, to get the 12V, GND, TX, RX and BUSY/DROP signals onto the right pins.  No voltage fiddling required, so long as the 74HCT125 chip can deal with 3.3V on the receive line (which it should; that's why we chose that chip originally!).

 

EDIT: This may be a bit more complex, as the AZ-GTi does NOT tie Rx/Tx together.  Will find out more going forward.

Edited by mlord, 27 April 2024 - 12:32 PM.

[fdboucher]

Hahah!

I will be watching this brilliant project of yours with great interest!

I received my Celestron/Synscan interface box… but it seems to be doing nothing… as of now.

I did not try it for very long, though.

Plugged the Celectron interface into my SkyWatcher Synscan 8" dobbie. 

I plugged the HBG3 in → nothing…

Tried the Celestron HC → nuthin'…

Not sure if i'm doing something wrong. 

At least: nothing caught fire!

Will try again later, but tonight should be a fine observing evening, and I just took out my C9.25 & HBG3 for a ride.

:-)

Edited by fdboucher, 26 April 2024 - 06:22 PM.

[fdboucher]

This is great news for the new project here, as it should be quite simple to adapt the existing HBG3 to plug directly into the SkyWatcher mount.  All that should be needed is a passive adapter cable for the AUX port of the HBG3, to get the 12V, GND, TX, RX and BUSY/DROP signals onto the right pins.  No voltage fiddling required, so long as the 74HCT125 chip can deal with 3.3V on the receive line (which it should; that's why we chose that chip originally!).

But do both systems, Nexstar and Synscan, use a similar set of instructions?

Edited by fdboucher, 26 April 2024 - 06:13 PM.

[mlord]

I received my Celestron/Synscan interface box… but it seems to be doing nothing… as of now.

It only works if a Celestron StarSense Hand-Controller is also plugged into it.  There are some "magic" commands that get exchanged to enable the bridge inside the Interface Box.   Now that I have one of those here, I expect to reverse-engineer that part, to eliminate the need for the StarSense hand-controller with that box.

 

But longer term, no such box. 

Edited by mlord, 27 April 2024 - 05:39 AM.

[mlord]

It only works if a Celestron StarSense Hand-Controller is also plugged into it.  There are some "magic" commands that get exchanged to enable the bridge inside the Interface Box.

Mmm.. I have been poking at this here today, and the initialization sequence used by the StarSense Hand-Controller (SSHC) for the StarSense-SkyWatcher Interface box (SSSWI) is this:

 

000120704 auxbus_rx: 3b 03 0e b4 fe 3d                                  [SSHC   -> SSAA  ] GET_VERSION
000121194 auxbus_rx: 3b 03 0e 10 fe e1                                  [SSHC   -> AZM   ] GET_VERSION
000121206 auxbus_rx: 3b 07 b8 0e fe 01 00 17 90 8d                      [SSSWI  -> SSHC  ] Version: 1.0.6032
000121224 auxbus_rx: 3b 03 0e 10 05 da                                  [SSHC   -> AZM   ] GET_MODEL
000121235 auxbus_rx: 3b 04 10 0e 05 00 d9                               [AZM    -> SSHC  ] Model: 0x00
000121254 auxbus_rx: 3b 03 0e b4 05 36                                  [SSHC   -> SSAA  ] GET_MODEL
000121354 auxbus_rx: 3b 03 0e 10 05 da                                  [SSHC   -> AZM   ] GET_MODEL
000121364 auxbus_rx: 3b 04 10 0e 05 00 d9                               [AZM    -> SSHC  ] Model: 0x00
000121384 auxbus_rx: 3b 03 0e 11 fe e0                                  [SSHC   -> ALT   ] GET_VERSION
000121396 auxbus_rx: 3b 07 b8 0e fe 01 00 17 90 8d                      [SSSWI  -> SSHC  ] Version: 1.0.6032
000121414 auxbus_rx: 3b 03 0e 11 05 d9                                  [SSHC   -> ALT   ] GET_MODEL
000121424 auxbus_rx: 3b 04 11 0e 05 00 d8                               [ALT    -> SSHC  ] Model: 0x00

000121444 auxbus_rx: 3b 03 0e b8 fe 39                                  [SSHC   -> SSSWI ] GET_VERSION
000121456 auxbus_rx: 3b 07 b8 0e fe 01 00 17 90 8d                      [SSSWI  -> SSHC  ] Version: 1.0.6032

000121474 auxbus_rx: 3b 03 0e b8 05 32                                  [SSHC   -> SSSWI ] GET_MODEL
000121484 auxbus_rx: 3b 04 c8 0e 05 00 21                               [SSSWI2 -> SSHC  ]

 

000121504 auxbus_rx: 3b 03 0e b8 31 06                                  [SSHC   -> SSSWI ]
000121516 auxbus_rx: 3b 07 b8 0e 31 9f 07 e3 9b de                      [SSSWI  -> SSHC  ]

000121536 auxbus_rx: 3b 07 0e b8 32 fe e9 55 a7 1e                      [SSHC   -> SSSWI ]
000121544 auxbus_rx: 3b 04 b8 0e 32 01 03                               [SSSWI  -> SSHC  ]

 

Most of this is standard stuff, and very easy for the HBG3 to replicate.  But control of the SkyWatcher mount is not enabled until after the final two exchanges shown, the mysterious "31" and "32" commands.  The SSHC then repeats this exchange every 15-seconds from that point onward, with different 4-byte data values returned by SSWI and then responded to by SSHC each time.  Eg:

 

000968269 auxbus_rx: 3b 03 0e b8 31 06                [SSHC   -> SSSWI ]
000968281 auxbus_rx: 3b 07 b8 0e 31 ff ae 0e a5 a2    [SSSWI  -> SSHC  ]
000968307 auxbus_rx: 3b 07 0e b8 32 ff a2 c8 35 63    [SSHC   -> SSSWI ]
000968319 auxbus_rx: 3b 04 b8 0e 32 01 03             [SSSWI  -> SSHC  ]

000983269 auxbus_rx: 3b 03 0e b8 31 06                [SSHC   -> SSSWI ]
000983281 auxbus_rx: 3b 07 b8 0e 31 af 82 a4 2b 02    [SSSWI  -> SSHC  ]
000983301 auxbus_rx: 3b 07 0e b8 32 ff 77 2b 57 09    [SSHC   -> SSSWI ]
000983309 auxbus_rx: 3b 04 b8 0e 32 01 03             [SSSWI  -> SSHC  ]

000998269 auxbus_rx: 3b 03 0e b8 31 06                [SSHC   -> SSSWI ]
000998281 auxbus_rx: 3b 07 b8 0e 31 df 56 39 b1 e3    [SSSWI  -> SSHC  ]
000998302 auxbus_rx: 3b 07 0e b8 32 ff 42 11 61 4e    [SSHC   -> SSSWI ]
000998310 auxbus_rx: 3b 04 b8 0e 32 01 03             [SSSWI  -> SSHC  ]

001013270 auxbus_rx: 3b 03 0e b8 31 06                [SSHC   -> SSSWI ]
001013282 auxbus_rx: 3b 07 b8 0e 31 8f 2a cf 37 43    [SSSWI  -> SSHC  ]
001013302 auxbus_rx: 3b 07 0e b8 32 ff 1a fd 9a 51    [SSHC   -> SSSWI ]
001013310 auxbus_rx: 3b 04 b8 0e 32 01 03             [SSSWI  -> SSHC  ]

 

Notice that the first byte of data received/sent each time is usually af,ff,8f,9f etc.. But the other three vary wildly.

 

I have tried replicating this, but the HBG3 is thus far unable to "enable" mount control.  I am beginning to suspect that this may be some kind of cryptographic challenge/response exchange to "enable" mount control.  As in, the SSSWI responds to the 31 command with a 4-byte "challenge", and the SSHC then performs a transformation on those 4-bytes to generate the correct "response" to then send with the subsequent 32 command.

 

This challenge/response is repeated by the SSHC every 15-seconds, and the SSSWI must have an internal time-out associated with it -- if I disable the SSHC, and wait, say, 30-seconds, mount control is lost again.  So one has to keep doing the challenge/response to keep the connection alive.

 

I have also determined that the "challenge", returned by the 31 command, changes every half-second.  Eg:

 

000005821 ssswi challenge: 8f fa a5 ad
000006329 ssswi challenge: cf 56 22 1e
000006828 ssswi challenge: 8f b3 9e 93
000007326 ssswi challenge: cf 0f 1b 06
000007825 ssswi challenge: 7f 6c 97 79
000008322 ssswi challenge: bf c8 13 ec
000008820 ssswi challenge: ff 24 90 61
000009317 ssswi challenge: bf 81 0c d2
000009826 ssswi challenge: ff dd 89 47
000010323 ssswi challenge: bf 3a 05 ba
000010820 ssswi challenge: ef 96 82 2f
000011319 ssswi challenge: af f2 fe a0
000011816 ssswi challenge: ef 4f 7b 15
000012314 ssswi challenge: af ab f7 88
000012822 ssswi challenge: ef 08 73 fb
000013320 ssswi challenge: af 64 f0 6e
000013818 ssswi challenge: df c0 6c e3
000014316 ssswi challenge: 9f 1d e9 54
000014814 ssswi challenge: df 79 65 c9

 

Next up, is to determine if this is really just the Interface Box doing this, or if instead it is the SkyWatcher mount itself?

 

EDIT:  No problem sending SkyWatcher commands directly to the mount to cause motion, so the mount itself isn't locked down.  It must just be the Celestron Interface Box that wants the challenge/response thing.

 

All of this suggests that Celestron may be trying to lock-down the SkyWatcher Interface Box.  If that's the case, one can only speculate on why?

Edited by mlord, 27 April 2024 - 08:00 PM.

[mlord]

Surely we must have someone here who's a bit of a statistician or math wiz?

 

I can easily collect a few hundred of the pairs of 32-bit challenge/response values, which then someone else may know how to do a bit of correlation analysis on.. and figure out what the transformation is that produces the second number from the first of each pair?

 

It's probably something relatively simple, like just doing a CRC calculation, or even simpler.

 

I used to know how to do this kind of thing, maybe four decades ago.. but no longer!

Edited by mlord, 28 April 2024 - 07:02 AM.

[gmiller123456]

It's probably something relatively simple, like just doing a CRC calculation, or even simpler.

I used to know how to do this kind of thing, maybe four decades ago.. but no longer!

See if you can find a pair of challenge/responses where the challenges differ by only one bit (or very few bits). Then compare the number of bits that change in the response. If about half of them change, then it's likely a cryptographic hash function, and not worth anyone's time trying to crack unless you really enjoy a challenge. You might also try sending your own challenges.

Edited by gmiller123456, 01 May 2024 - 11:03 AM.

[mlord]

You might also try sending your own challenges.

I like that idea.  It'll take quite a bit of "plumbing" to get to the point where that is possible though, so it'll be a while.

 

EDIT:  Or perhaps not.. The StarSense HC can be connected to the Relay side of the HBG3-Relay, with the normal side of that plugged into the Interface Box, and from there to the mount.

 

With minor coding, the HBG3-Relay can then intercept and respond to the "get Challenge" requests of the SSHC, enabling us to use any Challenge data we want for the purpose of seeing how it gets transformed into Responses.  We'll lose comms with the mount, but that doesn't really matter for this exercise.

Edited by mlord, 01 May 2024 - 12:22 PM.

[mlord]

I like that idea. ... The StarSense HC can be connected to the Relay side of the HBG3-Relay, with the normal side of that plugged into the Interface Box, and from there to the mount.

 

With minor coding, the HBG3-Relay can then intercept and respond to the "get Challenge" requests of the SSHC, enabling us to use any Challenge data we want for the purpose of seeing how it gets transformed into Responses. 

Coded, working, and the results thus far look encouraging.  It appears to be some kind of simple (non-cryptographic) transformation.  I'll post the data here in a while and see if the algorithm can be worked out.
 

[mlord]

Here's some useful data, a series of challenge/response pairs:
 

0xffffffff 0xffffffff
0x80000001 0x80fdfcfe
0x80000002 0x80fdfcfe
0x80000004 0x80fdfcfe
0x80000008 0x80fdfcfe
0x80000000 0x80fdfcfe
0x40000000 0x40fdfcfe
0x20000000 0x20fdfcfe
0x10000000 0x10fdfcfe
0x08000000 0x08fdfcfe
0x04000000 0x04fdfcfe
0x02000000 0x02fdfcfe
0x01000000 0x01fdfcfe
0x00800000 0x807efdfe
0x00400000 0x403efdfe
0x00200000 0x201efdfe
0x00100000 0x100efdfe
0x00080000 0x0806fdfe
0x00040000 0x0402fdfe
0x00020000 0x02fffcfe
0x00010000 0x01fefcfe
0x00008000 0x80fe7eff
0x00004000 0x407e3eff
0x00002000 0x203e1eff
0x00001000 0x101e0eff
0x00000800 0x080e06ff
0x00000400 0x040602ff
0x00000200 0x0202fffe
0x00000100 0x01fffdfe
0x00000080 0x150ae4fe
0x00000040 0x83b4f0fe
0x00000020 0xe5e4f6fe
0x00000010 0xf8f3f9fe
0x00000001 0xfffcfcfe
0x00000002 0xfffcfcfe
0x00000004 0xfffcfcfe
0x00000008 0xfffcfcfe

0x00000000 0xfffcfcfe
0x8000000f 0x80fdfcfe
0x4000000f 0x40fdfcfe
0x2000000f 0x20fdfcfe
0x1000000f 0x10fdfcfe
0x0800000f 0x08fdfcfe
0x0400000f 0x04fdfcfe
0x0200000f 0x02fdfcfe
0x0100000f 0x01fdfcfe
0x0080000f 0x807efdfe
0x0040000f 0x403efdfe
0x0020000f 0x201efdfe
0x0010000f 0x100efdfe
0x0008000f 0x0806fdfe
0x0004000f 0x0402fdfe
0x0002000f 0x02fffcfe
0x0001000f 0x01fefcfe
0x0000800f 0x80fe7eff
0x0000400f 0x407e3eff
0x0000200f 0x203e1eff
0x0000100f 0x101e0eff
0x0000080f 0x080e06ff
0x0000040f 0x040602ff
0x0000020f 0x0202fffe
0x0000010f 0x01fffdfe
0x0000008f 0x150ae4fe
0x0000004f 0x83b4f0fe
0x0000002f 0xe5e4f6fe
0x0000001f 0xf8f3f9fe
0x0000000f 0xfffcfcfe

 

Some patterns quickly emerge.  I'll have a longer look at it later, but I'm hoping for help on this one!

Note that the final digit of the "challenge" seems to be ignored/not-used.

And the second-last digit of the "response" is always "f".

Edited by mlord, 01 May 2024 - 05:06 PM.

[mlord]

To sweeten things up, I am offering to send a fully-assembled HBG3 accessory for free to the first person to show how to generate a correct 32-bit response from any 32-bin challenge here.  So dust off the tinfoil hats and have a go at it! 

[gmiller123456]

That's fairly promising, it's not cryptographically strong.  I checked that it is not one of the standard CRC algorithms using this CRC calculator.

 

If you send 0x88000000, do you get 0x88fdfcfe?

 

It looks like the first two numbers of the response simply involve addition (or logical OR) of parts of the challenge, as they are often just copies.

[mlord]

CR: 0x88000000 0x88fdfcfe

CR: 0x80800000 0x017ffdfe

 

I have noticed that much of the time, the first byte of the Response appears to be the OR (or sum?) of the first three bytes of the Challenge.

Edited by mlord, 02 May 2024 - 05:46 AM.

[mlord]

There's an interesting relationship among the first three bytes of the challenge/response.  Here are some selected values:

 

CR: 0xffffffff 0xffffffff
CR: 0xfe010100 0x0102fefe
CR: 0x00010200 0x0303fffe
CR: 0xff010200 0x0304fffe
CR: 0x00010200 0x0303fffe
CR: 0xff010200 0x0304fffe
CR: 0xfe010200 0x0204fffe
CR: 0xff020100 0x0303fefe
CR: 0xff020100 0x0303fefe
CR: 0x00ff0100 0x0101fffe
CR: 0x00010100 0x0201fefe

 

The 2nd byte of each response appears to be the sum of the 2nd/3rd bytes of the challenge.

The 1st byte of each response appears to be the sum of the 1st/2nd/3rd bytes of the challenge.  More or less.

To me, this still suggests some kind of CRC/Checksum algorithm.

 

 

[gmiller123456]

Well, it's certainly not a CRC, might be some other checksum algorithm.  Wikipedia has a list of common checksum algorithms, and Fletcher-32 seems kinda promising.  But the fact that the last byte of the response always starts with "f" means it's an inefficient algorithm, so probably not a standard one.  It might be a standard one with some slight modifications though.  It could be a bug in their attempt at implementing a standard one.

[mlord]

Here (attached) are some more of the challenge-response data points, in case anyone here wants to get the SSSWI interface working without having to have a StarSense HC plugged in.

 

Note that the SSSWI (StarSense for SkyWatcher Interface) is not actually part of this new project, other than as a useful thing to work out some of the commands required to manage a SkyWatcher mount.

 

Cheers

Attached Files

•  cr_pairs.txt   25.54KB   27 downloads

[killerkiko]

i no nothing about cryptography, but later today im going to feed all of this in to a LLM and see if it can figure it out. I also manage 6 really bright engineers in my day job, and will be asking them to help too. haha. 

As a current owner of 2AVX's and an slt mount, i just picked up a second hand AZGTI and am excited to be able to use all my celestron stuff with it, including the two HBG3;s i have. 

 

Hey mark, this is me, francisco.

[killerkiko]

Ok, ive been defeated Mark. I got nothing on this cryptography front, but it was fun going back and forth with ChatGPT about this. 

[Bartec]

https://skywatcher.c...on-development/

 

Can this information help you?

[Bartec]

https://www.youtube....Z8b6X71U&t=346s

[mlord]

https://skywatcher.c...on-development/

 

Can this information help you?

Yes, I already have that stuff, thanks.

[jlutzwpi]

Bumping this up.  Looking forward to this project!

[mlord]

On hold until the long dark winter here.  Will probably make some progress in November and again in January/February.

 

Cheers