mAPRS är mitt eget projekt – en app för Android- och iOS-system som är avsedd att fungera tillsammans med APRS. Den skapades inte för att det saknades appar med APRS-stöd på marknaden – det finns redan flera sådana program, och många av dem gör sitt jobb mycket bra. Anledningen var betydligt enklare. När jag använde APRS i vardagen störde jag mig på att ständigt behöva ändra inställningarna manuellt beroende på vad jag gjorde för tillfället. När jag kör bil vill jag vara synlig på ett annat sätt än när jag går. Ytterligare en uppsättning information bör skickas när jag är hemma. Varje gång var jag tvungen att komma ihåg detta. Och då uppstod frågan: varför kan appen inte göra det själv? Så började mAPRS växa fram. 

grafika

Varifrån kom idén till mAPRS?
Projektets grundidé var mycket konkret från början: appen ska fungera så autonomt som möjligt. Jag ville inte behöva fundera på om jag hade valt rätt ikon före varje avfärd. Jag ville inte manuellt byta profil när jag hade parkerat bilen och började gå. Jag ville inte heller behöva komma ihåg att ändra inställningarna igen när jag kom hem. mAPRS ska känna av situationen och reagera på rätt sätt.

Appen avgör om jag för tillfället: kör bil, går eller befinner mig hemma. Utifrån detta väljer den automatiskt vilka element som ska skickas till APRS – framför allt ikon, kommentar samt rätt stationssymbol/tecken. Användaren behöver alltså inte ändra konfigurationen manuellt varje gång. Det är just denna automatisering som är den viktigaste anledningen till att mAPRS skapades och samtidigt den egenskap som hela projektet bygger kring.

Samarbete med APRS-IS
mAPRS kommunicerar med nätverket APRS-IS, det vill säga den internetbaserade delen av APRS-infrastrukturen. Appen sammanställer information om stationen och vidarebefordrar den till nätverket. På så sätt kan positionen och övriga uppgifter även visas i andra tjänster och appar som använder APRS-IS. För mig är det samtidigt mycket viktigt att APRS-kompatibiliteten bevaras. Automatiseringen ska inte skapa ett eget, slutet sätt att fungera. Tvärtom ska mAPRS använda den befintliga APRS-infrastrukturen, men utföra vissa uppgifter åt användaren som vanligtvis måste göras manuellt. Det är en liten skillnad ur nätverkets perspektiv, men en mycket stor skillnad för den som använder appen varje dag.

Spåret ska förbli exakt
En viktig del av appen är att registrera och visa färdvägen. När jag utvecklar mAPRS är det viktigt för mig att optimeringen av appens funktion inte sker på bekostnad av spårets kvalitet. Om jag färdas längs en rutt vill jag senare se dess verkliga förlopp, inte några slumpmässiga punkter som kopplats samman med raka linjer. Därför behöver inte de mekanismer som ansvarar för att skicka information till APRS och de mekanismer som används för att skapa spåret fungera exakt på samma sätt. Appen kan behöva detaljerad information om rörelsen för att fungera korrekt och visa rutten, även om inte all denna information måste skickas till APRS-IS omedelbart.

Nästa utmaning: energiförbrukningen
En app som övervakar positionen under många timmar kan mycket lätt bli en av telefonens största energiförbrukare. Därför är optimering av batteriförbrukningen ytterligare ett viktigt steg i utvecklingen av mAPRS. Det handlar dock inte om den enklaste lösningen, som innebär att positionen kontrolleras mer sällan. Det skulle kunna försämra spårets kvalitet och effektiviteten i identifieringen av hur användaren förflyttar sig. Målet är att hitta ett sätt att använda positioneringstjänsterna så att appen får den information den behöver, utan att samtidigt tvinga telefonen att arbeta i onödan. Detta är särskilt viktigt under längre resor eller en hel dags aktivitet utomhus. mAPRS ska kunna köras i bakgrunden under lång tid utan att man hela tiden behöver fundera på hur mycket batteri som finns kvar i telefonen.

Appen utvecklas stegvis
mAPRS utvecklas hela tiden. Jag försöker dock att inte införa många slumpmässiga förändringar samtidigt. Varje ny version har ett konkret mål – att förbättra en viss del, ändra appens beteende eller optimera en befintlig mekanism. Därefter testas den nya versionen. Detta arbetssätt gör det betydligt enklare att kontrollera om förändringen verkligen gav det förväntade resultatet och om den samtidigt påverkade något som tidigare fungerade korrekt negativt. Det är särskilt viktigt för en app som använder positionering i bakgrunden. Vissa problem visar sig inte efter fem minuters användning. De blir synliga först under en längre bilresa, vid ett stopp, under en promenad eller efter flera timmars drift. Därför är tester under verkliga förhållanden en mycket viktig del av hela projektet.

Det handlar inte om att skapa ännu en APRS-app
mAPRS ska inte konkurrera med alla befintliga program genom antalet funktioner. Det var inte projektets mål. Jag vill framför allt lösa ett problem som jag själv stötte på när jag använde APRS. Om appen själv kan märka att jag kör, varför ska jag då manuellt ändra bilsymbolen? Om jag en stund senare börjar gå, varför ska jag återigen öppna inställningarna? Och om jag har kommit hem kan telefonen också känna av det. Det är just denna idé som är viktigast för mig: APRS ska anpassa sig efter vad användaren gör, inte användaren efter appen.

Ett projekt där jag själv lär mig mycket
mAPRS är samtidigt ett praktiskt och tekniskt projekt. När jag skapar det måste jag kombinera flera helt olika områden: hur systemet fungerar, positionering, appens arbete i bakgrunden, nätverkskommunikation, APRS-specifika förutsättningar, rörelseanalys samt optimering av energiförbrukningen. Dessutom tillkommer framtagning av nya versioner, tester och hela distributionsprocessen för appen. Varje nytt steg avslöjar nya problem som ofta inte syns i början. Och det är just det som är mest intressant med projektet. mAPRS skapades inte som en färdig produkt som planerats från den första till den sista skärmen. Den utvecklas tillsammans med nya tester och idéer som uppstår genom verklig användning av appen.

Vad händer härnäst med mAPRS?
Grundidén är oförändrad: att automatisera arbetet med APRS så mycket som möjligt, samtidigt som man behåller kontrollen över vad appen gör. De kommande utvecklingsstegen handlar framför allt om att förbättra identifieringen av situationer, korrekt växling mellan profiler, positioneringens funktion, hur positionen rapporteras samt att minska energiförbrukningen. Jag vill också att användaren tydligt ska kunna se vad appen gör för tillfället och vilka uppgifter den skickar till APRS-IS. Däremot vill jag inte lägga till funktioner enbart för att göra listan längre. Jag föredrar att några få viktiga mekanismer fungerar riktigt bra.

mAPRS – mindre växling, mer APRS
Projektet började med en mycket enkel irritation: att ständigt manuellt växla APRS-inställningar. Därifrån växte idén fram om en app som övervakar situationen och själv kan avgöra hur min station ska presenteras för tillfället. Jag kör. Jag går. Jag är hemma. mAPRS ska känna av detta och välja ikon, kommentar och APRS-symbol på rätt sätt. Utan att behöva komma ihåg några reglage. Utan att behöva öppna inställningarna varje gång. Det är just detta som är mAPRS huvudidé – och det var där hela resten av projektet började.

Integritetspolicyn för mAPRS finns här.