Hjälp med Float pow(x,y)

[sodjan]

> Känns som mer besvär än nödvändigt, byter hellre till en PIC som klarar float-beräkningar.

Eftersom du inte behöver någon större noggranhet (sensorn ger ju +/- 1 m) så är
tabelluppslagning nog helt rätt. Det handlar ju bara om att göra samma beräkningar
i förväg som du skulle ha gjort i alla fall.

Förrsten, hur för du tag på P0? Är P0 konstant under en viss tid (flygning?)?

Visst kan du göra detta på en liten processor.

[hyperion]

P0 får man mata in manuellt eller laddas ner via GPRS/WiFi.

Och jo det går säkert, men för mig känns det som mer besvär än det är värt. Antagligen för att jag inte vet hur jag ska göra

[kodar-holger]

Sorry att det gick lite fort där i morse. Det blir lätt så när jag gjort något liknande tidigare och inbillar mig att jag kan förklara. Skulle dessutom iväg på orkester-repetition!

Jag tycker definitivt inte du skall ge upp än. Även om du i slutänden byter processor så kan det vara en rimlig lektion och tillfredställelsen är stor när man klarar något sånt här.

Så här var din formel:

h= (((P0/P)^(1/5,257) - 1) * (T + 273,15)) / 0,0065

Om man skall tabellera några vettiga värden måste man ju veta vad P varierar mellan. Det vet vi inte. Däremot har du nu sagt att h kan variera mellan 0 och 300. Du tänker tydligen inte flyga vid döda havet. Vi vet också att P0 kan vara mellan 950 och 1050.

Först kan vi multiplicera båda sidor av likhetstecknet med 0,0065. Då får vi:
h*0,0065 = ((P0/P)^(1/5,257) - 1) * (T + 273,15))

Vi kan också dividera båda sidor med (T+273,15) och få
h * 0,0065 / (T+273,15) = (P0/P)^(1/5,257) - 1

Nu har vi kommit till något viktigt. Vi kan räkna ut extremvärden på vänstersidan nu genom att sätta in dina max och minvärden.

h=0, T=-30 => 0
h=0, T=+60 => 0
h=300 T=-30 => 0,008019741
h=300 T=+60 => 0,0058532193

Är du med så långt så kan vi fortsätta med den lite svårare matematiken sen.

[hyperion]

Ingen fara, jag uppskattar hjälpen. Känns som man får lov att utnyttja RUT-avdrag för läxhjälp snart

Jag menade dock att P som är uppmätt lufttryck aldrig blir under 300hPa som innebär en höjd på 9000-10000meter (beroende på vad P0 och T är såklart ) och även att P aldrig kommer vara högre än P0 vilket skulle innebära att sensorn befinner sig under havsnivå.

Så om jag förstår dina formler så torde de bli något såhär väl?:

h=0, T=-30 => 0
h=0, T=+60 => 0
h=10000 T=-30 => 0,267324697
h=10000 T=+60 => 0,195107309

[kodar-holger]

Eftersom läskunnigheten på den här sidan verkar begränsad så kan du glömma mina formler. Du hade ju skrivit vilket intervall P var i och inte intervall för h. Och den här läxhjälpen får du inget avdrag för eftersom den är gratis. Därav kvaliten också...

Vi vill göra EN tabell med färdiga beräkningar för några punkter. Om vi gör det kan vi få fram en hyfsad siffra senare även om den inte blir lika rätt som med hela formeln. Eftersom både P och P0 varierar kunde man tänka sig en tabell för varje P0 men det vore opraktiskt. Dessutom är en division billig jämfört med ^ och logaritmer. Så en tabell med olika värden på P0/P.

Lägsta värde P0/P kan få är ju vid min P0 och max P.
950 / 950 = 1

Högsta värde P0/P kan få är vid max P0 och min P.
1050 / 300 = 3,5

Så jag stoppade in formeln (P0/P)^(1/5,257) - 1 i open office calc och fick en liten tabell

Kod: Markera allt

P0/P	
1     0
1,25  0,0433606918
1,5   0,0801809906
1,75  0,1123240308
2     0,1409397118
2,25  0,1667909725
2,5   0,1904116469
2,75  0,2121908176
3     0,2324213881
3,25  0,2513297317
3,5   0,2690946591

Om du nu fått mätvärdet 518 på P och har ställt in 1013 som aktuellt lufttryck så räknar du först ut
P0/P = 1,96 (ungefär) men det finns inte i tabellen!

Så, du letar på 1,75 i tabellen. Där står det att den komplicerade uträkningen blir 0,1123... Och vid 2,0 är det 0,1409...

Ditt värde - närmast lägre värde (1,96 - 1,75) är 0,2. Det säger hur mycket av differensen mellan de båda värdena du måste addera. Men du kan inte ta 0,2*skillnaden eftersom du har flera värden per enhet så att säga. I det här fallet fyra.

Så 0.2 * (skillnaden mellan uppslagna värden vid 1,75 och 2,0) * 4 skall du addera. Har du en tätare tabell blir extrafaktorn högre.

Ungefär vid 1,96 är alltså 0,112 + 0.2*(0,14-0,112)*4 = 0,136 (Det stämmer inte om du kontrollerar med dessa siffror för jag har räknat med "alla")
kalkylbladet säger 0,135.

Sen pluggar vi in resten av formeln och antar att det är soligt och vackert. D.v.s +15

h= (0,1358 * (15 + 273,15)) / 0,0065 = 6022m.
En "exakt" beräkning hade gett 6032m.

Fler rader i tabellen ger naturligtvis bättre resultat.

Så vad blev det av din exp? Några helt vanliga +-* och tyvärr / eftersom det är en mycket dyr operation i jämförelse. Och en tabelluppslagning.

Jag rekommenderar också att ta tabellen minst ett steg utanför vad du tror att du kommer att använda. För minsta lilla avläsning på P>P0 kommer att ge dig huvudvärk och det kommer inträffa första gången du kör koden. Garanterat.

[hyperion]

Behöver jag inte skapa en ny LUT varje gång jag ändrar P0?

[hyperion]

Och om jag har en tätare tabell, säg increment av 0,05
Hur påverkas formeln då? Det du kallar extrafaktor...

[kodar-holger]

Du behöver ingen ny tabell om du ändrar p0. Det är p0/p du räknar ut först och använder för att slå upp i tabellen.

Det jag kallar extrafaktor är 1/avstånd mellan värdena. Har du 0,05 blir den 1/0,05 = 20.

http://sv.wikipedia.org/wiki/Interpolation
http://sv.wikipedia.org/wiki/Reguladetri

Herre gud, jag är antik

Termen togs bort i den svenska skolmatematiken på 1960-talet

och då var jag inte ens född förrän i slutet av 1960-talet.

[hyperion]

Tack! Nu ser jag sambandet mellan de olika siffrorna

Matte är riktigt skoj när man förstår, synd det ska vara så svårt för en

Med 0,05 intervaller så fick jag ett resultat på 6034,5 meter med samma värden som du använde för P0, P samt T

Går att få till ännu mer rättvisande resultat om man begränsar högst tillåtna höjd till 1000meter t.ex. givet att antalet värden i LUT är oförändrade.


Stort tack för hjälpen!

/Daniel S

[bearing]

Anledningen till att jag föreslog tabeller för båda termerna var att jag tänkte mig en algoritm på 8 och 16-bit heltal, med 32-bit mellansteg. Jag har nämligen aldrig använt flyttal på en mikrocontroller. Skulle behövas en 32/16-bit-division, två tabellslagningar, och en 16x16-bit-multiplikation, i så fall.

Holgers lösning ser bra ut, så om du inte behöver extrem hastighet, är den nog bättre än en heltalsalgoritm.