mAPRS is my original application project for Android and iOS, designed to work with APRS. It was not created because the market lacked APRS applications—there are already several such programs, and many of them do their job very well. The reason was much simpler. When using APRS every day, I was frustrated by having to constantly change the settings manually depending on what I was doing at the time. When I drive, I want to be represented differently than when I am walking. Yet another set of information should be transmitted when I am at home. I had to remember this every time. And that is when a question arose: why can't the application do it itself? That is how mAPRS began to take shape.
Where did the idea for mAPRS come from?
From the very beginning, the project's main premise was very specific: the application should operate as autonomously as possible. I did not want to wonder before every trip whether I had selected the right icon. I did not want to change the profile manually after parking the car and starting a walk. Nor did I want to remember to switch the settings again after returning home. mAPRS is meant to recognize the situation and respond accordingly.
The application determines whether I am currently: driving, walking, or at home. Based on this, it automatically selects the appropriate elements to transmit via APRS—above all, the icon, comment, and appropriate station symbol/character. This means the user does not have to change the configuration manually every time. This automation is the most important reason mAPRS was created and, at the same time, the feature around which I am building the entire project.
Integration with APRS-IS
mAPRS communicates with the APRS-IS, the Internet-based part of the APRS infrastructure. The application prepares station-related information and passes it to the network. As a result, the position and other data can also be visible in other services and applications that use APRS-IS. At the same time, preserving APRS compatibility is very important to me. Automation is not intended to create its own closed method of operation. On the contrary—mAPRS is meant to use the existing APRS infrastructure while performing some of the tasks that users typically have to do manually. This makes little difference from the network's perspective, but a very significant one for someone who uses the application every day.
The track should remain accurate
One important feature of the application is recording and displaying the route. As I develop mAPRS, I want to ensure that optimizing the application's operation does not come at the expense of track quality. If I travel along a route, I want to see its actual course afterward, not a few random points connected by straight lines. For this reason, the mechanisms responsible for transmitting information to APRS and those involved in creating the track do not have to operate in exactly the same way. The application may need detailed movement information to function correctly and display the route, even though not all of that information needs to be sent to APRS-IS immediately.
Another challenge: power consumption
An application that monitors location for many hours can easily become one of the biggest consumers of power on a phone. That is why optimizing battery usage is another important stage in mAPRS development. However, this is not about the simplest solution of checking the position less frequently. That could reduce track quality and the effectiveness of detecting the mode of travel. The goal is to find a way to use location services that provides the application with the information it needs without making the phone do unnecessary work. This is particularly important during a longer journey or a full day of outdoor activity. mAPRS should be able to run in the background for a long time without requiring constant concern about how much battery remains on the phone.
An application developed in stages
mAPRS is continuously being developed. However, I try not to introduce many unrelated changes at once. Each new version has a specific purpose—to improve a particular element, change the application's behavior, or optimize an existing mechanism. The new version is then tested. This approach makes it much easier to determine whether a given change actually produced the expected result and whether it negatively affected something that had previously worked correctly. This is especially important for an application that uses location in the background. Some problems do not appear after five minutes of use. They only become apparent during a longer drive, a stop, a walk, or after several hours of operation. That is why testing in real-world conditions is a very important part of the entire project.
The goal is not to create yet another APRS application
mAPRS is not intended to compete with every existing program in terms of the number of features. That was not the project's purpose. Above all, I want to solve a problem I encountered myself while using APRS. If the application can recognize that I am driving, why should I change the car symbol manually? If I start walking a moment later, why should I go into the settings again? And if I have returned home, the phone can recognize that too. This idea is the most important to me: APRS should adapt to what the user is doing, not the user to the application.
A project through which I am learning a great deal myself
mAPRS is both a practical and a technical project. To create it, I have to combine several completely different areas: system operation, location services, background application operation, network communication, the specifics of APRS, movement analysis, and power-consumption optimization. On top of that, there are new releases, testing, and the entire application distribution process. Each successive stage reveals new problems that often cannot be seen at the beginning. That is precisely what makes this project most interesting. mAPRS was not created as a finished product planned from the first screen to the last. It is evolving along with successive tests and ideas arising from real-world use of the application.
What is next for mAPRS?
The basic idea remains unchanged: to automate work with APRS as much as possible while retaining control over what the application does. The next stages of development focus primarily on improving situation recognition, switching profiles correctly, location handling, position reporting, and reducing power consumption. I also want the user to have clear information about what the application is currently doing and what data it is sending to APRS-IS. I am not interested in adding features merely to make the list longer. I would rather have a few key mechanisms work really well.
mAPRS—less switching, more APRS
The project began with a very simple annoyance: constantly switching APRS settings manually. This led to the idea of an application that observes the situation and can decide on its own how my station should be presented at any given moment. I am driving. I am walking. I am at home. mAPRS is meant to recognize this and select the appropriate icon, comment, and APRS symbol. No need to remember switches. No need to open the settings every time. This is the core idea behind mAPRS—and the starting point for everything else in the project.
The privacy policy for the mAPRS application is available here.