668 replies to this topic

[mlord]

The built-in Wifi of my new EVO-8 seems to be poorly implemented (big surprise, not!) -- if the connection with my smartphone ever lapses, the mount requires a power-cycle before it ever works again.  That's just poor programming in the mount electronics, a lack of basic fault tolerance considerations.  The fault is definitely on the mount side, not the app.  The mount simply doesn't appear to accept a "new" connection when it thinks the "old" connection is still there, even though it isn't alive at the other end.

 

So.. solution is to roll one's own more reliable wireless option(s), as a small box that plugs into an AUX port on the mount.  This thread will help document and share the efforts, and anyone is welcome to join in and play along.

 

An ESP32 dev board, with both bluetooth and Wifi built-in, is a good starting point.   These cost between CAD$12 and CAD$25 on Amazon, or less than that direct from Asia.  I'll be using one of those, probably a "NodeMCU-32S" style variant.  These are 3.3V boards, and are NOT designed to tolerate 5V logic inputs from the mount.  So a discrete 74LV136 chip will likely be wired in to buffer/tristate the bus lines and also to do the 5V <--> 3.3V level conversions.

 

Some effort may be needed to figure out the protocols -- as near as I can tell, no-one else has documented interfacing Wifi or Bluetooth directly to the AUX bus -- most tend to use the serial port on one of the older generation hand controllers instead.

 

My first effort today was to plug the logic analyzer into the EVO mount, and observe what happens when a wifi connection is used with the built-in wifi stuff.  I am very happy to have discovered that nothing "fancy" at all is involved.  The Wifi appears to show up as DEV_ID=0x20 on the bus, and otherwise speaks the same protocols as the hand-controller and other devices do.  Good!

 

 

So next up will be to have a quick peek at the IP packets (most likely TCP on top of IP) going back and forth and see if they use the same raw AUX bus protocol, or if a bit of translation is needed from one side to the other.

 

The ESP32 board I first acquired for this job is faulty -- repeated boot loop whenever bluetooth is enabled -- so it's going back to Amazon and a replacement is on the way for this coming week.

 

I expect to first try and get Wifi going, because that's all that SkyPortal seems to grok.  But I'd very much prefer to use bluetooth, so that the smartphone  1) can stay internet connected where feasible, and 2) will stop complaining that the Telescope doesn't provide internet connectivity!   Skyportal doesn't do bluetooth, but SkySafari apparently does.  There's also an Android app out there which can be used to redirect bluetooth to make it appear to be coming from an IP address (eg. wifi) instead -- if that works, then this would enable a bluetooth connection to work with SkyPortal!  Yay!

 

For easy reference, here's a link to the (paid, but cheap) BT/USB/TCP Bridge Pro app for bridging connections on Android:

https://play.google....ge.pro&hl=en_US

 

More when I have more.  Feel free to join in.

 

Cheers!

Edited by mlord, 06 December 2020 - 04:34 PM.

[mlord]

Next up: I have connected my Linux notebook to the mount over wifi, and then run "nmap" on it to look for obvious connection ports:

Starting Nmap 7.60 ( https://nmap.org ) at 2020-12-06 13:58 EST
Nmap scan report for _gateway (1.2.3.4)
Host is up (0.013s latency).
Not shown: 998 closed ports
PORT     STATE SERVICE
2000/tcp open 
3000/tcp open
MAC Address: 4E:55:CC:1A:xx:xx (Unknown)
Nmap done: 1 IP address (1 host up) scanned in 7.95 seconds

Port 2000 is the usual one I believe for SkyPortal and the like.

But there's also port 3000.  I wonder what that one is for?

 

I'm going to hard-code a command or two for the mount, and just inject them into those ports to see what happens..

Edited by mlord, 06 December 2020 - 02:05 PM.

[mlord]

Oooh.  Okay, port 3000 is the maintenance/control portal for the wifi adapter itself:

[~] telnet 1.2.3.4 3000
Trying 1.2.3.4...
Connected to 1.2.3.4.
Escape character is '^]'.
> help
Help options for the ZentriOS Command API ...
  help commands   -> Print a list of Commands
  help variables  -> Print a list of readable Variables
  help <command>  -> Print help for a specific Command
 
  Additional help is available online at http://docs.zentri.com
> help commands
dms                : dms
exit               : exit
factory_reset      : fac
faults_reset       : faur
faults_print       : faup
file_create        : fcr
file_delete        : fde
file_open          : fop
file_stat          : fst
format_flash       : format
get                : get
gpio_dir           : gdi
gpios_get          : gges
gpio_get           : gge
gpio_set           : gse
help               : ?
http_download      : hdo
http_add_header    : had
http_get           : hge
http_head          : hhe
http_post          : hpo
http_read_status   : hre
http_upload        : hup
load               : load
ls                 : ls
network_down       : ndo
network_lookup     : nlo
network_restart    : nre
network_up         : nup
ota                : ota
ping               : ping
reboot             : reboot
save               : save
set                : set
setup              : setup
sleep              : sleep
stream_close       : close
stream_list        : list
stream_poll        : poll
stream_read        : read
stream_write       : write
tcp_client         : tcpc
tls_client         : tlsc
tcp_server         : tcps
uart_update        : uartu
udp_client         : udpc
wlan_get_rssi      : rssi
wlan_scan          : scan
version            : ver
Command failed
>
> help variables
get     all                            :
get/set broadcast.data                 : br d
get/set broadcast.http.host            : br h h
get/set broadcast.interface            : br i
get/set broadcast.interval             : br t
get/set broadcast.udp.ip               : br u a
get/set broadcast.udp.port             : br u p
get/set bus.command.rx_bufsize         : bu c r
get/set bus.command.tx_bufsize         : bu c t
get/set bus.mode                       : bu m
get/set bus.stream.cmd_gpio            : bu s g
get/set bus.stream.cmd_seq             : bu s s
get/set bus.stream.flush_count         : bu s c
get/set bus.stream.flush_time          : bu s t
get/set bus.stream.flush_time_reset    : bu s r
get/set dms.bundle_id                  : dm b
get/set gpio.init                      : gp i
get/set gpio.usage                     : gp u
get/set http.server.api_enabled        : ht s a
get/set http.server.cors_origin        : ht s c
get/set http.server.enabled            : ht s e
get/set http.server.interface          : ht s i
get/set http.server.max_clients        : ht s m
get/set http.server.notfound_filename  : ht s n
get/set http.server.port               : ht s p
get/set http.server.root_filename      : ht s r
get/set ioconn.enabled                 : io e
get/set ioconn.remote_host             : io h
get/set ioconn.remote_port             : io r
get/set ioconn.local_port              : io l
get/set ioconn.control_gpio            : io c
get/set ioconn.status_gpio             : io s
get/set ioconn.protocol                : io p
get/set network.default_interface      : ne f
get/set network.tls.ca_cert            : ne t a
get/set network.tls.client_cert        : ne t c
get/set network.tls.client_key         : ne t k
get/set network.tls.version            : ne t v
get/set ntp.enabled                    : nt e
get/set ntp.interface                  : nt f
get/set ntp.interval                   : nt i
get/set ntp.server                     : nt s
get/set remote_terminal.enabled        : re e
get/set remote_terminal.password       : re w
get/set remote_terminal.port           : re p
get/set remote_terminal.timeout        : re t
get/set setup.gpio.control_gpio        : se g g
get/set setup.web.idle_timeout         : se w i
get/set setup.web.passkey              : se w p
get/set setup.web.root_filename        : se w r
get/set setup.web.ssid                 : se w s
get/set setup.web.url                  : se w u
get/set softap.auto_start              : so a
get/set softap.channel                 : so c
get/set softap.client_list             : so l
get/set softap.dhcp_server.enabled     : so d e
get/set softap.hide_ssid               : so h
get/set softap.idle_timeout            : so t
get/set softap.info                    : so o
get/set softap.passkey                 : so p
get/set softap.ssid                    : so s
get/set softap.static.gateway          : so t g
get/set softap.static.ip               : so t i
get/set softap.static.netmask          : so t m
get/set system.build_number            : sy n
get/set system.cmd.echo                : sy c e
get/set system.cmd.header_enabled      : sy c h
    set system.cmd.mode                : sy c m
get/set system.cmd.prompt_enabled      : sy c p
get/set system.gotosleep.timeout       : sy s t
get/set system.indicator.gpio          : sy i g
get/set system.indicator.state         : sy i s
get     system.memory.usage            : sy e u
get/set system.oob.event_mask          : sy o e
get/set system.oob.gpio                : sy o c
get/set system.oob.gpio_level          : sy o l
get/set system.oob.rising_edge_mask    : sy o r
get/set system.oob.status              : sy o s
get/set system.print_level             : sy p
get/set system.safemode.disabled       : sy s d
get/set system.safemode.status         : sy s s
get/set system.uuid                    : sy u
get/set system.version                 : sy v
get/set system.wakeup.timeout          : sy w t
get/set tcp.client.auto_retries        : tc c e
get/set tcp.client.auto_start          : tc c a
get/set tcp.client.connect_timeout     : tc c t
get/set tcp.client.connected_str       : tc c c
get/set tcp.client.disconnected_str    : tc c d
get/set tcp.client.local_port          : tc c p
get/set tcp.client.remote_host         : tc c h
get/set tcp.client.remote_port         : tc c o
get/set tcp.client.remote_send         : tc c s
get/set tcp.client.retries             : tc c r
get/set tcp.client.retry_period        : tc c w
get/set tcp.client.tls_enabled         : tc c s
get/set tcp.server.auto_start          : tc s a
get/set tcp.server.connected_gpio      : tc s c
get/set tcp.server.data_gpio           : tc s d
get/set tcp.server.idle_timeout        : tc s t
get/set tcp.server.port                : tc s p
get     time.last_set                  : ti l
get/set time.rtc                       : ti r
get     time.uptime                    : ti u
get/set time.zone                      : ti z
get/set uart.baud                      : ua b
get/set uart.data                      : ua d
get/set uart.flow                      : ua f
get/set uart.parity                    : ua p
get/set uart.stop                      : ua s
get/set udp.client.auto_interface      : ud c i
get/set udp.client.auto_start          : ud c a
get/set udp.client.remote_host         : ud c h
get/set udp.client.remote_port         : ud c p
get/set wlan.auto_join.enabled         : wl o e
get/set wlan.auto_join.retries         : wl o r
get/set wlan.auto_join.retry_delay     : wl o d
get/set wlan.dhcp.enabled              : wl d e
get/set wlan.dhcp.hostname             : wl d h
get/set wlan.hide_passkey              : wl h
get/set wlan.info                      : wl i
get/set wlan.join.timeout              : wl j t
get/set wlan.join.retries              : wl j r
get/set wlan.mac                       : wl m
get     wlan.network.dns               : wl n d
get     wlan.network.gateway           : wl n g
get     wlan.network.ip                : wl n i
get     wlan.network.netmask           : wl n n
get/set wlan.network.status            : wl n s
get/set wlan.passkey                   : wl p
get/set wlan.rate.protocol             : wl r p
get/set wlan.ssid                      : wl s
get/set wlan.static.dns                : wl t d
get/set wlan.static.gateway            : wl t g
get/set wlan.static.ip                 : wl t i
get/set wlan.static.netmask            : wl t n
get/set wlan.tx_power                  : wl t

Edited by mlord, 06 December 2020 - 02:16 PM.

[mlord]

This looks very promising:

> stream_list
! # Type  Info
# 0 TCPS  1.2.3.4:2000 1.2.3.6:48131
>
> get all
...
tcp.server.auto_start: 1
tcp.server.connected_gpio: 5
tcp.server.data_gpio: -1
tcp.server.idle_timeout: 3600
tcp.server.port: 2000
...

The idle_timeout could be a helpful thing here:  it is set to an hour (3600 seconds) by default.   Just for experimentation, I changed it:

> set tcp.server.idle_timeout 15
Set OK
> save
Success
> reboot

Instant effect!  Now when SkyPortal loses communications with the scope, one can just reconnect instead of having to reset the mount!  15-seconds is probably a bit short (but was good for testing).  I think I'll try longer, say 60-seconds.  That way it's a minute wait at most before the app will be able to reconnect after a failure.

There's also a built-in web server interface to much of this.  One can enable it thusly:

> help setup
Usage   : setup web
Shortcut: setup
> setup web
In progress

After which.. http://1.2.3.4/ yields a rich web interface to the wifi adapter.

Edited by mlord, 06 December 2020 - 04:31 PM.

[mlord]

[EDIT] Mmm.. despite the save command, the mount seems to restore the original 3600 setting on each power-cycle.  Oh well.[/EDIT]

 

This discovery is important enough that I'm going to summarize it again here:

 

The SkyPortal app frequently loses its connection to the wifi in the Evolution mount.  This can happen for a variety of reasons, many of which are out of the user's control.  When this happens, one generally has to power-cycle the mount before a connection can be re-established, losing sky alignment in the process.  Bad.

 

A decent workaround for this with the built-in Zentri wifi of the Evolution mount is to do this:

 

1. Connect a PC to the mount over wifi.  I'm using a Linux PC here, but anything with a telnet command should work.

2. Now from a terminal window on the PC, connect to the Celestron wifi maintenance port over telnet:

 

    telnet 1.2.3.4 3000

 

3. Once connected, change the connection timeout from 3600 to something more reasonable, say 60 seconds:

 

   set tcp.server.idle_timeout 60

   save

   reboot

 

4. Exit from the telnet session, or just close the terminal window on the PC.

 

The above change is permanent, at least until you repeat the steps to change the value again.  Actually, next power-on restores the original 3600 value.  Ugh.

 

The effect of this change is that, when the SkyPortal smart-phone app loses connection to the scope, one can then simply tap "CONNECT" from within the app to re-establish communications.  Normally, this wouldn't work unless one waited an hour before retrying.. duh.

 

There have apparently been at least three versions of built-in wifi on the Evolution mounts.  Mine has the Zentri version.  If yours is different, then the above steps probably won't do anything.

 

Edited by mlord, 06 December 2020 - 05:22 PM.

[mlord]

Well, at least I can script the changing of the tcp.server.idle_timeout value on my smart-phone.  But that's probably a bit tricky for some to get working.  I use an app called SManager on my phone, and have configured it to run this script (with su) at the touch of a widget:

#!/system/bin/sh
## Fix network timeout on Celestron Wifi:
telnet 1.2.3.4 3000 << EOF &
set tcp.server.idle_timeout 60
save
reboot
EOF
sleep 2
kill $!
exit 0

So I can just tap that widget once before starting SkyPortal, and timeouts are then taken care of until the next time the mount loses power.
 

[skaiser]

mlord

 Here is some "history" of the Celestron WiFi modules.

Quick Note.

Sounds like you have the 2nd gen wifi which is NOT updateable. Which is why your TIMEOUT change doesn't "Stick"

 

------------

There have been 3 generations.
The version numbers are confusing because they used different systems in different generations.

The first generation had the Roving Network parts. CFM will identify first generation modules as a SkyQLink (RN-171).

The second generation parts were developed by ACKme. CFM will identify second generation parts as WiFi Accessory (AMW006). ACKme was purchased by Zentri, shortly after launch and the second generation modules and so the second generation modules are better known in the forums as "Zentri" parts. Zentri was purchased by Silicon Labs shortly before we stopped shipping the second generation modules.

The third generation products were purchased directly from Silicon Labs. CFM will identify third generation modules as Wifi Accessory (AMW007). SiLabs kept most of the talent from Zentri in the acquisition, but the name "Zentri" and "Zentri OS" are no longer used.

 

The 1.x software was never updateable. Nor was it intended to be. That was a mistake.
The 2.x software used different hardware and was supposed to be updatable. Unfortunately, the person in charge of that project didn't test that before we launched.

The 3.x software uses another kind of hardware that includes a dedicated bridge circuit. Both the bridge and the WiFi module can be updated (requires CFM version 2.7.8088 or later for best results).

 

---------------------

Also for those interested.

Finally, a More Modern Terminal For Windows
At Build 2020 on May 19, 2020, Microsoft announced that the new Windows Terminal was stable and “ready for enterprise use.”

You can download the Windows Terminal from the Microsoft Store. You can even get the source code on GitHub. Yes, the new Windows Terminal is even open-source.

-------------------------

 

Looks like fun project.

Take care

Edited by skaiser, 07 December 2020 - 12:47 PM.

[robglinka]

Nice work! Hopefully someone at Celestron sees this and integrates some of your findings into the next firmware patch.

[mlord]

Sounds like you have the 2nd gen wifi which is NOT updateable. Which is why your TIMEOUT change doesn't "Stick"

Some variables "stick" across power-off though.  Eg. Setting a password on the port 3000 interface.  But NOT setting a password on the softap wifi.

[mlord]

The 1.x software was never updateable. Nor was it intended to be. That was a mistake.

The 2.x software used different hardware and was supposed to be updatable. Unfortunately, the person in charge of that project didn't test that before we launched.

The 3.x software uses another kind of hardware that includes a dedicated bridge circuit. Both the bridge and the WiFi module can be updated (requires CFM version 2.7.8088 or later for best results).

Skaiser, perhaps you can enlighten me on something related:  does the app (eg. SkyPortal, SkySafari) send HC commands over the wifi, and the "bridge" translates those to AUX commands/protocol?  Or does the app have to speak native AUX bus?

 

I'll figure it out anyway, but if you already know it could save a bit of sleuthing here. 

Edited by mlord, 08 December 2020 - 08:29 AM.

[skaiser]

Mlord

 sorry. I don’t have any in depth information on that.

you might check on Mike swanson’s  nexstarsight.com.

he has a lot of. Celestron/ nexstar information.

I have a evo system, but I keep it at my daughters in Utah.

next time I’m out there I’ll have try out the Windows terminal program on the built in WiFi module to see what it says.

i might also poke at my SkyPortal WiFi module I use on my cgx mount. 
i believe it’s a 3rd gen unit .

be interesting to see how it responds to telnet communication.

take care

steve

[mlord]

does the app (eg. SkyPortal, SkySafari) send HC commands over the wifi, and the "bridge" translates those to AUX commands/protocol?  Or does the app have to speak native AUX bus?

So, to answer my own question here now..  I connected my smart-phone to the EVO mount over wifi, and ran tcpdump -w /sdcard/log.pcat and then did a bunch of slew operations from SkyPortal.   The log.pcat capture file then got transferred over to my Linux machine, and loaded into WireShark for analysis.  Lots of unexpected crap in there, so I filtered the display using tcp.port==2000 to show only the scope communications.

 

The result?  When using Wifi to my EVO mount, SkyPortal speaks "native AUX bus".   Each command/response begins with 3B and matches the AUX bus protocol exactly.  This will make it very easy to implement a custom Wifi adapter, since very little in the way of "smarts" is needed there.

 

Not so sure about bluetooth now though.  I would really prefer to use bluetooth, avoiding all of the smart-phone wifi issues and maintaining a constant internet connection in the process.   But the native bluetooth support in SkySafari is likely only for hand-controller protocol, not AUX bus.  I can use an app on my phone to redirect bluetooth to make it appear to have come from the scope wifi, which would work, but that app currently doesn't allow arbitrary hard-coded IP addresses.  SkyPortal will expect to see 1.2.3.4 there.  Dunno about SkySafari yet.  So, more thought required there.

 

I can (and will) of course hack a Nexstar+ HC to build-in bluetooth on it, which should work fine, but that uses more (battery) power and involves having a HC dangling from the mount.
 

Edited by mlord, 08 December 2020 - 03:45 PM.

[mlord]

Another discovery:  While testing with SkyPortal today, I forgot to set the shorter TCP timeout.  Yet, the connection with the EVO behaved admirably with no disconnects.  It turns out that this was because the smart-phone was plugged into my PC at the time (for capturing packets) and thus was receiving external power.

 

So I unplugged it and tried again:  got a disconnect error quite quickly.

 

Solution to this:  when using the Telescope over wifi, just ensure that the smart-phone is plugged into some form of external power.  I don't want mine tethered to the mount (tangled cord issues..), but a small power-pack in my pocket will do the trick.  This should work even without fixing the timeout value.

Edited by mlord, 08 December 2020 - 03:52 PM.

[mlord]

Some progress.  I have interfaced the ESP32 dev board to the AUX bus, and can receive and send packets over the bus.  The electrical interface is actually even safer now than in my previous projects.  I've added 330ohm resistors between the circuit and the AUX bus on the TX, RX, and RTS pins, as a safeguard against over-driving should there ever be a problem.

 

Also, since the mount uses pull-ups on all of the AUX bus signals, it is only necessary to drive them LOW when sending zeros, and just let the bus passively go HIGH when sending ones by tri-stating the pins.  This is probably how it is supposed to be done, though I won't be revisiting my previous circuits.

 

The 74HC125 chip is used here to manage the voltage level conversion from 5V (AUX) to 3.3V (ESP32 processor), and also to do the tri-stating as needed.

 

 

Next up is to actually implement the Wifi bridge software stuff!

Edited by mlord, 10 December 2020 - 04:09 PM.

[mlord]

Curiously, the circuit pictured above works fine with both the 6se and Evo-8 mounts.  Unless I also plug in the logic analyser, at which point it doesn't work even though everything else continues to.  It will also work in combination with the GPS accessory I made, plugged in separately.  But not with the logic analyzer.

 

My guess is that the 3.3V logic levels it sends to the mount are not quite powerful enough to overcome whatever impedance the analyzer adds.  So signal levels are probably marginal there.  I may end up rewiring slightly and adding a 5V PSU for the 74HC125 so that it can send 5V logic to the mount, which will make it more robust overall.

 

EDIT:  Found it.  Cabling artifact from the logic analyzer setup.  Fixed.  All good now!

 

Stay tuned.  I hope this is at least interesting to someone other than myself! 

Edited by mlord, 09 December 2020 - 11:32 PM.

[SanjeevJoshi]

MLord, interesting stuff.  Wanted to share my observations from testing WiFi on new Evo 8 and new WiFi dongle on AVX.

 

WiFi drop seems to be driven by how Celestron WiFi hardware hand shakes with a device’s WiFi when device WiFi is subject to some power management related change.   The behavior is also different based on the device.

 

for example, any laptop pretty much drops connection when some power management feature kicks in, either on battery power or after idle time.

 

on my Alienware which has an Intel WiFi chip, I was able to fix by simply turning off the power management savings for the WiFi due to idle or battery power.

 

on my Asus which runs a different WiFi chip, no possible settings down to bios level made any difference - the connection would drop.  The workaround I found via testing was to turn off the Asus WiFi adapter completely, get a powerful external adapter - Netgear, plug that via USB port, fix the power management settings at adapter level and power plan level and I have never dropped WiFi even as far as 75 to 100 feet away.

since this issue appears with both the mount WiFi and the WiFi dongle, wanted you to be aware of this - to confirm for example, it’s not the behavior of the aux ports.

 

Just wanted to pass this along in case it helps your project.  I have for other reasons (EAA) switched to using a mini PC at mount so I don’t need to worry about connections - I just connect mini pc to handset.  I do Windows Remote Desktop, works superbly.

 

your project is very cool!

Edited by SanjeevJoshi, 10 December 2020 - 02:48 AM.

[mlord]

Yup, that all matches my own theory and observations.

 

The issue with the Celestron wifi is that it doesn't tolerate or recover from situations where the other end of the link has dropped due to power management (or whatever).  Having to reboot the mount, and then re-do alignment, simply to re-establish communications is a major fail! 

 

The time-out workaround (described earlier here) mitigates this considerably, and even just the ability to script a "reboot" command to the Celestron wifi (doesn't affect the mount itself) is useful to recovery semi-gracefully.

 

In my case, I only connect from a smart-phone, so it is relatively easy to just "plug in" the smart-phone to an external power pack and thus avoid having it do very much power management -- in my case this works exceptionally well.

 

But now that I'm into it, I will complete the home-brew Wifi adapter project, which will not have the same issues as the Celestron wifi.  It'll also be cheaper than buying the Celestron adapter for the 6se/8se/cpc/etc, for those who are capable of following the recipe developed here.  I am also going to combine my earlier home-brew GPS accessory with the new Wifi circuit for all-in-one convenience.

 

Once SkyPortal-7 is available, I will likely purchase that and see if a way can be worked out to use bluetooth (from the AUX bus) with that instead of wifi --  it should be much more reliable and appropriate for this application.

Edited by mlord, 10 December 2020 - 01:27 PM.

[mlord]

Here's another discovery:

 

I had previously used CFM to update my Evolution-8 just last week (twice, even!), so I had assumed it was already running the latest of all firmwares for it.  But.. no.

 

I ran CFM again just now, and it updated things further than before, including the "motor firmware" (really, the "mount firmware") including the built-in Wifi Adapter.   This update has been out for a while, so not sure why it didn't install it last week -- perhaps they have to be done incrementally or something.

 

Anyway, among the Change Log fixes for the Wifi was this one:

"7.15.9120  July-2019  Bug Fix: WiFi would lock up if user lost connection to WiFi attempted to reconnect".

 

So, I quickly telnet'd to port 3000 for a look (see earlier in this thread), and now I see the default tcp.server.idle_timeout is a far more reasonable 30 seconds rather than the 3600 seconds from the older firmware.   Ha!  So they had already fixed it more than a year ago!

 

Summary:  If you haven't already, update your mount firmware (using CFM) to the latest version, currently 7.17.0098.  Contrary to outdated instructions on the web, MCupdate.exe was not necessary for this.  Just CFM.

 

Note: according to CFM, the built-in wifi in my EVO-8 is actually "AMW007 WiFi module (3rd generation)".

 

Cheers

 

PS: Important tip: unplug any custom AUX bus accessories (eg. homebrew GPS) before doing the update.  If you forget, then let it finish, power-off, unplug the accessories, and re-do the CFM and it will fix stuff up again.  Don't ask me how I know this. 

Edited by mlord, 10 December 2020 - 02:42 PM.

[mich_al]

 I hope this is at least interesting to someone other than myself! 

It's interesting to me,  I've been tracking the thread hoping to learn something.  My Bluetooth & WIFI acumen isn't what it could be.

[mlord]

.. among the Change Log fixes for the Wifi was this one:

"7.15.9120  July-2019  Bug Fix: WiFi would lock up if user lost connection to WiFi attempted to reconnect".

 

So, I quickly telnet'd to port 3000 for a look (see earlier in this thread), and now I see the default tcp.server.idle_timeout is a far more reasonable 30 seconds rather than the 3600 seconds from the older firmware.   Ha!  So they had already fixed it more than a year ago!

I just now checked with the web management interface on the mount wifi, and no changes in version numbers there from before.  So the wifi firmware itself appears to have not been updated, despite the new timeout setting.  My guess is that the newer mount firmware is talking to the wifi adapter and making the change at each power-on.

Edited by mlord, 10 December 2020 - 03:05 PM.

[skaiser]

So I noticed you said you seem to have a 3rd generation WiFi in your evolution.

according to celestron information, that module should have the ability to be reprogrammed.

yet when you changed the timeout value by hand , it did not seem to retain the value after power cycle.

i would assume then , that there must be a specific way (custom program) to reprogram the module.

just curious.

not as urgent a issue if they are correcting the value another way.

definitely interesting on no timeout if phone or pc WiFi is configured/powered properly.

your little project is starting to rouse my long dormant interest in circuit projects.

too many years ago my wife and and built our first computer. We literally had to solder every component into the motherboard and build our own keyboard. Soo much fun, after we got it working.

take care

Steve

[skaiser]

mlord

 Interesting effort by another posting here on site.

take a look at this thread

Celestron AUXBUS Scanner

Under this forum topic  Celestron Computerized Telescopes.

You probably already have what you need but just in case.

Take care

Steve 

[mlord]

An update:

Using the exact same hardware as pictured in post #14 of this thread, I now have simultaneous working Wifi and GPS from the ESP32.   I have left the internal Evo-8 Wifi enabled, but am ignoring it and connecting my smartphone to the HomeBrewWifi instead.  Skyportal connects and controls the telescope, but I can instead just use the HC (with GPS data) should I choose.

 

Next:

1. Tidy things up and make the code presentable for others.

2. Wire up one into a case for velcro-ing to the mount.

3. Tackle the bluetooth alternative with the same hardware.

 

Cheers

[mlord]

Another small update:

 

Using the exact same hardware as pictured in post #14 of this thread, I now have simultaneous working Wifi and GPS from the ESP32.

I have switched over to one version of the slightly smaller 30-pin ESP32 dev boards.  This enables using a regular half-size breadboard for everything, with some wires running beneath the ESP32 board.  Again, sticking with ones that have a "Vin" pin located next to the voltage regulator.

 

 

The on-board "AMS1117" 3.3V regulators seem to have issues with 12V input.  A true/genuine AMS1117 from Advanced Monolithic Systems should handle up to 15V input, so I'm guessing these ones are lower-spec'd knock-offs.  To use with 12V power from the scope, an extra 12V-to-5V conversion will be needed.   But instead, I'm going to try replacing the dubious AMS1117 regulators with TLV1117 parts, which should do the trick. Those will arrive here on Wednesday Thursday.

 

As for the Wifi project itself, there's still a bug or two to track down and fix before I release first code.  Soon!  [EDIT] Found bug in Wifi library, workaround implemented!

 

Cheers

Edited by mlord, 15 December 2020 - 09:58 AM.

[mlord]

In case anyone else here wants to join in on the fun, here (attached) is the first release of my ESP32 GPS+Wifi module on a breadboard.

 

 

This version includes an LM78HC05 voltage regulator to convert the 12V scope power down to 5V for input to the ESP32 board.  This wastes around 1.5W of power (thus the heatsink), so a DC-to-DC buck converter may be a good/easy alternative, especially one of the more compact "mini" style ones.

 

The ESP32 Arduino source code is also attached.  EDIT: updated it to v1.1.

Attached Files

•  esp32_wifi.ino.v1.1.txt   12.91KB   69 downloads

Edited by mlord, 15 December 2020 - 01:52 PM.