-
Notifications
You must be signed in to change notification settings - Fork 84
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Implement missing form template GPS-related insertion tags #330
Conversation
@xylo04 I thought I'd give it a try. |
(ignore those extra commits -- I was having issues pushing from my virtualbox...) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@n2ygk this looks like a great first crack! Thanks for putting this together. Does it work for you locally? If so, that's super exciting!
@xylo04 This is working properly for the GPS form but not the Winlink Check In form. Not sure why just yet other than suspecting I'm either not formatting the signed decimal string correctly or the form is buggy. The LAT gets filled in properly but the LON doesn't. See attached before and after screen shots for the GPS Position report form. In before, the tag has not been substituted and still showed as Clicking on "Click to use connected GPS LAT LON" does the right thing and fills in all the other fields on the form. |
I got the Winlink Check In form working by reverse-engineering and finding several undocumented insertion tags which I've added in 32e7106. There's a lot of random capitalization going on and some tags that are both supplied by the HTTP server and calculated in the form -- notably Grid Square. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice improvements! Getting closer.
Thanks for working on this @n2ygk 🙂 It looks like you haven't configured your editor to run PS: We have a CONTRIBUTING.md with some guidance to first time contributors. It's not the best, but worth the read hopefully 🙂 |
@martinhpedersen: no sorry I didn't run
Am I missing something? I can certainly rebase. Will do that now. Thanks for the reminder. |
These seems to be related to a change in how build tags are handled (>Go 1.17). I will fix those 👍 Running |
@martinhpedersen Ah. Thanks for the pointer. My editor is Emacs and my go knowledge is zero.
|
@martinhpedersen fixed in my .emacs: |
Nice! 🙂 👍 One more thing! We generally merge PRs to Thanks! |
@n2ygk - Are you still working on this, or waiting for a new review and/or merge? |
I'm done. Waiting for review/merge. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for working on this @n2ygk 😄
I think we're almost ready to merge this. Please see my inline comments.
Thank you!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Almost there!
I suppose I should rebase this.... Standby. Done. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since our default config provides a default gpsd address this will always throw an error for users without GPSd.
I think we need a more graceful handling of this condition than printing the standard tcp dial error each time those users fills in a form template.
Maybe we should simply omit the error if it's a network dial error?
How about changing the default config to not list a gpsd address? It's kind of wasteful to attempt those dials irrespective of whether errors are being logged. I wouldn't want to not log errors if there is in fact expected to be a gpsd running. |
I think we should avoid comprimising a good default value in our config just to keep from logging errors for users of these forms that don't care about using GPSd. The default config is very convenient for the other GPSd related features, requiring no config on most systems. How about adding a Line 227 in 587580f
|
For enabling use of GPSd with forms. Ref #330
Will try to get to this over the weekend. Thanks. |
For enabling use of GPSd with forms. Ref la5nta#330
@martinhpedersen I need a little help here. I've made the change but when trying to compile and run there appears to have been some change to the web js code that throws this error: |
@n2ygk - I think you should rebase again, and solve that conflict in README.md. I don't fully understand why you would get such an error. Probably not related to this PR anyway, but I will check it out once you've rebased 🙂 Thanks!! |
b58eee3
to
150c45b
Compare
I suspect this may be related to 7850c5f which I just found now that I've rebased;-) |
@martinhpedersen OK so this is looking like it does the right thing now. It's being very quiet about the error message per your prior recommendation so the user will not realize that the GPSd stuff needs to add |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Once last thing... (see inline comment).
@@ -705,6 +710,99 @@ func (m *Manager) findAbsPathForTemplatePath(tmplPath string) (string, error) { | |||
return retVal, nil | |||
} | |||
|
|||
// gpsPos returns the current GPS Position | |||
func (m *Manager) gpsPos() (gpsd.Position, error) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since the error returned from this function is never used for anything but to check for success, I think we should replace this with a "ok" boolean. Then you could omit the check for "noPos" as well 🙂
All these error messages could be useful for debugging, so I suggest logging them instead using our debug logger debug.Printf.
func (m *Manager) gpsPos() (pos gpsd.Position, ok bool) {
}
I'd be happy to do these last minute tweaks after merging if you prefer. Just say the word 🙂
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The code currently propagates the return from NextPosTimeout() so this will become quite a bit uglier as would the NoPos checking since gpsFmt is called with a Position.
I've added a couple of debug Printf of the gpsPos error.
Feel free to make the tweaks you suggest if you disagree.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sure, I see what you mean 🙂
As a general rule of thumb I think it's better to either log or return an error, not both. It helps with readability and makes the responsibilities clearer IMO.
I think we should merge this now, and I'll see what can be done with regards to this afterwards.
Thank you 😄
I agree! If you don't mind, yes please 😄 |
…the Winlink Check In form.
Thanks for working on this @n2ygk! Highly appreciated 🙂 |
@martinhpedersen done: https://github.com/la5nta/pat/wiki/The-web-GUI |
I've put together a Python script that request GPS position from the Signal K server. It respond with nn.dddd nn.dddd, but I included a routine that convert the output to a grid reference. It would be benefical if Signal K could be added as a source. File is get.grid.py. Not all RPis have a local GPS attached. |
Thanks for the suggestion, Ole! I've filed #356 to track adding Signal K as a GPS source. |
Fixes: #328
Implements several missing insertion tags for form templates (some of which are not documented other than by reading the HTML):
Some of these values are substituted in forms but not used (like GridSquare).