1R053
commented
3 months ago just got my EvScope 2 today... knowing the apis at ports 13007-13012 would be awesome! I figured it is possible to connect from the iPad/iPhone and a computer to the AP. However, wireshark on my mbp does not capture the packets of the other device. It is apparently a MacOs limitation. On some Linux distro / hardware combinations it seems to work though, see here: https://wiki.wireshark.org/CaptureSetup/WLAN#macos-mac-os-x
maybe someone wants to give it a try?
alternatively, in case you have ssh access maybe the remote packet capture in wireshark would work?
Hello,
I found this repo because I had a very similar idea, I wanted to be able to control the eVscope from a computer over a wired connection. My end goal is/was to translate ASCOM into whatever protocol this thing uses. It was very valuable to read through your findings! But it seems you have hit a dead end?
I was wondering if a different approach might work. Instead of keeping the entire evsoft package and trying to decode the traffic between it and a smartphone, what about replacing the evsoft package all together? I was thinking it might be possible to create a new disk image with regular RPi OS on it (or something similar), and then write an ASCOM server (device driver) that runs as an application on the OS. Then the ASCOM server interfaces with the camera and motors through the Unishield HAT.
In the long run that just moves the goal post. Instead of decoding the wireless communication, now I would have to figure out what signals are sent from the RPi to the Unishield HAT. What makes me especially nervous about this approach is the Microchip MCU on the Unishield. I looked it up and I presume it's used for driving the motors, and taking the data from the axis encoders. But I'm not sure how much is handled inside the MCU itself, and how much is passed directly to the RPi. Maybe/hopefully there's a feedback loop that runs on the MCU and never involves the RPi? Presumably Unistellar has written some firmware that lives on the MCU flash memory. So again, that could complicate things.
All that said, I haven't really gotten too far into this approach yet. I want to use a logic analyzer to see what the communication between the RPi and the Unishield looks like. That should give a good idea as to whether this approach is viable. If it's a pretty straight forward protocol, it might have merit. Those are my thoughts though, and I am just getting into reverse engineering, so I'm a bit of a newbie.
What do you think?
EDIT: this method would also allow you to boot from a regular file system instead of a firmware image, you could use a package manager, and something like libcamera would be on the table again.