Hi Razor, Chris
I've been following this thread with interest and may have some useful info here. But before going into details, first and foremost I would like to thank Chris and the team at Atik for going down the AtikAir path and putting together some first rate software to help us do our Astrophotography. The detailed analysis that follows is provided purely to help flush out the last few little bugs and get everything really robust.
I recently set up a Pi 3 B 1GB RAM 8GB SD card with AtikAir (image method) and connected it via a good cat6 Ethernet cable to a managed switch. Initially I just used it exactly as specified in the instructions - no mods. It didn't work even though the router had given it an address via DHCP (192.168.1.139) and logged it offering the name 'raspberrypi' .
The AtikAir App (recently installed via 4.1.0.9 setup on a PC with very little software on it) didn't find it. Even if I used the Set IP option, the Remote button showed 'Not Available'. I tried ArtemisCapture and it couldn't connect. Also tried the App from the PC that normally drives my scope - lots of stuff connected and a horribly messy software environment but it behaved the same (also setup 4.1.0.9)
I connected to the Pi via ssh using PuTTY from a PC and found a few things to go after.
/var/log/daemon.log shows the services AtikAirService and ArtemisHscService falling over as Razor found. I looked for possible causes, focusing on what might be different between the development environment and homed in on the network setup - as noted by other threads.
/etc/network/interfaces referenced two wifi adaptors with manual addressing, both to be configured from /net/wpa_supplicant/wpa_supplicant by wpa-conf ...but that file was missing - presumably deleted to avoid giving out the wifi password at development location. I edited /net/interfaces to just have the one wireless adaptor using dhcp and put in a wpa_supplicant file using WPA2 with SSID and password to match and rebooted. The router renewed the old lease 1.139 for the copper and gave out 1.30 for the wifi. Fortunatley the Pi's Linux setup seems very tolerant of multiple network interfaces and doesn't seem to need careful routing setup to live like that.
Went back to AtikAir app ... and still couldn't find the Pi... and Remote still shows 'Not Available' BUT ... Artemis Capture finds the camera (recent Atik 460) and can connect. I expected to find the AtikAirService and ArtemisHscService services now stable but they still failed 5 mins after startup - or at least they make that entry in the logs. Strange. Here's the status with log extract via systemctl:
root@raspberrypi:/var/log# systemctl status -l ArtemisHscService.service
● ArtemisHscService.service - (null)
Loaded: loaded (/etc/init.d/ArtemisHscService)
Active: failed (Result: timeout) since Sun 2016-11-20 16:02:51 UTC; 2 days ago
Process: 487 ExecStart=/etc/init.d/ArtemisHscService start (code=killed, signal=TERM)
Nov 22 23:47:16 raspberrypi ArtemisHscService[487]: Send100ms: 890165
Nov 22 23:47:16 raspberrypi ArtemisHscService[487]: Big Message Sent!!
Nov 22 23:47:16 raspberrypi ArtemisHscService[487]: ProcessMessage: 401
Nov 22 23:47:16 raspberrypi ArtemisHscService[487]: -- StartExposureReceived
Nov 22 23:47:16 raspberrypi ArtemisHscService[487]: Start Exposure: 1912 240.00ms (200558442)
Nov 22 23:47:16 raspberrypi ArtemisHscService[487]: Image NOT Ready
Nov 22 23:47:16 raspberrypi ArtemisHscService[487]: --Switch to First
Nov 22 23:47:16 raspberrypi ArtemisHscService[487]: ProcessMessage: 1202
Nov 22 23:47:16 raspberrypi ArtemisHscService[487]: ProcessMessage: 1204
Nov 22 23:47:16 raspberrypi ArtemisHscService[487]: ProcessMessage: 1301
root@raspberrypi:/var/log#
HOWEVER ArtemisCapture works well now and robustly captures images - more on this in a second. Looking for the daughter processes from the service scripts - they are still up:
# ps -ax
477 ? Ss 0:00 /sbin/wpa_supplicant -s -B -P /run/wpa_supplicant.wlan0.pid -i wlan0 -D nl80211,wext -c /etc/wpa_supplicant/wpa_supplicant.conf
496 ? Sl 0:49 /usr/lib/artemishscservice
497 ? S 0:00 /usr/lib/atikairservice
584 ? S< 0:00 [kworker/3:1H]
662 ? S< 0:00 [kworker/u9:0]
663 ? S< 0:00 [hci0]
664 ? S< 0:00 [hci0]
665 ? S 0:00 /usr/bin/hciattach /dev/serial1 bcm43xx 921600 noflow -
666 ? S< 0:00 [kworker/u9:1]
670 ? Ss 0:00 /usr/lib/bluetooth/bluetoothd
815 ? Ss 0:00 /sbin/dhcpcd -q -w
816 ? Ss 0:00 /usr/sbin/sshd -D
832 ? Ss 0:00 /usr/sbin/ntpd -p /var/run/ntpd.pid -g -u 106:111
838 tty1 Ss+ 0:00 /sbin/agetty --noclear tty1 linux
921 ? Ss 0:00 dhclient -v -pf /run/dhclient.wlan0.pid -lf /var/lib/dhcp/dhclient.wlan0.leases wlan0
1068 ? Ss 0:00 sshd: pi [priv]
1074 ? R 0:00 sshd: pi@pts/0
1076 pts/0 Ss 0:00 -bash
1089 pts/0 S 0:00 su
1094 pts/0 S 0:00 bash
:
... and they've stayed up. I set ArtCap looping and took 1439 1min images on the low software PC on the same switch over 27hours. I killed that connection and then connected to the same Pi from my scope PC, 4 switches away and downloaded 364 4min images in the following 25h and its still running as I write this. Although the managed switch shows no errors on the Ethernet connection to the Pi itself, it has ridden through DHCP lease renewals that killed the PuTTY connection but the images just keep coming rock steady. Mean time the two daughter processes are still there, with the artemishscervice process having clocked up 186 mins CPU - still the same process:
root@raspberrypi:/var/log# ps -ax | grep atik
497 ? R 1:39 /usr/lib/atikairservice
29464 pts/0 S+ 0:00 grep atik
root@raspberrypi:/var/log# ps -ax | grep arte
496 ? Sl 186:18 /usr/lib/artemishscservice
29466 pts/0 S+ 0:00 grep arte
root@raspberrypi:/var/log#
Also no memory growth (VIRT stuck in the band 91064 - 102872, %MEM 3.0 and same CPU fraction 5.5 to 6%). Dead impressed. Hope this helps iron out the last few bugs in the setup and service wrapper and especially the UI on the App. The USB comms and network link to the PC look to be solid when they get going properly.
Gerry
Aiming to post more on interfaces and wpa_supplicant files separately when I have more time as image users wanting to avoid too much Rasp Pi detail may want these and they are a little tricky especially matching to router setup.