Manually Entering Location/Time via web interface stops solving

[tranquilaxolotl]

Software Version: 1.11.2 Alt-Az Mode PiFinder in Flat Configuration.

When manually entered GPS position through website LOCATE screen still shows "Searching for GPS...." When proper GPS lock is established it seems problem goes away.

After manually entering GPS coordinates, GPS indicator on top of the screen stops flashing,

This problem limits PiFinder as being useful for Grab&Go, I observe from deck and area is obstructed by building/trees resulting in very long wait times for GPS lock (sometimes up to 30minutes)

[cdSheriff]

Able to duplicate bug in a different form, driven through PiFinder w/out webpage interface and driven through SkySafari. here are the SW/HW details:

• Rpi 4
• PiSugar S Plus
• 1.11.2 built fresh from release .img
• PiFinder in flat configuration
• reproduced on both AP and client wifi modes
• tested in open space without obstructions, GPS antenna pointed at least 40deg above horizon up to straight up

Method to reproduce:

• Startup PiFinder in Alt/Az mode
• Wait for GPS lock symbol on top right of UI
• Move to catalog screen, select object
• Locate screen says "searching for GPS"
• Status screen shows minimum 5 satellites and lat/lon coords. Seen both before and after selecting catalog item to locate
• also reproduced when sending GOTO from SkySafari Pro

Method to fix:

• Change PiFinder to EQ mode. EQ mode does not show this bug and Locate screen works normally

Notes:

• Persistent through software driven resets (changing config values) and software driven shutdown. Also persistent through power down (PiSugar switch), have not tested with battery removal

Will reproduce soon to get debugging images (logs if possible) and attach here

[brickbots]

Hello @tranquilaxolotl, thank you for the bug report with screen shots. I'm hoping you can help me out by providing answering a couple of questions.

I've tried a couple of times and have not been able to replicate this issue, but I did notice that the camera icon in the upper-right of the screen shot you sent is missing.

• Was the PiFinder properly solving at that point?

On one attempt to replicate this issue, the PiFinder had gone into low-power mode while I was entering the information from the GPS in the web interface, and the 'Waiting for GPS' message did not actually go away until I moved the PiFinder to wake it from the low-power state.

• If you are able to replicate this issue, would you please try moving the PiFinder or pressing a physical key to make the screen/keypad brighten and see if that potentially solves the issue?

Thank you so much, I'm keen to understand and fix this issue!

[brickbots]

@cdSheriff and @tranquilaxolotl One other thing to check, please, is the time displayed on the Status screen. The GPS lock is a combination of lat/long/time and it would be great to know what all three of these components are 👍

[tranquilaxolotl]

@brickbots , I took it out and was able to re-produce the bug, although it was cloudy, so got just few solves.

I also tested it on version 1.10 one before the "Waiting for GPS" addon, and it had the same behavior.

I have also did same in the basement, so I did not get a proper plate solve, and screen was showing "Waiting for solve",

Here is how I replicated the bug:

1. Unplug GPS antenna to make sure GPS signal will not show up.
2. Power up - AltAz Mode, Flat.
3. Search for nearby object, and I got "Searching for GPS"
4. set GPS coordinates, and time using browser
5. verify if GPS/Time was correct in status screen, seemed ok.
6. Search for nearby object, and I got "Searching for GPS"
7. I pressed several buttons multiple times to make sure that it is not in sleep mode.

Camera in the upper right showed for a short while, but after few seconds disappeared (too cloudy)

Let me know if you need any more info.

bellow screenshots that I took:

[brickbots]

Hi @tranquilaxolotl ! Thank you so much for the additional info and for the very helpful photos :+1: I've taken a look through this and the code and I think I know what's going on.... at least I've been able to replicate it under the conditions below.

The GPS status on the Locate screen is only checked with each new plate solve, and it seems like there has not been a new plate solve since the location/time has been set via the web interface. There could be a deeper issue here, but based on the images you sent, it seems like this is what is going on if this tracks with your experience. If you have seen this same issue while the PiFinder is solving, let me know and I can keep looking and trying to replicate this.

I'll put this on the todo list, but this generally should not be an issue when actually using the PiFinder for observing as a plate solve should be coming in every second or more frequently. Has this issue caused you problems under actual observing conditions?

[tranquilaxolotl]

I'm usually observing very short sessions 10-20 minutes maximum, so when I took scope out it showed me waiting for GPS all the time while I was trying to see something. I will do some more testing to see how it behaves when plate solves are coming in. I'll be out of town for 2 weeks, so will not have much time to use PiFinder, Once I'm back I'll get back to testing

[brickbots]

Thank you so much! I look forward to hearing about your results. Have a good trip 👍

[AstroScot66]

I have the same issue. I purchased the PiFinder fully built.

[tranquilaxolotl]

I did test it again today. Tried several times, once it worked. It seems to me that after password is entered on website, PiFinder stops plate solving. When I closed the website, once it managed to recover and started working. but it is very intermittent.

[brickbots]

Sorry for not giving more frequent updates here, we've been busy with finalizing the PiFinder v3 hardware and re-writing the UI code.

We're continuing to dig into this and have found that it's actually some issue with the solver crashing after the gps info is set via the web interface. We'll focus on fixing this up shortly after the v3 release.

Here's a hint for getting the GPS to lock, which is ultimately the best outcome:

• The Bump on the top of the PiFinder houses the GPS antenna, which is directional. Pointing the bump on the top of PiFinder towards the most open part of the sky, especially if there are obstructions, can sometimes speed up lock times. For left/right units, this generally means pointing the scope towards the horizon so that the bump is pointing up towards the sky.

[AstroScot66]

Thank you. I'll test this out tonight.

[AstroScot66]

That didn't work for me. Plate solves look like they work well, but GPS fails. When I manually enter the GPS on the mobile app, then plate solve stops working.

[tranquilaxolotl]

I tried few times, and could not get it to work, GPS for takes forever to get a lock. When I try on open field, then I can get GPS lock. I will try again when new UI is released.

I was thinking that maybe with the new user interface it would be easy to add 4-5 preset preset GPS locations, and time/date setting, that could be easily accessible when "Searching for GPS..." is displayed. Adding this would make life much easier for people observing from obstructed locations (lots of trees, buildings, balcony in an apartment etc...)

[mrosseel]

That's a good suggestion, probably not for the first release but soon after. Another fix is to the number of sats seen / used, this is currently only updating after a fix so useless. As for the web every, I've seen that fail on an old branch but not on current main, I will test again to be sure.

[brickbots]

I spent a bit of time trying to replicate this one the bench and could not, but I've seen it happen several times when testing under the stars, so I'll try tonight if it's clear.

While I was looking through the code I realized that even if this works, it probably won't actually work. The web interface only asks for time and the PiFinder code combines this with whatever the system date is, which is likely to also be wrong. This should be updated to ask for the entire date/time to be entered and to grab this from the browser time automatically. I'm logging this as #220