After a great mess of attempted fixes, this is the best path to get the DIYMall GPS to work with EKOS. My goal was to prevent hard wiring KSTARS any site. The Diymall Vk-172 vk 172 Gmouse G-Mouse USB GPS Dongle Glonass , (a mouth full), is an inexpensive GPS. This is a USB 2.0 device, only. The USB 3.0 hubs that I wanted to use (compact and small) did not work with this device.
For starters, GPSD on Astroberry is place to get running. First, look hard at what devices are needing a specific port to communicate with hardware. The DIYMall and my AstroEQ are two types of RS232 devices. The RPI3B+ is the next requirement. Websites claim this will work with 3B. I have not verified if the RPI 3B works. Parts of what I write are taken from an AMAZON review for this device.
Source: ChicagoDave (I have edited some syntac errors)
sudo apt-get update
# Install the gps daemon, libraries and NTP
sudo apt-get install gpsd gpsd-clients python-gps ntp # to install the gps daemon and the ntp server
# edit the gpsd config file
sudo vi /etc/default/gpsd
# Add/modify the following lines to the file. They may already exist so just modify. These specify the device explicitly and NTP won't work without the -n
# save/quit the above, then edit the ntp configuration file
sudo vi /etc/ntp.conf
# Add these lines to ntp.conf:
server 127.127.28.0 minpoll 4 maxpoll 4 prefer
fudge 127.127.28.0 time1 0.000 refid GPS stratum 15
# save/quit then reboot
Once that's all done you should be able to type:
...and see a full screen display with the GPS attempting to lock or locking up. If you get a timeout check your work and connections
If NTP is working you should be able to type:
...and you'll see a line in the resulting text that looks something like this:
*SHM(0) .GPS. 15 l 14 16 377 0.000 3.505 3.556
If "poll" and "reach" are zero it's not working.
Use these commands to verify the devices are properly registered.
dmesg | grep tty
setserial -g /dev/ttyACM[01}
Thank you for your reply and welcome to my world. Well, I reviewed my "evidence" on GPSD and found the issue. I now have GPSD linked to INDI_GPSD. KSTARS now is aware that it is no longer in Poland. LOL.
How I became aware of the problem was when I was attempting Polar Alignment via EKOS. It would not resolve because its starting point is in Poland. I am not by any KSTARS known site. I do have my GPS site listed in the KSTARS DB. At that night, I was in Poland according to KSTARS.
Now for another clear night. I am looking for the opportunity to Polar Align with EKOS.
It appears that I am at a standstill with the RPI 3B+ and AstroBerry. Neither will accept this GPS device contrary to the vendor and a well written HOW-TO.
The following is the syslog after a reboot about GPSD. The GPSD rule was edited to include the Vendor DIYMall and its device. In fact, the rule for GPSD is very simple. Adding a rule in /lib/udev/rules.d does not change anything. INDI_GPSD does not see GPSD rules. GPUSB does not look at GPSD rules.
This is the output using KSTARS device manager. **** is the device enumerated but ignored.
2019-07-30T17:27:32: listening to port 7625 on fd 3
FIFO: start indi_gpusb -n "GPUSB"
With name: GPUSB
FIFO: Starting driver indi_gpusb
2019-07-30T17:27:32: Driver indi_gpusb: pid=2636 rfd=4 wfd=7 efd=8
2019-07-30T17:27:32: Client 5: new arrival from 127.0.0.1:59498 - welcome!
2019-07-30T17:27:37: Driver indi_gpusb: Skipping device 04d8/000a
*****2019-07-30T17:27:37: Driver indi_gpusb: Skipping device 1546/01a7******
2019-07-30T17:27:37: Driver indi_gpusb: Skipping device 1618/0941
2019-07-30T17:27:37: Driver indi_gpusb: Skipping device 125f/db8a
2019-07-30T17:27:37: Driver indi_gpusb: Skipping device 1a40/0101
2019-07-30T17:27:37: Driver indi_gpusb: Skipping device 045e/001d
2019-07-30T17:27:37: Driver indi_gpusb: Skipping device 0451/1446
2019-07-30T17:27:37: Driver indi_gpusb: Skipping device 04f2/0939
2019-07-30T17:27:37: Driver indi_gpusb: Skipping device 1a40/0101
2019-07-30T17:27:37: Driver indi_gpusb: Skipping device 0424/7800
2019-07-30T17:27:37: Driver indi_gpusb: Skipping device 0424/2514
2019-07-30T17:27:37: Driver indi_gpusb: Skipping device 0424/2514
2019-07-30T17:27:37: Driver indi_gpusb: Skipping device 1d6b/0002
2019-07-30T17:27:37: Driver indi_gpusb: Error: No GPUSB device found
Editing GPSD and pushing it to look at the assigned port by SETSERIAL shows that GPSD is not looking at the rules.
Jul 30 13:06:31 astroberry systemd: Created slice system-gpsdctl.slice.
Jul 30 13:06:31 astroberry gpsd: gpsd:ERROR: SER: /dev/ttyAMA0 already opened by another process
Jul 30 13:06:31 astroberry gpsd: gpsd:ERROR: initial GPS device /dev/ttyAMA0 open failed
Jul 30 13:11:25 astroberry gpsd: gpsd:ERROR: SER: device open of /dev/ttyAMA0 failed: Device or resource busy - retrying read-only
Jul 30 13:11:25 astroberry gpsd: gpsd:ERROR: SER: read-only device open of /dev/ttyAMA0 failed: Device or resource busy
Jul 30 13:11:25 astroberry gpsd: gpsd:ERROR: /dev/ttyAMA0: device activation failed.
Jul 30 13:11:25 astroberry gpsd: gpsd:ERROR: /dev/ttyAMA0: activation failed, freeing device
ModemManager is worthless in this dance. I removed it. Old posts are the results of web searches for errors. They show the same errors that I was getting. The applet cannot create a modem out of a GPS nor a Tom Carpenter AstroEQ. It just can't. Despite setting up rules to IGNORE or NOT PROBE, ModemManager errors out anyway. Less noise in the logs.
LSUSB and dmesg | grep tty show that everything is connected and working.
astroberry@astroberry:~$ dmesg | grep tty
[ 0.000000] Kernel command line: 8250.nr_uarts=0 bcm2708_fb.fbwidth=1600 bcm2708_fb.fbheight=900 bcm2708_fb.fbswap=1 vc_mem.mem_base=0x3ec00000 vc_mem.mem_size=0x40000000 dwc_otg.lpm_enable=0 console=tty1 root=/dev/mmcblk0p2 rootfstype=ext4 elevator=deadline fsck.repair=yes rootwait quiet splash plymouth.ignore-serial-consoles
[ 0.000143] console [tty1] enabled
[ 0.567066] 3f201000.serial: ttyAMA0 at MMIO 0x3f201000 (irq = 87, base_baud = 0) is a PL011 rev2
[ 7.491594] cdc_acm 1-126.96.36.199:1.0: ttyACM0: USB ACM device # DIYMall USB device
[ 7.492742] cdc_acm 1-188.8.131.52:1.0: ttyACM1: USB ACM device # AstroEQ USB device
Why nothing in KSTARS sees this configuration is baffling me. In EQMount, I can set the tty device. In INDI_GPSD and INDI_GPUSB, I cannot set up the tty. With the AstroBerry GPSD not working, I am unable to confirm that INDI_GPSD is not seeing the GPSD. Neither INDI devices have logging.
Everything to shows the USB and RPI are enumerating devices correctly. AstroBerry, INDI, and KSTARS are not seeing the setup. What is missing?
I have more information to share with this site. I used Log Viewer to get this information. I think I see why this is being skipped.
Jul 28 20:31:39 astroberry kernel: [ 5638.530880] usb 1-1.2: new full-speed USB device number 6 using dwc_otg
Jul 28 20:31:39 astroberry kernel: [ 5638.663322] usb 1-1.2: New USB device found, idVendor=1546, idProduct=01a7
Jul 28 20:31:39 astroberry kernel: [ 5638.663338] usb 1-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=0
Jul 28 20:31:39 astroberry kernel: [ 5638.663347] usb 1-1.2: Product: u-blox 7 - GPS/GNSS Receiver
Jul 28 20:31:39 astroberry kernel: [ 5638.663356] usb 1-1.2: Manufacturer: u-blox AG - www.u-blox.com
Jul 28 20:31:39 astroberry kernel: [ 5638.664469] cdc_acm 1-1.2:1.0: ttyACM0: USB ACM device
Jul 28 20:31:39 astroberry mtp-probe: checking bus 1, device 6: "/sys/devices/platform/soc/3f980000.usb/usb1/1-1/1-1.2"
Jul 28 20:31:39 astroberry mtp-probe: bus: 1, device: 6 was not an MTP device
Jul 28 20:31:39 astroberry upowerd: unhandled action 'bind' on /sys/devices/platform/soc/3f980000.usb/usb1/1-1/1-1.2/1-1.2:1.1
Jul 28 20:31:39 astroberry upowerd: unhandled action 'bind' on /sys/devices/platform/soc/3f980000.usb/usb1/1-1/1-1.2/1-1.2:1.0
Jul 28 20:31:39 astroberry systemd: Starting Manage ttyACM0 for GPS daemon...
Jul 28 20:31:39 astroberry upowerd: unhandled action 'bind' on /sys/devices/platform/soc/3f980000.usb/usb1/1-1/1-1.2
Jul 28 20:31:39 astroberry systemd: Started Manage ttyACM0 for GPS daemon.
Jul 28 20:31:50 astroberry ModemManager: <info> [device /sys/devices/platform/soc/3f980000.usb/usb1/1-1/1-1.2] creating modem with plugin 'u-blox' and '1' ports
Jul 28 20:31:50 astroberry ModemManager: <warn> Could not grab port (tty/ttyACM0): 'Cannot add port 'tty/ttyACM0', unhandled serial type'
Jul 28 20:31:50 astroberry ModemManager: <warn> Couldn't create modem for device '/sys/devices/platform/soc/3f980000.usb/usb1/1-1/1-1.2': Failed to find primary AT port
What steps are necessary for RS232 devices?
I have an AstroEQ device. It is an RS232 device. I did not have any issue setting the AstroEQ up.
AstroBerry sees the UBlox device and assigns the appropriate port. GPUSB enumerates the Vender ID. The log says skipping the Ublox.
For the AstroEQ, AstroBerry sets up a RS232 communication. With Ublox, I am not finding RS232 communication artifacts.
This might be Bluetooth RS232 vs all other RS232. I am going to see if rules to push the dance of the RS232 devices.
Any research on RPI and number of devices possible is fruitless. The available ttyACM* is just 00 and 01. I am going to test values in Rules.
This link is to the device. The details on how to talk with the device are provided.
The site says the device is RPI ready. It does work and is USB 2.0 only. A software package is described on this site.
The SUDO issue is resolved. I was able to find the problem. The BASH_PROFILES had a pipe to &> /dev/null. I removed this and the output came back after a reboot.
A bad DEB package was preventing DEB packages from running. Removal of the errant install allow DEB to work.
The QHY5LII is dead as said under EZ Cypress tools and Windows 10. Cypress Express tools requires nearly all tools to be run as Administrator. This is an old and now dead device. We can mark this closed.
DMESG shows the DIYMall USB GPS GLO/NOSS device as attached to Serial 0. Lssub enumerates this device as an attached USB device. I have specific rule for this device called out.
The driver GBUSB looks at the device and says SKIPPING. What must this device need in rules or Astroberry config to be recognized by GPUSB?
I have a similar discussion in EKOS. But this is centers on AstroBerry and RPI 3B+.
I have a DYI USB GPS that is pinging away that it has a lock. EKOS does not seek it. GPSD does see it. Must I make a rule for EKOS to see it? What should that rule say?
Yes. OaCapture, version 1.61, has several QHYCCD files. One is specific to rules. This is my source of the extra QHYCCD rule file.
The OaCapture rule file adds some good items to me. They helped get both PoleMaster and QHY5LII to be recognized by INDI. Then again, it could be source of my problems in the first place. The specific new vendor identifiers were not in either QHYCCD rule file. Both devices were 1 and not 0, 0921 and 0941.
INDI right out of the box supports both devices. I found this out when I blew up my RPI 3B+ using a different PSU. Bummer. I have a backup RP3B and the QHYCCD device were recognized.
I think mine has a dead CMOS camera. Once energized, the red light is bright. EKOS loads and my gear is recognized. The light goes out. EKOS no longer sees the device until I reset the power with a hard boot. I am use the supplied cable.
Look for the red light on the device. When first plugged in, the light is red. For me, when I select record, the light goes out. With the light out, the messages of “No QHY product found. Is it powered on?”
I am going to attempt the fxload update. Something is shutting the QHY5LII-C to off. Under Windows the same power off happens when recording. I am fast coming to the conclusion the QHY5LII model is abandoned to Windows 7. EOL hardware is the result.
I apologize if this has been discussed. In building an AstroBerry RPI3B+, I had two QHYCCD cameras, PoleMaster and QHY5LII-C. With EKOS and powered, telescope has the guide scope selection. Going to polar align and the guide scope is there. The option to change to a different scope is not offered. Should guide and polar scopes be more flexible?
I seem to be in a repeatable cyclical pattern of diminishing returns with RPI3B+ and AstroBerry.
The troubles that are mounting are OS related. The first area is Swap File. The AstroBerry GUI doesn’t have a path to set it to any other device. Command line does work. A GUI front end to troubleshoot issues would be nice. Warnings about the swap file on the same partition as the OS are valid.
The second is sudo. Sudo has stopped displaying its output. Hmm... Did an update kill echo out?
The third is DEB files. I am getting repeated error messages attempting to install any DEB file. Software Index is broken. Check that 1) for broken packages = none, 2) the rights to some directory/file is corrupted = Chmod 777 = no change, 3) or the file /etc/apt/sources.lists is corrupt. Every suggested remedy does not work. With a dead sudo, any sudo apt-get install -f returns to command line. Any errors should show up in some OS log. None are found to justify the error message.
The fourth is boot console. Raspi-config changes to look for Left Shift are ignored to get to boot repair console.
I am going to start with deleting the swap file. I have a spare USB drive to place the swap file.
The start of these troubles is attempting to get a brain dead QHYCCD QHY5LII to work in EKOS. Bought new, The QHYCCD device shuts down when asked to SNAP or RECORD any object. EKOS sees the device, gets its details, and connected. Ask it to live stream or record and nothing is placed in the SER files. The QHY5LII light goes out. This looks like a mismatched Firmware. Nope. Under Windows 10 and RUN AS administrator, every QHYCCD tool causes the light to go out.
OaCapture was claimed by the OS to be an installed app without a resource. Sudo apt-get update does not find oaCapture. Running gdebi to uninstall yields the Software Index is broken.
Supposedly, QHYCCD and the vendor are working the QHY5LII issue. Getting AstroBerry stable now is my focus. What options are available to turn of AstroBerry to back to Ubuntu-Mate for troubleshooting? The reverse should get me back to AstroBerry. Thank you.
I have two QHY products. QHY5L-II-C and Polemaster are attached to my Ubuntu-Mate for RPI3B+. I looked at the DEBUG for INDI_QHY_CCD and am seeing some problems.
The DEBUG file is filled with this.
DEBUG 169.822986 sec : [QHY CCD POLEMASTER-00d7] QHYCCD|QHY5LIIBASE.CPP|GetLiveFrame|GetLiveFrame pW=1280 pH=960 pBpp=8 pChannels=1
This says that the QHY5LII is attempting to setup the PoleMaster as a QHY5LII. Nope. This explains why my QHY5LIIC is not working. It should be pointing to (QHY CCD QHY5L-II-C]. I am puzzled if I have a missmatch somewhere.