Färdplaneringsprogram på nätet (Swflightplanner)

Just ja, glömde svara på din första fråga. Jag ska titta på att lägga in informationen från PDF:en du länkar till. Jag använder redan data därifrån, för att få höjd MSL och position på flygplatser, så radiofrekvenser, ban-nummer och liknande ska väl också kunna gå.

För stora flygplatser använder programmet data om trösklarnas positioner, vilket gör att banorna hamnar exakt rätt. Skulle det vara okay om programmet ritade ut banor även när exakta koordinater inte är kända? Jag misstänker att det då blir bra nog för allt utom GPS-assisterad auto-landning...

 

Vad kul med en expert! En spännande värld det där med programmering, och särskillt just det där med optimering Jag följer projektet med spänning...

Bara man får en bild av hur banorna ligger är det ett stort plus för piloten! Situational awareness är ju aldrig fel, särskillt när det är ett nytt flygfält man besöker och man kanske är lite stressad. Sen att dom inte ligger exakt för tex GPS-inflygningar och liknande tycker jag är en småsak i sammanhanget. Det här programmet är väl knappast tänkt som förstahandskälla i skarp IFR.

Angående optimum-cruise altitude. Jag tror nog det du nämner räcker ganska långt. Sen har till exempel flygplan med constantspeedpropeller lite mer avancerade performance-tabeller i sina manualer. Olika powersettings versus olika densitetshöjder och sen också bränsleförbrukningen som gåt åt till att stiga upp på höjden. En enkel modell är iaf bättre än ingen alls! Just nu blir det ju mycket att man väljer en cruisehöjd lite på höft...

 

Optimal flyghöjd

Du kan hämta metod från de Excel-blad för färdplanering som jag utvecklade för sådär 15 år sedan.
http://nuchem.se/aero/driftfpl/driftfpl.htm
Välj ett av flygplantyperna och gå till fliken Trip.
Kalkylen använder vinden på 0, 2000, 5000 och 10000 fot, och interpolerar mellan dessa.
Förutsättningen i min kalkyl är att man kör på marscheffekt både under stigning och sjunkning, vilket jag brukar göra.
Det ger optimal ekonomi om man äger planet själv eller hyr det torrt.
Hyr man flygplanet vått, gäller istället att man får bäst ekonomi genom att blåsa på med max tillåten effekt hela tiden.

Hälsningar

Allan

 

Hej!

Tack för tipsen. Sitter och kollar på dina excel-ark nu.

Förstår jag det rätt om jag tror att det funkar såhär:

Jag väljer att jag vill stiga, cruisa samt sjunka t.ex med 75% motoreffekt. Bränsleförbrukningen är då känd och konstant. Från en tabell för flygplanstypen går det att läsa ut hur lång tid det tar att stiga till 1000 fot, 2000 fot, 3000 fot osv vid den valda motoreffekten, samt hur lång tid det tar, och hur långt sträcka som krävs. Dessutom utläses vilken marschfart som uppnås på de olika höjderna, vid planflykt på den valda motoreffekten.

Baserat på allt detta går det att räkna ut bränsleförbrukning och tidsåtgång, från start till landning.

De tabeller som användarna skulle få mata in borde bli i stil med:

För varje höjd, säg 0 till 12000 fot, i intervaller om 1000 fot:
* Cruise speed
* Time to climb
* NM to climb
* Time to descend
* NM to descend
* Fuel flow, climb L/h
* Fuel flow, cruise L/h
* Fuel flow, descend L/h

Det borde kunna bli ganska bra va? (Med reservation för att jag kan ha glömt någon parameter)

 

Hej,
I princip kan man göra som du säger, och låta användaren fylla i tabeller för för olika effektuttag under stigning. Men de flesta saknar nog kunskaper om hur man får ut den informationen. Handböckerna för flygplan brukar ju bara innehålla data för stigning med max möjlig effekt.

Inte heller brukar handböckerna innehålla information om hur mycket hastigheten ökar om man gör plané med marscheffekt.

Så jag har valt att istället beräkna propellerverkningsgraden och flygplanets luftmotstånd. Dessa data kan beräknas ur glidtalet vid bästa glidhastighet och stigförmågan vid maxeffekt.

Principen är sedan att en viss del av motoreffekten behövs för att hålla flygplanet flygande. Resten kan användas till att ge ökad hastighet eller till att stiga.

Hur mycket effekt som behövs för att öka hastigheten över bästa glidhastihet får man ur data för marschhastighet på höjden noll vid olika effektinställningar. När det gäller höjden, så är det så gott som uteslutande en fråga om täthetshöjd.

Man måste ju förstås också ta hänsyn till att motorn bara kan ge den avsedda effekten upp till en viss höjd.

Under stigning får man en effektförlust genom att motoreffekt omvandlas till lägesenergi. Den effektförlusten skall vara lika stor som motorns överskottseffekt kompenserad för propellerverkningsgrad.

Under sjunkning frigör man lägesenergi, vilken omvandlas till ett effekttillskott (100 % verkningsgrad). Detta adderas till motorns effektiva effektöverskott och ger då hur mycket total effekt som finns tillgänglig för att öka hastigheten. Hur mycket extra effekt man får beror på sjunkhastigheten. Därför innehåller mitt kalkylblad en ruta där man kan fylla i vilken sjunkhastighet man tänker använda. Själv brukar jag sjunka med 100 - 300 fot per minut. Det som begränsar är att jag inte vill komma in i den gula bågen under sjunkning. Turbulens kan sätta in väldigt plötsligt.

Hälsningar

Allan

 

Hej!

Intressant resonemang. Så idén är att använda diverse fysikaliska samband för att sätta upp en matematisk modell över flygplanets prestanda, och sedan använda denna modell för att räkna ut t.ex bränsleförbrukning?

Har du någon bild av hur nära verkligheten det blir?

Modellen du beskriver kan väl t.ex inte ta hänsyn till att propellerns verkningsgrad varierar vid olika farter och densitetshöjder, eller att luftmotståndskoefficienten (Cd) och trimmotståndet varierar med anfallsvinkel, eller att både lyftkoefficienten (CL) och Cd varier med reynoldstal på olika höjder och farter?

Jag kan absolut köpa att man kommer ganska nära sanningen i praktiken, men hur nära?

Jag flyger ju själv UL, och inget av min flygklubbs plan har några vettiga prestandatabeller. Jag har ju förstås Civilair L1P-handboken någonstans, men det är ju inte många som flyger den flygplanstypen

Så därför undrar jag vilka tabeller som finns i t.ex Cessa 172 och PA28-handböckerna? Verkar vettigt att utgå från den information som ändå finns. Att stigdata bara finns för maxeffekt låter ju konstigt? Finns det inte nån sorts "enroute climb" data?

 

Hej,
Vilka data som ges varierar från fabrikat till fabrikat. I de handböcker jag har tillgängliga ser det ut så här:
PA-28: Tabell över stig varje 1000 fot vid maxvikt.
PA-32RT: Två diagram med temperatur, höjd och vikt. Ett för stighastighet och ett för stigsträcka.
Cessna 182P: Tabell med värden för fyra höjder och vid tre olika vikter.
Robin 100: Diagram över stighastighet med temrperatur, höjd och vikt.

Alla data i handböckerna gäller vid max möjlig effekt. Det är väldigt knäppt, speciellt för de tre sistnämnda, eftersom de har constant speed-propeller. Och med en sådan skall man reducera till 75-80 % så fort man är på säker höjd.
Ingen handbok jag har sett ger data för annat än maxeffekt.

Hur nära verkligheten man kommer vet jag inte. Men min erfarenhet är att data ur handböckerna oftast är överoptimistiska med minst 5-15 procent i de flesta avseenden utom sidvindskomponent. Enligt handboken skall min Robin ha en TAS på 140 knop på 5000 fot vid 75 procent effekt. Det uppmätta värdet är 135 knop. Å andra sidan gjorde den som jag kraschade (samma modell) 142 knop under samma förhållanden. Jag har fått intrycket att vingarna är något skeva på min nuvarande. Några mm skillnad bromsar ordentligt.

Därför använder jag uppmätta prestandadata för den individen jag flyger. När man stiger på konstant effekt skall man också ha konstant stighastighet och det har jag verifierat. Värdena stämmer rimligt bra med vad formeln säger, men jag har inte gjort några noggranna mätningar av den saken.

Hälsningar

Allan

 

Hej Ankan!

Jag gjorde ju en flygning från Frölunda och ner till Västkusten (Stigfjorden) med sjöplan för några veckor sen, via färdplaner som jag gjort upp via swflightplanner. Och som jag sagt tidigare: tröskeln för att jag skulle orkat sitta och pyssla ihop färdplaner hade nog varit lite för hög om jag inte haft din app till hjälp. Nu gick allt supersmidigt, alla siffror stämde och utskrifterna var väldigt bra att ha på knäbordet. Det var överhuvudtaget en superfin flygning, all flygledarinteraktion gick smidigt och jag kände att mitt flygande utvecklades på flera sätt. Tack!

Nu till din fråga om hur man vill att utskriften ska se ut, vilka data som är bra att ha där, osv.
Till att börja med vill jag säga att jag gillar upplägget, där brytpunkterna utgör separata rader, med benen emellan. I den driftfärdsplansmall jag brukat använda tidigare ligger brytpunkterna och benen på samma rad, vilket är ologiskt och ibland förvirrande.

Vi börjar med "brytpunktsraderna":
Bra med namn, ETA, återstående bränsle. Saknar ATA, samt ett par (oifyllda) kolumner som jag upptäckte var bra att ha, nämligen "försening/acc försening" eller vad man ska kalla dem. Om man får mer motvind än man väntat sig, så blir man ju lite försenad till varje brytpunkt. När jag flög gjorde jag på följande vis: när jag nådde en brytpunkt skrev jag ner ATA, hur mycket längre tid än beräknat senaste benet tog ("+5", t.ex.), samt uppdaterade ETA för nästa brytis utifrån det. När jag sen kom till nästa så gjorde jag nya anteckningar och beräkningar. Därför skulle jag föreslå följande utseende på brytpunktsraden: Namn, återstående bränsle, ETA, "uppdaterad ETA", ATA, försening för senaste ben, ackumulerad försening. De 4 sist nämnda fälten är givetvis oifyllda vid resans start. Finns det plats över kan man klämma in Terrain någonstans, men den känns inte alls lika viktig vid VFR-flygning. "Man ser väl var marken är?"
Angående förslaget att kalla första och sista brytpunkten för något annat håller jag för övrigt med dig; start- och slutpunkt är som vilka brytisar som helst. Möjligen skulle man kunna numrera dem så startpunkten blev nr. 0.

För "benraderna" tycker jag följande data är viktiga: Alt, CH, D(istance), TAS (eller kanske IAS), Time, Total time. Vinddata känns oviktigt - det har man ju ingen nytta av när man väl sitter i cockpit. Obst-free alt. kan man ha med om det finns plats, men jag tycker det är samma sak som med Terrain - flyger man VFR så bör man ha koll på det ändå. Skulle däremot gärna ha med GS - har man en GPS ombord är det smidigt att kunna jämföra beräknad GS med uppmätt för att få ett hum om huruvida man ska förvänta sig försening/bränslebrist eller ej. Kanske att man även vill ha med True Course för att kunna jämföra med GPS-en (för de fall man inte har lagt in rutten i GPS-en).

Ett extra plus för frekvenserna som stod utskrivna! Mycket praktiskt.

 

Lägger till en annan synpunkt i ett eget inlägg, eftersom det rör en annan sak:
När jag importerade färdplanen på AROWeb så blev det några småfel. Dels så verkade den inte gilla formatet på namn. I mitt fall blev det "JOAKIM.VON.SCHEELE" vilket renderade mig en liten röd stjärna. När jag redigerat och bytt ut punkterna mot mellanslag gick det bra.
Sen vore det smidigt om telefonnumret för SMS-svar fylldes i också, på samma sätt som det andra telefonnumret.

Sen har jag ett förslag: När jag lämnat in färdplan har jag alltid angivit "VFR" som flyghöjd, efter tips från min flyglärare. På så sätt har jag kunnat välja vilken flyghöjd jag vill ha när jag ser förhållandena, alternativt låta flygledaren föreslå en höjd som passar honom. Att i förväg välja flyghöjd har jag aldrig känt något behov av och det har känts överflödigt att fylla i det i driftfärdplanen i förväg också. Skulle man inte kunna ange "VFR" som flyghöjd i sin färdplan? Det skulle då resultera i dels att höjdfältet i utskriften blev tomt, för ifyllnad för hand senare, samt att VFR angavs som höjd i ATS-färdplanen?

Och om jag ska blanda mig in i er diskussion angående bränsleförbrukning för olika flyghöjder, stigvinklar, farter, temperaturer osv, så håller jag med om att det är ett intressant optimeringsproblem, men jag tror det blir svårt att få nytta av det i praktiken. Om inte annat för att vinden ändå inte stämmer när man väl är uppe, vilket påverkar mer än andra parametrar. Dessutom spelar ju vikten in högst väsentligt, på icke-triviala sätt, beroende på övriga parametrar. Jag tror mer på att manuellt kunna ange bränsleförbrukning per ben. Ett förifyllt värde, som idag, som man kan justera om man vill.

 

Jocke,
Jag håller med om att vinden ofta avviker från prognosen. Men om man kan beräkna optimala flyghöjden redan före start, så har man något att avvika ifrån. Man är dessutom automatiskt i ett bättre läge än om man bara använder tumregler.

Jag gjorde ett par små kalkyler på en typisk reseflygning, 400 nm i varje riktning. Det svarar mot t.ex. Skövde-Groningen och åter. Jag jämförde billigaste och dyraste alternativ. Prisskillnaden var 2142 vid ett vått timpris på 1500 kr. Äger man istället samma plan själv får man andra optimala höjder och motorvärden och en prisskillnad på 1442 kr. Kalkylen gäller förstås bara under givna förhållanden och med ett bestämt flygplan. Men den visar att det finns påtagligt med pengar att tjäna. Lämpligen gör man optimeringskalkyler för ett antal vindar runt de prognosticerade. Under flygningen kan man sedan välja den som stämmer bäst med verkligheten. Väl uppe på marschhöjd märker man ju ganska snabbt hur vinden blåser i verkligheten. Då kan man justera till optimal marschhöjd. Så det här är inte bara av rent teoretiskt intresse.

Men man skall också minnas att det kan finnas skäl att avvika från det optimala av olika anledningar, t.ex. väder, terräng eller luftrummets utseende.

Hälsningar

Allan

 

Allan,
missförstå mig inte - självklart är det bra att leta optimal flyghöjd ur olika aspekter. Det jag funderar över är dock om utförliga beräkningar, gjorda i förväg, löser det optimeringsproblemet. Jag tror, precis som du skriver, att det effektivaste sättet att hitta optimal flyghöjd är att justera utifrån de förhållanden som faktiskt råder, när man väl är uppe i luften.
Det jag, måhända otydligt, försökte säga är att jag tror att det kan bli onödigt komplicerat att använda appen om man inför för många parametrar, utan att det egentligen tillför så mycket. Något jag däremot tror vore bra är, som sagt, att kunna ange bränsleförbrukning explicit på vissa ben. Säg att man vet att man kommer att vilja stiga när man går ut över hav, t.ex. Eller sjunka när man närmar sig ett TMA. Då kan man ange ett (konservativt) värde på förbrukningen för just det benet som avviker från "normal" förbrukning. Det vore en ganska enkel åtgärd, jämfört med de beräkningar som beskrivs i inlägg ovan. Och som sedan, på grund av de många osäkerhetsfaktorerna, förmodligen inte kommer stämma, vilket kan utgöra en risk.

 

Anders, jag och Richard hade också stor nytta av att skriva ut färdplaner från din webb-app när vi gjorde vår rundflygning i södra Sverige. Mycket smidigt.

Jag har testat Android-appen lite. Tycker det är smidigt att använda den allra enklaste kartan för att se gränserna på luftrummen, speciellt när man flyger runt i stockholmsområdet.
Jag saknar dock att det inte finns fasta lägen för North Up och Track Up. Klickar jag på North Up förväntar jag mig att knappen byter namn till Track Up och att läget låses. Nu verkar det gå över till Track Up automatiskt.

Sen borde lösenordet i appen vara dolt och inte i klartext.

Det är allt för nu

 

Hej Jocke!

Tack för synpunkterna! Att ha oifyllda rader för ATA (Actual Time of Arrival?) och liknande låter som en bra idé. Du har ju förstås rätt i att det är väldigt viktigt att kontinuerligt utvärdera sin flygning och att vid mellanlandningar fråga sig själv: har jag fortfarande bränsle nog till nästa bränslestopp?

Terrain är med för att man ska kunna dubbelkolla sin QNH-inställning. Det har man ju i och för sig på flygplatskortet, så jag kan hålla med om att den kunde skippas i driftfärdplanen. Å andra sidan vet jag att det finns andra användare som skulle vilja ha mer flygplatsinfo (frekvenser, ban-nummer etc), så jag börjar luta åt att det här måste bli valbart per användare .

Obstacle free altitude kanske inte behövs, tanken att ha med det är som en sorts påminellse att man inte kan lägga sig på 1500 fot MSL och tro att detta ger laglig höjd över marken. Åtminstone var det en sån grej som blev en sorts aha-upplevelse för mig första gången jag åkte lite längre från hemmafältet ("men vad stora träden ser ut - jag ligger ju på 1500 fot"! "Ehm.. ah, just ja, terrängen är på 600 fot här"!). Under skolningen var ju AMSL (höjd över havet - det man läser på mätaren) nästan alltid lika med AGND (höjd över marken). (Jag skolade i Stockholmsområdet. Närmsta berg är typ i Dalarna.)

Jag kan nog hålla med om att man nästan aldrig behöver vind-info in flight. Avdriften ser man ju (om man inte är jättehögt), och medvind-motvind märker man ju på att man kommer fram fortare/långsammare. TAS är bara med för att man ska komma ihåg att hålla planerad fart.

Det där med att ha med GS och true track håller jag med om. Det har jag saknat själv ibland. Har redan lagt till det här och nu i min testmiljö, det kommer nästa gång jag uppdaterar webbsidan.

Det där med befälhavarens namn och aroweb är jag medveten om. Jag fick för mig förut att aroweb blev förvirrad av mellanslag i namnet, därför lade jag in punkterna. Men det verkar ju inte ha hjälpt, jag ska prova att ta bort dem.

Att programmet ska klara av att man anger VFR som flyghöjd är ju förstås möjligt. Dock kommer väl alla bränsleberäkningar att bli mycket osäkra då, eftersom man isåfall varken vet vilken vind man ska räkna med eller hur mycket soppa man ska räkna för stigning?

Jag märker att det finns två vägar att gå här. Att lasta mer av ansvaret för prestandaberäkning på piloten, och förenkla för de som kanske ändå mest går på 1500 fot GND, eller att göra programmet "smartare", mer kraftfullt, men då också lite svårare att använda och dessutom mindre tillförlitligt (ett enkelt program kanske inte tillåter så avancerade beräkningar, men risken för fel i själva programmet blir mindre).

Att välja VFR som flyghöjd är ju förstås möjligt. Dock kommer ju ev. bränsleförbrukningsberäkningar att bli ännu mer osäkra?

Micke: Hmm, är det så att du vill ha ett kartläge där norrut är uppåt, men som ändå följer med flygplanet när det rör sig? Det är en idé, ska skriva upp det på min göra-lista. Som det är nu, när man panorerar omkring (och Track North-funktionen dyker upp), så panorerar inte kartan när flygplanet rör sig. Tanken med att bilden automatiskt centrerar på flygplanet efter 20 sekunders inaktivitet är att man vid panorering på kartan ska kunna bara lägga ifrån sig mobilen precis närsomhelst, och nästa gång man tittar ska man vara tillbaka i huvudläget. Tanken var att detta skulle minska stressen i cockpit, eftersom man inte behöver göra något för att hamna tillbaka i default-läget. Kanske har det inte avsedd effekt? Typ. Att göra default-läget i sig konfigurerbart är en bra idé!

 

Liten nyfiken om VFR-höjd,optimering mm



Om man lämnar VFR som planerat höjd och stiger till tex 1500 fot och kollar läget,förhållandena, och ser att det går nog att stiga till 4500.....Optimerar ni innan ni stiger eller stiger ni först och börjar optimera?


Om höjden som som ni stiger till inte är optimal,optimerar ni igen och stiger högre om det verkar bättre? Om det ändå blir sämre på högre höjd,sjunker ni till höjden som som ni hade innan eller optimerar på lägre höjd?


Vill inte trafikledning veta höjd som man planerar att flyga på när det gäller längre flygningar,eller är VFR som höjd helt OK?


MVH/TOC

 

Japp. ATO (Actual Time Over) är väl egentligen den korrekta termen, om man ska vara petnoga.

Jo, det är ju en bra funktion. Men det har man ju bara nytta av vid första "brytpunkten" (nr. 0), dvs vid startflygplatsen. På alla andra ställen har man ju ingen större nytta av att veta exakta höjden över havet. Ingen nackdel, men lågprioriterat, i mina ögon.

Aha, denna siffra anger alltså högsta terränghöjd. Då missuppfattade jag den - jag trodde det betydde högsta hindret (master, vindkraftverk etc.) i området. Kanske vore "Highest terrain" eller nåt ett tydligare namn? En bra funktion! (Säger jag, som skolat på samma ställe som du. ;-)

Kanske borde det vara IAS istället? Så har du ett litet räkneproblem att bita i. ;-)

Du har rätt - man behöver ju ha en höjd att utgå från när man hämtar vinddata, om inte annat. Jag hör nog (än så länge) till dem som mest ligger och harvar på 1500 GND (även om jag, när jag nu flög på färdplan, mycket lättare kunde med att begära en högre höjd, genom diverse TMA:n och annat).
Svårt det där - ska man ha noggranna beräkningar som eventuellt ger felaktigt resultat pga osäkert indata eller ska man ha enkla beräkningar som ganska säkert ger felaktigt resultat men där det s.a.s. är "underförstått". När jag tänker efter lite mer så ser jag egentligen ingen anledning till att inte räkna noggrant. Men fortfarande tror jag det vore en bra idé att kunna "ovverida" det uträknade värdet på bränsleförbrukningen och mata in något annat, manuellt. I synnerhet som de noggranna beräkningarna inte kommer fungera för de flesta flygplanstyper, pga bristande info om bränsleförbrukning vid olika förhållanden.

Och återigen: Vilken superapp du skapat. Tack!

 

Precis. De flesta GPS:er kan köra antingen med Track Up eller North Up. Enda skillnaden mellan de två lägena är att det ena har kartbilden låst med norr uppåt. Det kan då vara lättare att förstå var man är då man oftast har lärt sig hur kartan ser ut med norr upp. (Det är ju så man studerar den hemma på kammaren)

 

Först några announcements! Swflightplanner.se har nu stöd för att räkna ut "optimal" cruise-höjd, och har även vissa flygplatskartor i android-appen.

Android-appen laddar helt enkelt ner flygplats-kartor från luftis AIP. Så enbart större flygplatser omfattas. Mervärdet från att låta swflightplanner ladda ner dessa kartor jämfört med att själv göra det är:

1: Man kan enkelt från programmet ta upp kartan för de två närmsta flygplatserna, utan att behöva tänka på filnamn, pdf-läsare eller dyligt.
2: Programmet ritar ut din position i kartbilden (så att du t.ex kan verifiera att du verkligen håller på att svänga av på taxibana Adam och inte Bertil, t.ex).

När det gäller att räkna ut optimal flyghöjd så har programmet nu stöd för att effektivt söka igenom alla möjliga kombinationer av cruise-höjd på alla ben i färdplanen. Programmet använder väderdata från luftis och tar hänsyn till flygplanets prestanda samt rådande vindförhållanden. Man kan välja att optimera för minsta bränsleförbrukning eller kortaste restid. Observera att programmet enbart optimerar höjden. I verkligheten kan det vara vettigt att också laborera med motoreffekten. Detta är en begränsning i programmet - det förutsätter att du alltid cruisar med samma motorinställningar på en viss densitetshöjd.

För att aktivera denna funktion, välj "advanced model" inne på flygplansinställningar ("aircraft"-menyn). De förifyllda värdena är hämtade från POH till nån Cessna 172 som jag hittade på nätet. För att optimeringsfunktionen ska fungera måste alla värden vara korrekta. All information som behövs finns i POH:n på flygplan som PA28 eller C172 (dock inte i handboken för de Ultralättplan vi har i flygklubben jag är med i :-( ). Efter att ha ändrat flygplanet till "advanced model", välj planet i en flightplan under "overview", och klicka på någon av "Optimize"-knapparna.

Om någon har någon bra algoritm för att räkna ut prestandaparametrar på ett godtyckligt flygplan utifrån grundläggande data (vingbredd, stallfart, motoreffekt etc), så kan denne troligtvis enkelt generera det data som programmet kräver med t.ex Excel, och sedan klipp-och-klistra in detta i programmet m.h.a. funktionen "Import values from text file" på "Aircraft"-sidan.

Se till att inte ange för låg bränsleförbrukning för plané - då kommer programmet att omväxlande vilja stiga och sjunka för att spara bränsle .

Funktionen fungerar endast bra om varje leg är någorlunda kort, säg 50NM som mest. Vid fler än ca 15 legs kan det bli lite segt.

Jocke:

Angående "printable flightplan":

Du har rätt om att man egentligen bara behöver terrängens höjd över havet vid brytpunkter där man tänkt landa.

"Obstacle free height" är som du först uppfattade den - lägsta höjd för laglig framfart. Dvs, 1000 fot över högsta mast i närheten av tracken. Jag kan hålla med om att i områden med t.ex 1000 fot höga master, är det också intressant med terrängens höjd. Å andra sidan bör man inte planera sin färd rakt över en 1000 fot hög mast, om man inte tänkt gå rejält över den, så jag vill nog ändå stå på mig och påstå att höjd för högsta hinder är mer intressant än högsta terräng!

Programmet kan i dagsläget inte konvertera mellan t.ex TAS och CAS. Detta eftersom programmet varken lagrar QNH eller temperatur för sträckan. Att lägga in stöd för detta skulle dock behövas, för att den nya optimeringsfunktionen jag lagt till ska bli mer realistisk. Nu förutsätts standardatmosfären gälla på hela sträckan.

Angående bränsleförbrukning så går det i dagsläget inte att göra "override" på de värden som programmet räknar ut. Dock går det att lägga in "justeringar" av bränslemängden på varje ställe man tänkt landa (det går t.ex att skriva "-5" i "fuel"-fältet på ett ställe man landar på, och programmet subtraherar så mycket bränsle).

Jag har lagt in en funktion under "profile", där man kan välja om man vill ha fält som ska fyllas i för hand under flygning, i "printable" flightplan.

 

Bra där! Ska undersöka så fort jag hinner. Men en fråga, hur blir det med en sån som mig som kör med Symbian?

 

Har kikat lite på programmet nu och läst hela tråden från början. Fantastiskt jobb måste jag säga! Kul att i efterhand läsa hur det utvecklas och upptäcka att de flesta av kommentarerna har åtgärdats/tillagts i programmet.

Kul med höjdoptimeringen. Men om det är något jag saknar så är det verkligen att kunna använda flera power settings. Jag tycker detta är viktigare än själva höjdoptimeringen eftersom den höjd man flyger på vid VFR oftare bestäms av helt andra faktorer än ekonomin. (Avser då luftrum, väder, terräng, halvcirkelregler, trafik mm). Som pilot har man mycket större möjligheter att påverka ekonomin genom olika effektuttag, i synnerhet om man betalar bränslet själv. Det är ju även så att det mest optimala effektuttaget påverkas av eventuell med/motvind.

En kommentar i debatten verklig flyghöjd vs VFR. ”VFR” som flyghöjd är ju bara en ren ATS-färdplansfråga. När man genererat sin färdplan för en vald flyghöjd kan man ju bara ändra flyghöjden som angetts i ATS-färdplanen.
Noterade även ATS-färdplanen ändå måste kontrolleras m a p flyghöjd vs flygnivå. Högre flyghöjder läggs alltid in som en ”altitude” istället för FL. Jag ser inte detta som ett problem så länge man är medveten om det.

Jag skulle gärna se en mer fullständig bränsleplanering. Det jag vill kunna lägga in på min maskin är bränsle för uppstart & taxi. Dessutom skulle det vara lämpligt om man kunde få programmet att visa en fullständig bränsleplanering med erforderlig mängd för att inkludera final reserv, contingency, och alternate fuel och extra. Jag skulle även vilja ha med punkterna för Top of Climb/Descend även i den utskrivna driftfärdplanen.

En detalj beträffande bränsle/tid-beräkningen är ju att både stig och sjunk beräknas på respektive hastighet direkt från/till flygplatsen. När jag ligger i plané låter jag motorn gå på cruise power och utnyttjar överskottsfarten. Dock måste jag ju någonstans börja sakta ner inför landning och troligen även göra nån form av trafikvarv. Samma sak vid start fast omvänt. I befintlig form kommer porgrammet att beräkna lite väl optimistiskt, troligen ca 5-6 minuter och ibland ännu mer. Jag föreslår en funktion där man kan lägga in önskat antal minuter och bränsle för start respektive landning. För landning skulle man kunna tänka sig att programmet räknar ut distansen och tiden till en punkt 1000 ft rakt över fältet, och därefter plussar på önskat antal minuter och liter för trafikvarv. Liknande skulle kanske kunna göras för start också.