Vår&sommar 2012

Jag har slarvat med blogguppdateringar och det straffar sig när man väl tar sig tid att skriva. Arbetet sen i November har varit något ofokuserat och det är svårt att sammanfatta allt i samma inlägg. Det eviga bekymret med spänningsdippar kvarstår, vilket resulterat i att jag tappat förtroendet för min nuvarande plattform. Jag har gjort nya försök att designa ett eget kretskort, men behöver hjälp med caddning. Min plan är att försöka värva någon för detta, men det är svårt att hitta kompetent folk som kan tänka sig ställa upp till en rimlig peng. Allra helst hade man velat hitta en skärmflygande elektronikingenjör som arbetar med cad till vardag, som råkar ha alldeles för mycket fritid över. Men det är nog tyvärr önsketänk.

Det kort jag designat är tänkt att vara ett prototypkort för att testa min design med det nya SIM900-modemet. För att slippa kladda med t.ex. antenn-matchning så har jag för detta kort valt att plocka in en färdig GSM-modul, som monteras mha stiftlister på mitt prototypkort. GSM-modulen jag valt är Propox MMsmartGSM. Kortet drivs på 4V som går rakt in i GSM-modulen. GSM-modulen har sedan en egen regulator som tar ner spänningen till 2.8V, som används för att driva AVR-processorn. Eftersom AVR-processorn kör på 2.8V, vilket också råkar vara GSM-modulens I/O-spänning, så krävs ingen omvandling. Nästan som om någon tänkt till här 😉

För reglering av input-spänning har jag använt en färdig modul, KIS-3R33S. Den ger egentligen ut 3.3V, men kan öppnas och modiferas för andra spänningar. Inuti sitter ett MP2307-chip och gör allt arbete, och fixar önskar utspänning (4V) upp till 3A med en inspänning mellan 4.75-23V. Med det stora input-spannet borde man kunna koppla på nästan vad som helst!

För inkoppling av sensorer finns en stiftlist (CONN1) som drar ut I2C-pinnarna från AVR-processorn, ett antal GPIO, ADC m.m.

Prototypkort

Propox MMsmartGSM

Kodbasen är för tillfället en enda stor röra då jag i våras tog beslutet att separera kärnan från den applikationsspecifika koden. Detta medför att man kan använda mjukvaran till annat än en vindmätare, som jag hoppas kunna göra i framtiden. Även hårdvaran är sådan att den skall fungera som en plattform för GSM-uppkopplade sensorer.  Min inspiration har till stor del varit linuxkärnan när jag designat mitt ”operativsystem”, då jag arbetat mycket med detta tidigare. Jag har försökt porta de delar som jag finner fiffiga, medans jag förenklat andra koncept som känns onödigt komplicerade.

T.ex. har jag inget behov av en äkta schemaläggare, men vill gärna ha förmågan att strukturera min kod i olika processer. Därför har jag valt att plocka in Protothreads, en portabel trådningsmekanism. Biblioteket arbetar att skutta omkring i kod via macro-inkapslade switch-block och tricks med goto, istället för att göra äkta kontextbyten. Detta medför låg overhead och god portabilitet. Fördelen är att kod kan struktureras som om kod kör i separata processer, medans det under ytan fortfarande fungerar som ett gäng tillståndsmaskiner. Vi får se hur bra det fungerar, jag misstänker att detta approach kan försvåra debugging något.

Jag har också lagt till ett abstraktionslager för hårdvaran, en s k ”HAL”. Detta gör att jag lättare kan byta plattform i framtiden, något jag gjort ett par gånger redan 😉 Ett HAL-lager underlättar också om man vill testköra kod på sin vanliga arbetsstation, som är mycket enklare att felsöka. I ett tidigare inlägg skrev jag om hur jag gjort en abstraktion för GSM-modem, och detta blir en förlängning som sträcker sig över andra periferienheter, t.ex. timers, sockets, lagring (t.ex. på fil eller flash) osv.

I sin första utgåva kommer det finnas ett HAL för Linux, och ett för Atmegan. Det innebär att man kan köra vindmätarmjukvaran på antingen en linuxmaskin, eller på den ”riktiga” hårdvaran. Givetvis skulle linuxmaskinen också kunna vara en relativt liten sak, som t.ex. en Raspberry Pi.

På tal om Raspberry Pi så får jag direkt erkänna att jag äger en och att jag redan avfärdat den som en lämplig vindmätarplattform. Åtminstone för den typ av vindmätare som skall fungera fristående. Strömförbrukningen är många gånger högre än min nuvarande plattform, och skulle kräva stora batteri och gigantiska solpaneler. För ett olastat Linux-system på Raspberry Pi drar ca 200 mA, medans en AVR endast drar 1 mA (eller ännu mindre i sömnläge). På detta tillkommer GSM-modem i båda fall. För vindmätare med fast ström är en RPi mycket intressant, men med det nya HAL-lagret har jag flexibilitet att byta vid ett senare skede om behovet finns.

Avslutningvis tänkte jag skriva några ord om andra relaterade projekt som progressat under sommaren. Jag har varit i kontakt med Onsalas rymdobservatorium för att höra om det finns möjlighet att få ut data från deras vindmätare på Onsala. Det visade sig gå alldeles utmärkt och de matar numera ut mätdata på webben varje minut. För tillfället håller jag på att bygga om winddb, den komponent i vindwebben som samlar in data från olika typer vindmätare och slår dem samma till ett enhetligt format, så den skall stödja även denna typ av mätare. När allt är klart kommer man kunna avnjuta live-data från Onsala, utifall att nån våghalsig flygare får för sig att ta en svängom på Torkelstorpsberget.

Under huven

Syftet med denna blogg är att främst att dokumentera mitt egna vindmätarbygge. Men ibland kan det vara nyttigt att låta sig inspireras av liknande projekt. Skånes skärmklubb Club Parapente Syd har nyligen utökat sin arsenal av vindmätare med en ny mätare från italienska DPS Promatic och deras AWS-X väderstationsprodukt. Detta är samma typ av mätare som klubben redan har på Hammars backar, och är också mätaren som inspirerat mig till att börja bygga något eget.

I egenskap av nörd och tillika vindmätarfreak kunde jag inte låta bli att ta en titt på tekniken under huven. Här följer en kort sammanfattning.

Moderkort och instickskort (tryck för större bild)

Väderstationen levereras i flera delar och du kan själv vid beställning välja vilka givare och tillval du behöver.  Utöver den givna vindflöjeln och vindsnurran kan man även koppla på givare för regn, solstrålning, lufttryck, temperatur och luftfuktighet. Man kan även koppla på en LCD-display för utläsning på plats. En ganska trevlig flexibel moduläritet som jag ännu inte tagit höjd för i mitt egna projekt.

”CPU-boxen”, som innehåller all elektronik är inkapslad i en IP56-klassad plastbox. Detta innebär att den skall vara delvis skyddad från damm, och klara av att man spolar boxen med en vattenslang utan läckage. Inget jag har planer på att testa, men med tanke på Sveriges väderlek känns det inte orimligt att det kan hända.

I boxen finns en ganska redigt 12V blyack. Gissningsvis har man valt blyack över Lithium-kemi för att underlätta solpanelsladdning och ev. för att bredda väderstationens temperaturspann.

Elektroniken består av två kretskort, ett s k ”TCX”-kort och ett ”AWX”-kort. TCX-kortet innehåller GSM-modem, styr-CPU, spänningsreglering & matning, batteriladdning och andra mer generella komponenter medans AWX-kortet tillför för all väderstationsfunktionalitet. Man kan väl se TCX-kortet som ett moderkort och AWX-kortet som ett slags instickskort. En snabb visit på DPS Promatics hemsida avslöjar att de utöver sina väderstationer även säljer andra GSM-uppkopplade prylar, t.ex. en grindöppnare, som sannolikt också bygger på ett TCX-kort, fast med ett annat instickskort.

Gränssnittet mellan korten utgörs av 4 st signaler. De syns i ovan bild som 4 st färgglada kablar med varsin tvinnad jord (4 st svarta kablar). Jag har inte brytt mig om att karakterisera signalerna, men jag misstänker att det är ett seriellt protokoll med t.ex. en data-pinne i vardera riktning, en klocka och kanske en interrupt-pinne? Signalnivån ligger på 3.3V. Förutom de färgglada kablarna finns 12V spänningsmatning (tvinnad röd&svart kabel i bild) och en okänd grå kabel. Se nedan för min teori kring denne.

Båda korten har varsin Atmel Atmega64L mikrokontroller, dvs en något biffigare variant jämfört med Atmega328p som används i mitt bygge. Mikrokontrollern på TCX-kortet kör på 3.3V, medans CPU-matningsspänning på AWX-kortet ligger på 5V. Jag finner det mycket märkligt att de använder olika matningsspänningar och tvingar säkerligen på diverse nivå-omvandlingskomponenter mot gränssnitt-signalerna.

Eftersom väderstationen även kan avlyssnas per telefon innehåller AWX-kortet ett par (2) externa minnen där ljudklipp lagras. Dessa klipps sedan ihop under pågående samtal för att bilda de upplästa meningar man hör i luren. I min design valde jag ganska tidigt bort att utföra röstsyntetisering i vindmätaren för att minska krav på minne, CPU och för att inte tumma på ljudkvalité och planerar istället att göra det på en separat server.

Något jag inte helt funderat ut är hur ljuddata överförs tillbaks till TCX-moderkortet. Som jag nämnde tidigare finns det en ”okänd grå kabel” mellan korten. Jag misstänker att denna kanske bär ljuddata från instickskortet tillbaks till GSM-modemet. Just nu har jag inget oscilloskop nära tillhands, men mätning med enkel multimeter på den grå kabeln under pågående samtal visar inte på några svängningar likt en analog signal. Behöver ett riktigt oscilloskop nu! Den grå kabeln och närliggande komponenter är för övrigt riktigt dåligt lödad, som kan vara en indikation på att de monterats manuellt i efterhand. Jag vet att röstsyntetisering ej ingår i standardutbuden, vilket kan vara ytterligare en ledtråd till att den grå kabeln bär ljuddata.

Dålig lödning! Plasten på kontakten är delvis värmeskadad/smält.

När korten strömsätts startar stationen upp och börjar genast ge ifrån sig ett tickande ljud från sin lilla summer på undersidan. Detta trodde jag först var ett trasigt relä, men det skall tydligen vara så. Inte helt intuitivt. I sitt standardläge är inga Status-dioder tända och den tickar på. En gång i minuten piper den till och STATUS + GSM-dioderna blinkar kort.

Vad jag senare insåg är att detta är väderstationens sätt att indikera sin sömncykel. I sin fabriksinställning är nämligen mätaren konfigurerad till att sova 1 minut, vakna, titta efter inkomna konfigurations-SMS, behandla dem och slutligen somna om. Detta är ett sätt för stationen att spara ström eftersom den då kan stänga ner stora delar av komponenterna under sin sömncykel.

Varför man inte använt ett avbrott istället för att periodiskt polla SMS-inkorgen är ett mysterium. Modemet sover inte eftersom det i alla lägen måste kunna svara på ett inkommande samtal, och i alla modem jag någonsin arbetat med kan man också få modemet att signalera vid inkommande SMS, trots att de ligger i partiell sömn. Jag tror någon har varit lite lat i sin implementation här 🙂 Följden blir att det tar upp till 1 minut att få svar på sina konfigurations-SMS. Segt! Jag var först osäker på om jag formaterat mitt meddelande rätt och hann skicka flera olika meddelanden innan jag fick svar på det första och poletten trillade ner.

Utöver sin uppringda funktionalitet kan väderstationen även sända sin mätdata till en server via en GPRS-anslutning. Detta är metoden som används för att samla in vinddata till CPS vindwebb och tanken är att även denna mätare skall kopplas på samma sida. Därför har jag även testkört denna funktionalitet i den nya mätaren. Tack å lov verkar paket-protokollet som DPS Promatic använder för att sända mätdata vara konsekvent med den äldre stationen, trots att de kör olika versioner av mjukvaran. Det gick förvånadsvärt smärtfritt att få den nya stationen att rapportera in mätvärden i databasen. Ett issue som måste lösas är dock att den nya stationen sänder vindhastighet i m/s, medans den gamla sänder i km/h. Det finns inte heller något sätt att särskilja paketen åt, bortsett från stationsnamn. Men man vill ju inte gärna hårdkoda in stationsnamn i mjukvaran som tar emot och behandlar paketen från vindmätarna, det blir snabbt ohållbart.

Jag mailade DPS Promatic och de hade inga råd att ge. Deras bästa tips var att uppgradera den gamla stationen så även den sänder med enhet m/s. På längre sikt är det tanken, men just nu inte möjligt eftersom jag för tillfället sitter 30+ mil bort från Hammars backar. Givetvis tillåter inte väderstationen fjärruppgradering. Doh! DPS Promatic kommer skicka en ny version av mjukvaran som jag kan använda för att uppgradera mätaren på plats i Hammar. Kommer kännas lite konstigt att sitta ute i naturen och programmera om en väderstation med laptop 🙂

Ni kan givetvis också räkna med en analys av mjukvaran så fort jag fått en kopia. Lite disassembly har ingen dött av!

Förhoppningsvis blir det montering i Vitemölla inom några veckor. Jag måste bara hitta lite gummi att täta kabelgenomföringshålen ordentligt. Slut på rapport!

Rippel?

 

.. Och då menar jag inte rippel som i kolarippel på glassen utan något helt annat. Ovan mätning illustrerar matningsspänning till vindmätaren under exekvering av ett enkelt kommando (beräkna stackstorlek). Jag är mycket skeptisk till att det är OK med dessa jitter på matningen. För AVR-processorns del, säkert. För min kod? Troligtvis inte. Att spänningen skulle ligga helt stabil förväntar jag mig inte, men inte heller att den skall variera i denna grad. Mätningen sker med relativt hög frekvens, varje ruta motsvarar 200 ns. Den största svängningen på linan varar alltså inte mer än ca 20 ns. Är det OK? Detta är trots allt på matningen till processorn, dvs efter buffertkondensatorer gjort sitt utslätningsarbete på den ”råa” spänningen.

Databladet specar acceptabel matningsspänning från 2.7V upp till 5.5V, men jag kan tänka mig att man måste ta höjd för en ändring i spänning om det skall göras under körning. Gränsen för att trigga AVR-processorns Brown-Out Detection ligger vid 2.5V om det är aktiverad. Om det inte vore för att min ISP-programmerare är nerpackad i någon av mina hundratals flyttlådor hade jag aktiverat det direkt, för att säkerställa om jag verkligen är så lågt ner som 2.5V och nosar. Det är åtminstone vad mitt oscilloskop antyder.

Jag misstänker att de korrupta tecken jag ibland ser på den mjuka serieporten också är kopplade till spänningsrippel. En teori är att klockornas precision påverkas av varierande spänning vilket leder till baudrate-jitter. I 9 av 10 fall uppstår korrupta tecken vid hög last, t.ex. när modemet suger ström eller om jag kör något tungt kommando över vindmätarens kommandorad.

Nästa steg blir att styra upp ett vettigt kraftaggregat. En USB-port är uppenbarligen inte pålitlig. Jag hade hoppats att de caddat Seeduinon med överdimensionerade bufferkondensatorer, men det är ju uppenbarligen inte fallet.

Imorgon skall jag försöka köra ett liknande test med batteri. Börjar sakna min verkstad nu, där har jag riktiga stabiliserade labaggregat. Dessvärre är dessa också nerpackad i flyttlådor. Ynk!

I övrigt går arbetet framåt. Utlovad socketmodul (föregående inlägg) är på plats, likaså tester för denna. Det börjar bli hög tid att koppla ihop alla färdiga pusselbitar:

• Avläsning av vindmätare (hast. och rikt.): Klart
• Modemkonfiguration och styrfunktioner: Klart
• Uppkoppling TCP-socket över GPRS: Klart
• Kommandorad: Klart
• Debugkonsol: Klart
• Bootladdare: Klart
• Lagring av användarinställning på EPROM: Halvklart

Google vs WindWiz 1-0

Visste ni att en tillsynes spartansk hemsida som Google.se har en helt groteskt stor indexsida (filstorlek)? Ialla fall från en stackars liten Arduinos perspektiv. Försök ladda ner och tolka ett HTML-dokument på 10+ KB på en device med 2 KB ram och gör något vettigt med det. I dare you! I double-dare you motherf*cker! .. Jag blev rätt ”ägd” ialla fall.

Veckorna sen senast har varit köriga men några timmar jag ändå hittat till programmering. GSM-prylarna i vindmätaren är nu uppdelad i två modulen, en Telit-modul som innehåller allt hårdvarunära kring den GSM-modul jag använder, och en annan portabel AT-modul som sköter kommunikation enligt AT-standarden (nåväl, nära nog..). Denna separering har gjort det möjligt att bygga mer strukturerade testfall för AT-modulen som nu kan köra precis lika bra på min arbetsstation som i vindmätarhårdvaran. När modulen kör på min arbetsstation tunnlas trafiken över en serieport till modemet medan AVR-processorn hålls i resetläge. När modulen kör på vindmätaren exekverar koden på AVR-processorn och pratar direkt med modemet. I båda fallen är in/ut-data från modemet ”live” och korrekt. Tack vare detta har jag kunnat göra en hel del viktiga buggrättningar och även kunnat utöka funktionalitet utan att störas av tråkig felsökning som lätt uppstår när man jobbar med dessa ettriga småprocessorer.

Status just nu är att jag kan ansluta TCP-sockets och även göra datautbyte av enklare sort (tillståndslöst). T.ex en HTTP-fråga. Mer än så behövs egentligen inte för vindmätaren, den skall koppla upp, skicka sin data och på sin höjd ta emot ett kvitto. Eller om det nu blir ett e-post (se föregående inlägg). Måste nog suga lite mer på den nöten.

Något jag noterat under tiden jag jobbat med modemet via sitt ”tunnel-läge” är att jag hittills inte drabbats av några konstiga resetfel eller ominitieringar. Förvisso är underliggande system på min PC brutalt mycket kraftigare och det vore ganska naivt att jämföra t.ex. timing eller buffertstorlekar mellan en AVR och en PC, men ändå. Inga problem! Vilket tyder på att det antingen finns en bugg i annan del av min kod, eller att det verkligen är ett hårdvarufel. Säkringen på Arduinon kanske slår till? Hur undersöker man sånt?! Jag har labbat lite med avlyssning på RESET-signalen mha mitt sprillans nya PicoScope (USB-oscilliskop) och hittills inte sett några dippar i signalen. Big need på en riktig elektronikingenjör.. Jag i egenskap av kodapa kommer inte långt här.

För tillfället väljer jag att blunda för dessa problem och fortsätta jobba i tunnel-läge och försäkra mig om att kommunikationskoden är korrekt. Nästa steg blir att implementera en modul för sockets, som inkapslar uppkoppling och hantering av TCP-sessioner via AT-modulen på ett snyggt och lätt sätt.

 

Höghastighetsprogrammering

Idag har jag programmerat i 150 km/h! Känns som taget ur SJs reklamkampanj ”Försök göra det där i bilen, om du kan!”. Söndagen har spenderats ombord ett Öresundståg upp till Göteborg,.. och några timmar senare tillbaks till Skåne igen. Mycket tid att slå ihjäl med andra ord. Tur att vindmätaren är mobil och lätt att plocka med i väskan. Många var det som stirrade misstänksamt på mig när de gick förbi mitt uppdukade ”elektroniksmörgåsbord”. Någon tänkte säkert ”GOD DAMN THATS NEERDY!”. Men det bjuder jag på, det gäller att ta vara på den lilla tid man har 😉

Kan för det första meddela att vindmätaren numera kan upprätta TCP-anslutningar. Jepp! Fet milstolpe! Ingen data strömmar över transportsessionen ännu, men det är bara en tidsfråga. Detta innebär att jag t.ex. skulle kunna skicka data direkt till en webbserver, eller annan mottagare av vinddata. Jag har även övervägt att låta e-post vara mitt ”huvudinterface” för vindmätaren, dvs att varje batch av mätpunkter skickas som ett mail. Detta har fördelen att en separat mailserver kan buffra mätpunkter på ett mailkonto, om min egna server skulle gå ner av någon anledning. Detta är ett problem hos den kommersiella AWS-X mätaren vars UDP-paket försvinner ut i cyberrymden närhelst ingen lyssnar. Med en maillösning kan man dessutom sprida mätpunkter på ett intuitvt sätt — mailinglistor. Vinddata anländer och sprids automatiskt till ett godtyckligt antal mottagare. Helt och hållet genom existerande teknologi!

Det råkar även vara så smidigt att GSM-modulen som används, Telit GE-863 QUAD, har färdig funktionalitet för e-post. Den kan hantera allt från autentisering, SMTP-protokoll och även kodning av attachmentdata (BASE64 etc). Den enda nackdelen är att det sannolikt blir mer data att sända jämfört med att uppfinna ett eget binärformat. Beroende på hur många mätpunkter som batchas så kan overhead för SMTP bli rätt stor del av paketet. Dock lär det inte vara något bekymmer med dagens ”trafikvänliga” mobilabb. Själv betalar jag 29 kr/mån extra för ”surf” i mobilen. Fett värt!

Jag skall ge detta lite mer tid att mogna innan jag tar ett beslut, men måste erkänna att det väger tungt för att välja existerande teknik över att återuppfinna hjulet om det bara handlar om några kronors skillnad i trafikkostnad.

Som vanligt har jag även en lite mindre rolig nyhet att dela. De tråkiga ”omstarts”-problemen som jag då och då stött på är tillbaks. Dessa har under hela projektets gång plågat mig och det retar mig oerhört att jag fortfarande inte lyckats hitta källan till problemet. Symptom är spontana omstarter av vindmätaren vid exekvering av slumpmässiga kommandon. Oftast i samband med interaktion med GSM-modem. Jag har nämnt problemet i tidigare inlägg och undersökt olika uppslag. Några gånger tror jag att jag hittat orsaken, men det har tyvärr visat sig att det bara lindrat i olika grad, ej botat. Ibland har problemet försvunnit i flera veckor, men nu är det tillbaks.

I inlägget ”Betongväggen” kan man läsa om de idéer på orsak jag hade då. Stor oro låg i hårdvaran, t.ex. spänningsfall, strömspikar osv. Det har troligtvis inget med saken att göra, med tanke på att jag nu sett samma fel i tre generationer av hårdvara. Hur som helst är sådant väldigt svårt att utesluta utan att köpa in fler enheter. Dyrt! Så vad annars kan orsaka spontana omstarter? På en vanlig PC-maskin hade jag varit orolig för överskrivning av programminne, dvs att någon del av programmet skriver över sin egna kod under körning av misstag. Detta kan få högst slumpmässigt beteende, som oftast slutar i att processorn hoppar till minne där den stannar. När detta händer kommer ”watchdoggen” att bita och enheten gör en omstart. Men en AVR-processor använder sig av en s k Hardvard arkitektur vilket innebär att instruktioner och data ligger i separata minnen. Instruktionerna finns enbart i flashminnet som ej kan modiferas från vindmätaren under körning. Alltså borde enheten vara immun mot denna typen av fel. Vad återstår då som kan orsaka hopp till oönskade adresser? Tja, det kan vara ett hopp till en pekare som felinitialiserats. Men med tanke på att jag använder oerhört få funktionspekare och i övrigt undviker trixig pekarartimetik känns detta också osannolikt. Alla adresser genereras automatiskt av länkaren, vilken vi får hoppas gör ett korrekt jobb.

Just nu undersöker jag om programinstruktionerna kanske blivit felaktiga innan de ens hamnat i det ”skrivskyddade” flashminnet. Detta skulle kunna leda till ett scenario likt ovan. De skrivs dit av min egna bootladdare, Magboot. Kan man lita på att den gör ett korrekt jobb? Jag vet inte! Det är ju jag som skrivit den 😉

Förra inlägget handlade delvis om Magboots nya integritetskontroll av data som skickas över serielänken. Mitt huvudspår just nu är att utöka denna funktionalitet så att integritetskontrollen även inkluderar skrivning till flashminnet. Datan skall alltså kontrolleras efter serielänksöverföring och efter flashskrivning. Först då kan jag med 100% säkerhet säga att programmet som ligger i vindmätaren är samma program som jag kompilerat på min arbetsstation.

Jag återkommer i nästa vecka med en uppdatering. Kanske. Om jag orkar. Och har tid. Och ifall det inte blåser SV 6-8 m/s, som långtidsprognosen visar just nu.

PS. Mina tågtester visar för övrigt att vindmätaren har GSM-täckning på Helsingborg C, a.k.a mobildödsstationen, där min egna smartphone sällan har en chans. Ganska coolt! DS.

Size matters

Flygsäsongen lider mot sitt slut, åtminstone för alla oss som ogillar att flyga i minusgrader. Någon vindmätare finns fortfarande inte ute på fältet, vilket är lite av en besvikelse. Arbetet fortgår dock fortfarande, om än långsamt.

I föregående vecka har jag slutfört arbetet med bootladdaren och det utökade stödet för flashladdning över en mjukvaruserieport. I all hast adderade jag även en grundläggande integritetskontroll för serielänken, vilket delvis kan användas för att verifiera serieportsimplementationen, och givetvis för att förhindra timmar av meningslös debugging som orsakats av att inkorrekt programvara skrivits ner i flashminnet på vindmätaren. Ett enstaka bitfel här och där kan kanske verka ofarligt, men tro mig — MYCKET kan gå snett.

Med denna nya funktionalitet på plats i Magboot kan jag nu återgå till att hacka på själva vindmätaren igen! Hurray!

Avslutar med lite Magboot-statistik som jag utvunnit ur mitt källkodsförråd. Nedan plot visar binärstorlek för Magboot mot en tidslinje (uttryckt i commit, i kronologisk ordning). Man kan tolka grafen som programmets storlek över tid, sedan jag började utvecklingen i slutet av Februari.

I och med introduktionen av stöd för mjukvaruserieport bygger Magboot numera två binärer, en med stöd för hårdvaruserieport (”HWUART”-versionen) och en med det nya mjukvaruserieportsstödet (”SWUART”-versionen). Den blå linjen visar SWUART-storlek och den röda representerar HWUART-storlek. Båda versionerna integrerar givetvis det nya verifieringsstödet. Grafen är egentligen ganska meningslös att titta på, men man kan dra några slutsatser:

1. Ingen version överstiger 1024 bytes, vilket är den övre smärtgränsen. En tidig version av Magboot vägde faktiskt in under 512 byte och fick därmed plats i en ännu mindre bootsektor, men fick skrotas i förmån för mer läsbar kod och ny funktionalitet.
2. SWUART-versionen väger in på ca 100 bytes mer — ganska nätt med tanke på hur mycket mer mjukvara det handlar om.
3. Commit #4 adderade stöd för sidbuffring av serieportsdata. Detta gjorde överföringar betydligt mer tillförlitliga.
4. Commit #8, #10 minskar storleken genom att plocka bort överflöda kommandon och viss EEPROM-hantering, som Magboot ändå inte har stöd för.
5. Commit #11 ökar förvånadsvärt mycket för den lilla kodmängd som tillförs. Det handlar om en funktion som gör att Magboot ej exekverar utan lämnar över till programmet i flash, förutsatt att vissa villkor uppfylls. Används för att snabba upp ”normal” omstart av enhet. Detta är ett typiskt ställe i koden där man troligtvis skulle kunna optimera ytterligare för binärstorlek.
6. Vid commit #21 introduceras SWUART-versionen, som även får HWUART-versionen att minska något i storlek, vilket jag inte kan förklara. Skillnaden är att viss kod brutits ut i en separat fil. Min erfarenhet av kompilatorer är att optimeringsrutinerna oftast fungerar bäst när kod samlas i samma fil. Detta beror på att ”whole-program optimization”, dvs att optimering även sker i länkfasen av körning, ännu är en omogen teknologi i GCC. Förvisso har AVRs GCC port troligtvis fallit väldigt långt bakom vad det gäller optimeringar, vilket är trist. Håller ett öga på LLVMs AVR port, that’s for sure!
7. Likt #8 plockar commit #22 bort ännu ett kommando som blivit överflödigt under utvecklingen. Den bidrar till ett välkomnat drop i filstorlek.
8. Sist men absolut störst är #25, som adderar det nya stödet för integritetskontroll. En ökning på ca 100 bytes, vilket är i överkant. Jag kommer förmodligen bli tvingad att se över koden igen, checksummeringsrutinen är långt ifrån ”optimerad för storlek”. Det är i stunder som dessa när högnivåprogrammeraren i mig skriker: ”Men jag ska inte behöva ta hänsyn till filstorlek när jag uttrycker mig i programkod!”.

Windspeak

Den upplästa utläsningen av vinddata via telefonsamtal är fortfarande den mest använda metoden för att kolla av vinden bland CPS medlemmar. Inte så konstigt, eftersom bara 1 av 4 mätare internetuppkopplad, och dessutom tror jag många föredrar att slippa trycka och navigera i menyer ute i starkt solljus. Ett samtal är en knapptryckning, tryck luren mot örat och vänta. Easy as dell!

Att ljudkvalitén sedan är såpass dåligt att man ibland tvingas ringa två gånger eller att informationen som ges är ytterst begränsad verkar få bry sig om. Men faktum är att det enda sätt att bilda sig en uppfattning om trender är att gång på gång ringa mätaren med nån halvtimmes mellanrum. Det skulle vara intressant att veta hur mycket pengar CPS medlemmar totalt lägger per månad i mobilsamtal till mätarna. Med en öppningsavgift på 79 öre och i snitt 30 sekunder samtal så hamnar vi på 1.1 kr/samtal (åtminstone med min leverantör). Jag gör säkert 10+ samtal till vindmätaren per flygdag om jag är i (eller avser att åka till) Ravlunda eller på västkusten (för Hammar använder jag givetvis webben!). Alltså rör det sig om ca 11 kr/dag och medlem. CPS har 200 medlemmar, varav säkert 50 är riktigt aktiva. You do the math!

Inte nog med att den uppringda funktionalitet fungerar dåligt i existerande mätare, den utgör också en stor tröskel för min egna implementation. Ett stort bekymmer är den icke-deterministiska strömförbrukningen som uppstår när X antal skärmflygare bestämmer sig för att ringa ner mätaren på en solig dag. Telefonsamtal över GSM-nätet är den i särklass dyraste funktionen i en vindmätare med avseende på strömförbrukning. Ett annat problem är att röstsyntetisering ökar krav på både processorkraft och lagringsyta. Därför har jag sedan dag #1 strykt denna funktion från mitt egna bygge.

Planen har istället varit att erbjuda samma funktionalitet via en landlina där man ej behöver tumma på ljudkvalité, inte har några begränsningar i lagringsutrymme och dit uppringningskostnaden potentiellt kan bli lägre. Jag ser bara fördelar!

I teorin behöver riggen inte vara mer avancerad än en telefonsvarare vars meddelande byts varje gång en vindmätare sänder en ny rapport. Inspelning av nytt svarsmeddelande sker automatiskt via mjukvara som hämtar vinddata från webben och spottar ur sig en ljudfil som sedan matas till telefonsvararen. Tack vare att större delen av telefonnätet numera digitaliserats och var och varannan kotte har tillgång till ”IP-telefoni” behöver man heller inte skaffa någon dyr analog telefonväxel eller annan utrustning, allt sköts av en vanlig dator. Inkommande samtal anländer via nätverket, behandlas av telefonsvararmjukvaran och svar skickas tillbaks — via nätverket.

Asterisk är en sådan ”telefonsvararmjukvara**” för Linux. Förutsatt att du har ett IP-telefoniabb. hos en operatör som tillåter inkoppling av annan utrustning än deras egen är det bara att tuta och köra. Det råkar falla sig så väl att min bredbandsleverantör T3 just lanserat ett nytt IP-telefoniabbonemang som lämpar sig ypperligt för detta syfte — T3 Zero. Månadskostnad 0 kr. Kostnad att ta emot samtal 0 kr. Ni förstår! Givetvis har de gjort ordentliga påslag på utgående samtal, men eftersom min telefonsvarare aldrig någonsin skulle få för sig att ringa ut på egen hand kan detta aldrig kosta mig mer än 0 kr. (Ska bara läsa det finstilta också 😉

Idag har det ösregnat utanför och jag hittade tid till att snickra ihop ett testprogram för att generera ljudfiler från aktuell vinddata. Detta är den komponent som skapar det nya svarsmeddelandet som sedan matas till Asterisk, telefonsvararen. Program, döpt Windspeak, jobbar mot WindWiz API och fungerar som vilket tredjepartsprogram som helst. Röstsyntetiseringen är väldigt enkel och består av ett större antal ljudklipp som fogas samman till ett meddelanden. Just nu är slutresultatet i allra högsta grad opolerat, men duger väl som ett ”proof-of-concept”.

Programmet körs via en terminal och har relativt få växlar.

$ windspeak.py -s Svetlana -o test.wav 

Denna rad beordrar Windspeak att hämta ner senaste mätdatan via API, syntetisera ett meddelande med rådande vindriktning och vindhastighet för att slutligen spara resultatet i test.wav. Som en liten bonus kan man även välja syntetiseringsröst med växeln -v. För tillfället kan man lyssna på min eller min flickväns ljuva stämma 😉 Den lilla källkod som utgör Windspeak v 0.1 Alpha finns redan för beskådning på GitHub bland WindWiz källkodsförråd.

Avslutar med ett litet demo!

** Att kalla Asterisk för en telefonsvararmjukvara är kanske årets understatement. Asterisk är allt du någonsin önskat inom telefoni och kan konfigureras för oändligt många fler användningsområden.

CPS vindwebb goes mobile

Det tog sin tid, men nu är den äntligen klar. Den upphottade och ombyggda vindwebben för skärmklubben. Jag har i tidigare inlägg hintat om mitt missnöje med vindwebben i mobilen och hur jag experimenterat med jQuery Mobile. Idag rullar jag ut en ny version av vindwebben. Nytt i denna upplaga är stöd för smartphones (iPhone & Android etc) och utökad stöd för äldre mobiltelefoner. Genom att surfa till http://vind.minimum.se/ kommer du numera automatiskt slussas vidare till en lämplig sida för din telefon, surfplatta eller dator.
Eftersom det inte är helt trivialt att kategorisera besökare på detta vis kan man även växla manuellt mellan sidorna med länkar. Jag ser automatslussningen som en grovsållning. Den fixar de flesta ”stora” mobilgrupper inom smartphones, t.ex. iPhone, iPod, iPad, alla Android-lurar, Windows Phone och Blackberry. En mycket svårare uppgift är att skilja på vanliga webbläsare och äldre mobiltelefoner, här finns inte lika tydliga avgränsningar. Strategin jag använder för tillfället är att försöka matcha vanliga nyckelord och leta efter särskilda HTTP-fält som WAP-telefoner har en tends att använda.

Huvudsidan är även ”plussad” med ändringar som CPS-medlemmar önskat:

• Vindriktning över tid som linjegraf. Även om ”radarbilden” med fördelningen av vindriktning är användbar och lätt att förstå brister den när man försöker få en uppfattning om vindriktningens trend. Vindradarn kommer numera representera de 2 senaste timmarna. För vindriktning på längre sikt fungerar den nya linjegrafen mycket bättre och täcker ett par timmar bakåt i tiden.
• Automatisk uppdatering. Sajten läser ut vald vindmätares uppdateringsfrekvens och sköter uppdatering under huven utan att hela sidan laddas om. Detta sätter givetvis lite högre last på webbservern, men i och med att alla grafer är cachade och datamängden som utläses via API är minimal blir trafikmängden och systemlast i princip försumbar (don’t quote me on that..).
• Högerjusterad Y-axel i diagram, för lättare utläsning av nya mätpunkter. En rätt given uppdatering, då jag själv suttit många gånger och manuellt försökt följa liner från högerkanten till Y-axeln på vänsterkant.

En annan fundamental förändring är att alla tre versioner av sajten numera jobbar helt och hållet mot API:t. Detta innebär att sajten lika gärna skulle kunna köra på en annan server, detta till skillnad från den gamla sajten som använde en SQL-koppling mot databasen med mätpunkter. Utöver vinsten med ett mer modulärt system är det också ett bevis på att API:t är tillräckligt användbart för att användas i ”produktionsmiljö”. I och med att sajten jobbar med API:t kan den också ansluta till andra vindmätare som är kopplade på systemet i framtiden utan ändring. För tillfället finns bara 2 (Svetlana och Teststationen), men jag hoppas på att mitt eget bygge snart skall gå att prototypköra via samma system snart.

Avslutar med lite bilder som visar de tre olika sidorna ”in action” (klicka för större bild):

Kändis

Ni läser väl skärmflygarnas egna tidning Hypoxia? I senaste upplagan (2011-2) pratas det om Svetlanas och ”hennes” webbplats http://vind.minimum.se/ i ledaren. Pretty cool! Även Skånes Drakflygarklubb har fått upp ögonen för sajten och nyttjar den flitigt. Det är alltid kul när folk faktiskt drar nytta av sånt man sitter hemma och knåpar ihop om kvällarna 🙂

.. För er som är nyfikna på hur arbetet med vindmätaren fortlöper har jag lite nyheter:

• Stand-alone batteridrift fungerar! Egentligen ingen jättestor ansträngning från min sida, men jag har äntligen fått tummen ur och konstruerat en adapterkabel av ett par kontaktdon från ett gammal DC-nätagg.
• Batteriladdning verkar OK via USB-port. Detta innebär att jag kan ladda vindmätaren vid datorn och sen bära iväg med den. Med 3 Ah har jag uppskattningsvis flera dygns batteritid på en laddning. Solpanelen kommer senare!

I och med batteridrift har vindmätaren dock fått ett nytt beteende: GSM-modemet startar upp automatiskt. Detta är sker sannolikt pga att laddfunktionaliteten i modemet måste vara aktivt för att undvika Dramatiska bränder; närhelst modemet upptäcker att dess strömkälla är ett batteri startar den upp för att skydda batteriet. Kanon, ur ett säkerhetsperspektiv. Mindre bra om man delar serieporten mellan modemet och omprogrammeringsfunktionen, som jag gör. Plötsligt kan inte programmeraren arbeta ostört vid uppstart, då modemet feltolkar programmeringskommandon på serieporten som AT-kommandon och det blir ett jävla liv. Programmeringen misslyckas och modemet är förvirrad. Inte särskilt ”win-win”.

Som en workaround för denna misär håller jag nu på att flytta programmeringsfunktionen till den andra ”mjukvarudrivna” serieporten som endast används för felutskrifter och debug när vindmätaren väl är uppstartad. Detta innebär att min bootladdare, Magboot, kommer ha möjlighet att ladda mjukvara från den dedikerade serieporten hos Atmega-procssesorn och via en valfritt definierad serieport över 2 godtyckliga I/O-pinnar. Vindmätaren kommer att förlita sig på den senare metod och därmed finns det inte längre någon risk att modem och programmeringsfunktion pratar i mun på varann.

Initialt var jag orolig att implementationen av en sådan mjuk serieport inte skulle få plats i den begränsade lagringsyta som en bootladdare är förvisad till. Motsvarande implementation i vindmätaren upptar (uppskattningsvis) 1 kb flashminne, vilket är på tok för stort. Magboot i sin helhet får plats på ca 600 bytes. Tack och lov finns det mycket funktionalitet i vindmätarens mjuka serieport som inte behövs och som kan skalas bort i magboot. Till exempel finns inget behov av full duplex, dvs, att parterna driver serieporten i båda riktningarna samtidigt. Magboot och dess serieprotokoll är konstruerat på så vis att endast värddatorn är drivande med förfrågningar.

En annan nerbantning är databuffring. Den mjuka serieporten i Magboot drivs ej av interrupt och har inga buffrar. Tecken läses från serieporten ett åt gången. Detta är OK eftersom Magboot inte ägnar sig åt något annat än att vänta på data. Detta hade troligtvis fungerat mkt dåligt i vindmätaren där flera händelser kan inträffa parallellt, t.ex. schemalagda aktiviteter som skall köra, utsändning/mottagning av data till/från modem osv. Eftersom en serieport är asynkron är det viktigt att läsning och skrivning till bussen sker utan störningar. Ännu en gång kan jag glädjas åt Magboots enkelhet!

Häromdan pysslade jag ihop en testversion av Magboot med den nya mjuka serieporten. Filstorleken ökade knappt 100 bytes! Det är en nerbantning med mer än 10x. Jag är mycket nöjd 🙂 Nu återstår bara att rätta buggarna också …

Juniuppdatering

Jag måste erkänna att det fina vädret har satt käppar i hjulet för vindmätarbygget. Det är hög tid att posta lite livstecken!

• En demo-version av vindsajten i mobilformat (se nedan inlägg om jQuery Mobile) finns numera på webben för allmän beskådan. Den är särskilt trevlig att besöka med en smartphone då man får flashiga slide-övergångar mellan sidor och andra ögongodis. Peka din webbläsare eller telefon till http://vind.minimum.se/demo/. Man kan även logga in med användare ”demo” och lösen ”demo”. Tanken är att förutom att göra vinddata lättillgängligt även göra väderprognoser och inlägg från andra flygare möjligt. Den är absolut i experimentfasen än så länge, men fungerar bra som ett proof-of-concept för jQuery Mobile-plattformen.
• Häromveckan rullade SMHI äntligen ut en mobilapp för sina väderprognoser. Kanske inte jättespännande för detta projektet tänker ni kanske? Fel! En mobilapp betyder nämligen att SMHI numera också exponerar sin data via JSON. För den som är intresserad av att integrera SMHIs väderprognoser i andra applikationer, t.ex. en mobil vindsajt, är detta glada nyheter. Med en väldefinierad JSON-datakälla slipper man tolka SMHIs vanliga HTML-sidor för att utvinna väderdata, något som är bökigt, tråkigt och jobbigt att underhålla. SMHI har inte officiellt gått ut med sin JSON-data, men det var inte direkt rocket-science att ”knäcka” deras system.
• GSM-kommunikationen är på plats i vindmätarbygget. Detta har varit i särklass den mest dryga komponenten att implementera hittills. Vägen hit har varit kantrad med alla tänkbara problem, allt från stacköverskrivningar, fel i klockfrekvenser, avsaknad av vissa utdragna pinnar, oförmåga att hantera strömspikar vid GSM-registrering på GSM-nät osv. Helt ärligt tror jag inte allt fungerar helt 100% ännu, men jag är ganska nöjd med att ha ett fungerande kommandoradsinterface där jag kan åtminstone kan exekvera AT-kommandon och läsa tillbaks dess svar.
• Det har tillkommit en ny debugfunktion för att mäta stackutnyttjande. När man bara har 2 KB RAM-minne är det lätt att man råkar tänja på gränserna utan att det märks innan det är försent 😉 Denna funktion gör det möjligt att mäta maximal stackstorlek som observerats sedan uppstart av vindmätare. Se GitHub för detaljer.

Här följer lite detaljer kring SMHIs JSON-API, mest som en minnesnotering för framtida bruk:

• GPS-koordinater i WGS84-format används för att välja plats för väderprognos. SMHI använder geonames.net webbtjänst för att översätta namn på städer och andra platser till GPS-koordinater.
• JSON-data hämtas från http://ppdyn.smhi.se/produktportal-1.0/ws/products/weatherdata/LAT/LON/forecast där LAT, LON är GPS-koordinatens latitud resp. longitud-komponent. T.ex har Ystad GPS-koordinat 55.42919, 13.81710 och därför blir adressen http://ppdyn.smhi.se/produktportal-1.0/ws/products/weatherdata/55.42919/13.81710/forecast.
• SMHI har försökt att skydda sig från ”stöld” av data genom att neka tillgång såvida inte en särskild nyckel bifogad i HTTP-anropet. Denna nyckel adderas som en extra HTTP-header kallad ”Key”. Jag är osäker på om denna nyckel någonsin ändras, men a67b9d6b5efa0d10617827d726b424d0 fungerar bra för mig.
• Exempel på hur datan kan hämtas med wget på en Linuxburk: wget –header ”Key: a67b9d6b5efa0d10617827d726b424d0” http://ppdyn.smhi.se/produktportal-1.0/ws/products/weatherdata/55.42919/13.81710/forecast
• Jag är osäker på om nyckeln är knuten till en unik användare, och skulle isf kunna användas av SMHI för att förhindra alltför täta hämtningar av data. Eller så använder alla samma nyckel och dess enda funktion är att göra det svårare att plocka datan direkt från en vanlig webbläsare, eller för att kunna ändras i framtiden. Nyckeln ovan fungerade i ett par dagar, sen fick jag ”Access denied” igen. Detta tyder på att varje nyckel är variabel och tidsbunden. Troligtvis en hash som innefattar datum (med ett par dagars precision), IMEI (eller annat ID) och ev. mer.
  
• Formatet på JSON-filen är ganska enkel, den innehåller vindriktning, medelhastighet och vindbyar samt lufttryck, lufttemp. och en del annan mätdata.