Onderwerp: Sextant - Altitude berekenen met Versine methode

@PvdW,
Een kleine opmerking over je plot. Gebruik een potlood aub. Je kan dan een gummetje gebruiken indien nodig en ook niet onbelangrijk het gaat niet vlekken als het nat wordt.

Edit: Ook je cijferwerk kan je beter met potlood doen. Een vergissing uitgummen ipv doorstrepen werkt veel netter en omdat het netter is maak je minder fouten.

Zie stuk terug over stappenplan hoe Hc berekend wordt (using versine method to calculate Hc, in reeds ook wel CA-Calculated Alt genoemd)
Berekening heb ik uitgevoerd met de versine, en consine tabellen

Azimuth is berekend volgens ABC formule:

te snel op verzenden geklikt -- hier volgt nog wat info over ABC

rooiedirk schreef :
eens, thanks!

PvdW schreef :
Is dr van je beginsituatie waar je dr hebt getekent in je plot?
43 10'5

als DR heb ik in dit geval mn gps pos genomen van tijdens meting, zodat ik afwijking meting kon bepalen. gps was 43 10.55N / 16 17.4E

PvdW schreef : Voor als je benieuwd bent wat je met die ABC-tabellen eigenlijk doet, zie bijlage.

PvdW schreef :
De intercept die ik vind, met dezelfde invoerwaarden, is wel groter, dus ik ben benieuwd wat de tabellen hierin voor rol spelen.

PvdW schreef :
het lijkt wel of je je DR (gps) positie hebt ingetekend op 43 16' ipv 43 10'

JotM schreef :
Gha en decl die ik vind zijn iets anders, resp: 44 42'5 E en 1 16'9 S

Ho heb ik hetzelfde 20 7'2 , TS komt op 20 7'38

doordat de aangenomen positie die ik heb gebruikt lager zit dan de DR komt de azimuth (zuidelijker) en intercept (groter) van jotm logisch over.

wat ik niet begrijp dat als je je gps positie neemt als uitgangs punt dan zou het intercept minimaal moeten zijn bij de versine methode, omdat je plot vanuit je DR ( in dit geval gps) positie.
Was het misschien een wilde zee waardoor de meting niet nauwkeurig was?

PvdW schreef :
Nog even hierop terugkomend: de inleiding van Henning Umland (LINK, 7.5 MB, 107 pag's, m.i. zéér leesbaar, zeker ook door de vele illustraties) is denk ik een goed en prettig uitgangspunt om je de "inner workings" voor de geest te kunnen halen.

Hij heeft ook erg handige dingetjes gemaakt, zoals een programmaatje voor het bepalen van de ware hoogte die geïmplementeerd is in javascript in een webpagina die ook offline tot ong 2040 binnen 1' werkt:
www.celnav.de/sunsight.htm
screenshot


Of alleen een in een webpagina geïmplementeerde almanac. De komende 20 jaar ong 1" fout,


zolang je zelf de juiste delta_T invoert. (voor nu geldt (Bulletin A): delta_T = 69.384 s)
www.celnav.de/longterm.htm
screenshot


Ook deze is offline te gebruiken, alle berekeningen worden door het script in de pagina lokaal uitgevoerd, dus er is geen dataverbinding nodig.

De scripts zijn gebaseerd op "Astronomical Algorithms" van Jean Meeus (LINK). Voor de liefhebbers weet ik uit ervaring dat het boek in druk verkocht wordt in de sterrenwacht in Utrecht.

Edit:
Als je de pagina's offline wilt gebruiken gewoon in de browser "pagina opslaan" en het *.htm bestand op een telefoon of tablet zetten. Daarna kan de pagina offline geopend worden mbv de browser in je mobiele apparaat.

De intercept die ik vind, met dezelfde invoerwaarden, is wel groter, dus ik ben benieuwd wat de tabellen hierin voor rol spelen.....

doordat de aangenomen positie die ik heb gebruikt lager zit dan de DR komt de azimuth (zuidelijker) en intercept (groter) van jotm logisch over.

wat ik niet begrijp dat als je je gps positie neemt als uitgangs punt dan zou het intercept minimaal moeten zijn bij de versine methode, omdat je plot vanuit je DR ( in dit geval gps) positie.
Was het misschien een wilde zee waardoor de meting niet nauwkeurig was?[/quote]

Rol Tabellen: wat ik me kan voorstellen is dat afrondingseffecten bij het aflezen / interpoleren van de tabellen toevallig een positief effect hebben gehad op de nauwkeurigheid.
Ik heb nog te weinig met mn sextant gewerkt om te weten wat mijn typische nauwkeurigheid is mbt mn metingen... is 10NM afwijking qua meting met een niet-metalen sextand absurd veel? leek mij redelijk normaal...

Hi JotM,

Ik heb al je boekwerken nog niet in detail door kunnen nemen, maar dat boek van John Karl is zeker een goede uiteenzetting, Dank!

Wat ik er niet in terug vond is antwoord op 2 vragen waar ik nog mee zit, zou je me hier nog mee op weg kunnen helpen?

VRAAG 1)
Alhoewel ik het stappenplan wat in mijn Reeds boek staat prima kan uitvoeren snap ik nog niet goed hoe ik hiermee de formule uit het boek feitelijk uitvoer: Versine (CZD) = Versine (LHA)xCos(LAT)xCos(DEC) + Versine(LAT +/- DEC) met Hc=90-CZD

Hieronder het in het boek beschreven stappenplan met daarachter mijn comments / vragen (zie ook eerder geposte afbeelding van dit stappenplan)

Stap 1 tm 4: Log Versine(LHA) + Log Cos(LAT) + Log Cos(DEC)
comments: ik snap dat door de log te nemen de vermedigvuldigingen uit de formule gereduceerd worden tot optellingen...

Stap 5: discard ten's digit
comments: ik snap ook de toegepaste truc om negatieve logaritmen te voorkomen door er 10 bij op te tellen en aan het einde weer af te trekken

Stap 6: Take natural versine of result of step 5
Vraag: Deze stap snap ik niet. Dit gaat kennelijk nog steeds over het stukje formule: Versine (LHA)xCos(LAT)xCos(DEC), waarbij het resultaat van stap 5 (som van Log's) terugvertaalt wordt van Log naar een Versine. Maar waarom is dit eindresultaat een Versine? het was immers onderdeel van een vermenigvuldiging met Cos(LAT)xCos(DEC)? ...



VRAAG 2:

Ik snap de noodzaak uit het verleden om met Log's te werken om moeilijke vermenigvuldigingen te voorkomen.
Ook snap ik dat hierdoor de noodzaak ontstond om een truc toe te passen om negatieve logaritmen te voorkomen die ontstonden bij Cosinusen voor hoeken groter dan 90 graden, en dat de oplossing gezocht werd in de Versine (die met 1-Cos(x) nooit negatief kon worden) en de halve versine of Haversine (om het bereik van 0-2 weer te reduceren tot [0-1]

Wat ik niet snap is hoe je van de (Co)Sinusregel voor boldriehoeken tot de versine en haversine formules kan komen? Weet jij of dit ergens goed uiteengezet staat?


Lang verhaal, hoop dat mn vraag een beetje duidelijk is

Ad vraag 1)
Het resultaat van de optelling is de logaritme van de eerste term. Om de optelling in de formule te kunnen doen moet je eerst terug naar het resultaat van de eerste term, niet van de log daarvan. Dus het resultaat van de optelling omzetten van een logaritme naar een waarde (de versinus van een hoek die er verder niet toe doet; je gebruikt de tabel eigenlijk gewoon als een logaritme-tabel).

Ad vraag 2)
De (ha)versinus-formule en de cosinusregel voor boldriehoeken zijn eigenlijk dezelfde formules, alleen een beetje anders opgeschreven mbv standaard gonio som- en verschilformules en de wetenschap dat de sinus van een hoek gelijk is aan de cosinus van de complementaire hoek (= 90° - hoek). Ik heb dat uitgewerkt in de bijlage bij een eerder bericht: zeilersforum.nl/index.php/foru...e?start=%1$d#1090492

JotM schreef :
Ah daar zit volgens mij mn vraag.., als: Versine (LHA)xCos(LAT)xCos(DEC)
Waarom is dan het resultaat van deze vermenigvuldiging weer een versine?
(anders gesteld, waarom is het resultaat van de Log optelling een Log van de 1e term - een Versine)?

Het eindresultaat van de vermenigvuldiging wordt immers 'terugvertaald' via de versine tabel

Of probeer ik nu dingen te snappen waar ik meer wiskundige achtergrond voor nodig heb?

PvdW schreef :
Nee, je verwacht dat er meer achter zit dan erachter zit.

De waarde die je opzoekt is een versinus van een hoek omdat alle getallen tussen 0 en 2 een versinus van een hoek zijn. Maar zoals ik schreef, die hoek (dus ook het feit dat daar een versinus bij hoort) doet er hier niet toe. Een aparte logaritmetabel doet ook wat je nodig hebt.

Maar als je dan toch al een tabel hebt waarin per regel de versinus van een hoek (een getal tussen 0 en 2) èn de logaritme van de versinus van die hoek (het logaritme van het betreffende getal tussen 0 en 2) staat, kun je net zo goed die tabel gebruiken ipv daarvoor een aparte logaritmetabel ter hand te nemen.

Je gebruikt van de "hoek - versinus(hoek) - log(versinus(hoek))"-tabel dus alleen de laatste twee kolommen. Voor dat terugzoeken is die tabel dus eigenlijk een "whatever - X - log(X)"-tabel.

Je hebt een log(X) (het resultaat van de optelling van Log Versine(LHA) + Log Cos(LAT) + Log Cos(DEC) ) en je hebt de bij log(X) horende X nodig. Zo duidelijk?

Ah ja nu snap ik het dank!!

Misschien domme vraag, ik ben ook de methode van reeds aan het bestuderen omdat de hoeveelheid tabellen die je mee moet sjouwen veel,overzichtelijker is.

Maar wat ik NIET begrijp is waarom in stap 5 de tientallen genegeerd moeten worden. Wie kan dit uitleggen?

Zoals ik eerder beschreef ( zeilersforum.nl/index.php/foru...sine-methode#1090527 ) wordt in de tabellen een truc uitgehaald om altijd positieve getallen in de tabel te hebben.
Als je bij het logaritme 10 optelt (de onderliggende waarde vermenigvuldigt met 10 miljard) moet dat er ook weer een keer vanaf. Als dat voor meerdere factoren is gedaan is dat het makkelijkst door gewoon de tientallen te negeren. Dan werkt daarna je tabel weer als je de uitkomst terug wilt zoeken.

Vragen die je stelt om te doorgronden hoe een methode werkt zijn volgens mij trouwens nooit domme vragen.