Welcome to the NavList Message Boards.

NavList:

A Community Devoted to the Preservation and Practice of Celestial Navigation and Other Methods of Traditional Wayfinding

Compose Your Message

Message:αβγ
Message:abc
Add Images & Files
    Name or NavList Code:
    Email:
       
    Reply
    Re: Lunar4.4. vs Frank's online calculator
    From: Frank Reed
    Date: 2023 May 11, 20:22 -0700

    Modris, you wrote:
    "I always use 7X telescope with very excellent optics for lunars."

    Ah, very nice. :) I don't have a 7x scope anymore, but that used to be my favorite for lunars. Enough magnification for good results, but still a wide enough field of view that hand motion and other vibratory motions don't become a nuisance.

    And you wrote:
    "You described Jupiter lunar to proof that it is not possible to identify very small angles."

    Just to clarify, not as a "proof". It was a suggestion --something to ponder! I wrote about trying to split the disk of Jupiter into different visible "slices" just to get us thinking ("us" meaning you and me and whatever other tiny group of people are reading these messages).

    You mentioned the comparative quality of lunars using a variety of "other bodies". This is something that I've written about rather regularly in the 21st century, and I agree with you that Sun-Moon lunars produce the best results. Bright star lunars are notoriously variable. I get good results with bright stars in bright twilight. I know other lunarians who have experienced this, too. As our eyes adapt to the darkness later in twilight and into real night, the defects of our eye become more significant visually, and the stars turn into their traditional cartoon form: bright, extended objects with spikey points on them. Such distorted images of the stars yield fairly poor angular results. 

    You mentioned that you have not had good success with Jupiter sights. Here we differ, and I think you should experiment more. I get excellent results with Moon-Jupiter lunars, almost always comparable to Moon-Sun lunars, especially when using a scope of 5x or better magnification.

    You continued:
    "The all above mentioned is an explanation how I get 0,05’ desired value for software. As you can see all my assumptions are not scientifically based, but only emotionally based."

    Fair enough. But my key point here is that you hit a hard limit immediately. And no amount of fine-tuning of the ephemerides or delicate adjustment of our sextants is going to make that go away. The Moon has mountains and valleys. And they are the limit for lunars.

    I assume you're aware from your reading, either digging around in the NavList archives or elsewhere, that the Apollo astronauts shot lunars --not for time determination, of course, but for fixing a position in three-dimensional space. They measured angles from the Moon's limb to bright stars almost exactly as an 18th century navigator would have done. The sextant had a nice 28x scope, and all the math was done by that efficient little on-board computer, but the principle was exactly the same. The sextant on the Apollo command module was fitted behind a slit like the opening on an observatory dome which could be turned to point at different stars. I made a little animation of this months ago. I've been meaning to post it. See below...

    The astronauts discovered rather early that the limb of the Moon is too lumpy (and for "earther" sights, the atmospheric levels are too uncertain). The navigation team invented a new "clever plan". Instead of measuring angle to the Moon's or Earth's limb, they planned to measure the angle between a star and some identifiable point on the Moon or the Earth. For example, if the target is the middle of the Golden Gate Bridge at the opening of San Francisco Bay, this can be identified and centered by the observer to the nearest second of arc or so over a great range of distances from the Earth. Even though the actual bridge is invisible beyond the closest ranges, the angular position is still easily specified. That's probably the sensible way to move lunars forward today, if we're shooting them for some non-historical reason (like quantifying arc error). For example, with the Moon, we might measure the angle from a bright star to the exact top of the peak at the center of the crater Tycho (depending on the time of the lunar month and lighting conditions on the lunar surface).

    You wrote:
    "Frank, your explanation relating to the Moon’s limb imperfection is great! I did not know that these values reach +/-3” ( I thought they does not exceed 1”). Thanks! Very interesting indeed!"

    Glad you liked it. Yes, this is the fundamental limit. Here's an interesting and relatively recent article on this topic from the NASA "Scientific Visualization Studio": https://svs.gsfc.nasa.gov/4517.

    I asked you for some specific cases of possible discrepancies, and you wrote:
    "Here are some examples. Position: 57°N; 26°E; 10°C; 1010mbar
    1) Sun-Moon near limbs; 30.04.2023; 16:20:00; Frank’s distance: 120° 28,59'; Paul’s Lunar4.4: 120° 28,77'; Difference: 0,18’.
    2)Capella-Moon near limb; 03.05.2023; 19:20:00; Frank’s distance: 114° 58,44'; Paul’s Lunar4.4: 114° 58,58'; Difference: 0,14’."

    So where does the truth fall?? Closer to Paul's numbers? Closer to mine? Sometimes one and then the other? If the "truth" is more or less in between, is that good enough? Or maybe the "truth" is a substantial difference from the output of both apps?! How ever would you know?? 

    I actually have "another" lunars app, waiting off-stage in the wings. :) When time permits, I've been working on an app for iPads and similar. It's mostly built on the same code base as the web app that you have been using, but there are some cases of approximations in the old web app which I don't have to worry about anymore. It's funny -- one of the earliest versions of my web app originally ran on phones --but not what we could call "smartphones" today. The earliest version of my lunars web app was designed to run on my favorite flip phone back in 2004/05. Lunarians marveled back then at the trick! We could shoot lunars from a shore site near Mystic Seaport and clear them right there! The web app still works on modern phones and tablets, but it's not very stylish. :) 

    Thank you for providing specific cases. I can take your examples here and test them out with my "other" app. For case 1, your Sun-Moon example, the "better" result would be 120°28.63'. For your case 2, the Capella lunar, the "better" number should be 114°58.53'. So my current web app differs by only 2.4 arcseconds in the first case (harmless) and 5.4 arcseconds in the second case (mostly harmless --with a nod to a researcher from Betelgeuse). I'll be a little more "comfortable" with the better numbers from the new app, but this is all still at the level of the natural uncertainty --unless and until we add limb profiles to the game! :) I do believe I'll port the slightly improved code for oblateness corrections to the standard web app. It's ready for market right now, but I should test it to make sure I haven't missed any nasty special cases (edge cases, as they say).

    I think that this "versus" (Lunars4.4 vs Frank's) thread is done. Comparing is no longer useful. 

    Moving on... You raised multiple interesting topics in your last post, and I hope you'll start some new threads spinning off into those topics. For example, Moon-Sun lunars are better lunars. Why? Have you encountered the concept of visual "hyper-acuity" yet? It's also known as "vernier acuity". And it's relevant to several aspects of celestial navigation including lunars (and vernier scales, not coincidentally!). And why do we list (and trust) our almanac data quoted to tenths of a minute? That's another interesting topic. Consider that in 1767 the lunar distance tables in the first edition of the British Nautical Almanac (from then onward) listed the angles between the Moon and the other body always to the nearest second of arc. Did they believe it? Why didn't they use tenths of minutes?

    Anything else? :) 

    Frank Reed
    Clockwork Mapping / ReedNavigation.com
    Conanicut Island USA

    File:


       
    Reply
    Browse Files

    Drop Files

    NavList

    What is NavList?

    Get a NavList ID Code

    Name:
    (please, no nicknames or handles)
    Email:
    Do you want to receive all group messages by email?
    Yes No

    A NavList ID Code guarantees your identity in NavList posts and allows faster posting of messages.

    Retrieve a NavList ID Code

    Enter the email address associated with your NavList messages. Your NavList code will be emailed to you immediately.
    Email:

    Email Settings

    NavList ID Code:

    Custom Index

    Subject:
    Author:
    Start date: (yyyymm dd)
    End date: (yyyymm dd)

    Visit this site
    Visit this site
    Visit this site
    Visit this site
    Visit this site
    Visit this site