Reading time 5 min

Stijn Huygh

As developers, we understand that GPS accuracy is the backbone of many mobile applications, from navigation to location-based services. The accuracy of your app's GPS functionality can make or break the user experience. In this article we’ll give you five practical ways to improve the GPS accuracy of your mobile application and ensure that your users never feel lost again. How poor GPS location accuracy kills mobile application success: real-life example Let’s start with a real-life example of how poor GPS accuracy can cause your mobile application to fail big time. Example Elise downloaded your new mobile application, Commuter . The app promises to enhance her commuting experience by delivering timely notifications about her bus stops and estimated arrival times. However, to her dismay, the performance of your app has been inconsistent. While on some days it offers accurate real-time updates, on others, she receives the notifications too late or too early. Understandably, Elise is frustrated and shares her dissatisfaction with your mobile application through a negative review. What goes wrong with the GPS accuracy? You, as the developer, are left perplexed. After all, you've integrated the platform's standard GPS algorithms, so why the inconsistency? The app calculates her average velocity based on the difference between GPS locations and the time between these updates. It's programmed to notify her of her bus stop once her GPS coordinates fall within a 100-meter radius of the station. While this sounds logical, the real-world results don’t align with expectations. What causes poor GPS location accuracy? The core issue stems from the inherent inaccuracies in GPS location data. While GPS locations include a margin of error, typically expressed in meters with a 68% confidence interval, this margin doesn't consider the influence of GPS signal reflections , also known as multipath errors. Multipath errors occur when GPS signals bounce off objects or surfaces before reaching the GPS receiver's antenna. Urban areas with tall buildings and dense infrastructure are particularly prone to GPS signal reflections. The reflection of signals off skyscrapers, vehicles, and other structures can create a complex signal environment, leading to unpredictable location inaccuracies. GPS signal reflections can divert the signal by kilometers, potentially causing the app to incorrectly indicate that Elise has either already reached her destination or is still kilometers away. Challenges of GPS signal reflections for mobile app developers GPS signal reflections pose several challenges to mobile app developers: Inaccurate positioning : GPS signal reflections can cause the GPS receiver to calculate an incorrect position. When the reflected signal arrives slightly later than the direct signal, the receiver may interpret it as coming from a different angle, leading to inaccurate position estimates. Inconsistent readings : GPS signal reflections are often inconsistent, making it difficult for developers to predict when and where they will occur. This inconsistency can result in varying levels of inaccuracy, posing a challenge when designing location-dependent services. How to improve GPS location accuracy? To counter the challenges of GPS signal reflections and enhance the user experience, a renewed strategy is necessary. Here are some innovative strategies to improve the GPS location accuracy of the Commuter mobile app in the example above: Filtering GPS locations : It's crucial to discard any location updates with inaccuracies exceeding 100 meters. This ensures that only the most reliable data is used for computations. Leveraging additional sensor data : Incorporate accelerometer data to enhance GPS accuracy. Use a velocity Verlet algorithm to predict locations based on the accelerometer data. Combine these predictions using a Kalman Filter, factoring in the uncertainty of each data source, stabilizing the location signal, and providing a more accurate prediction. Projection algorithms for bus routes: Since Elise commutes by bus, projection algorithms can be employed to align her location with the bus’s route. This can be achieved by approximating the route using data from different bus stops. Crowdsourced Wi-Fi SSIDs: Another innovative approach involves crowdsourcing Wi-Fi SSIDs (Service Set Identifiers). These SSIDs can act as location markers, providing additional data points to refine location accuracy. Bluetooth beacons for enhanced accuracy : Detecting crowdsourced Bluetooth beacons, can also serve as location updates. By tapping into these BLE beacons, you can further enhance the app's accuracy. By implementing these strategies, the Commuter app significantly enhances its accuracy, ensuring a consistent and reliable user experience. As a result, Elise and many users like her can enjoy timely and accurate updates, leading to positive reviews and overall customer satisfaction. 📱 Conclusion While the challenges faced by the Commuter app might seem unique, they reflect real-world hurdles many mobile app developers encounter. At ACA, we've successfully navigated these challenges using the strategies outlined above. While GPS is a valuable tool, understanding its limitations and augmenting its data with other technologies is key to ensuring reliable location-based services. Looking for an experienced mobile application development partner? {% module_block module "widget_137b2ccd-e194-4a50-a7ff-05def1e6085b" %}{% module_attribute "buttons" is_json="true" %}{% raw %}[{"appearance":{"link_color":"light","primary_color":"primary","secondary_color":"primary","tertiary_color":"light","tertiary_icon_accent_color":"dark","tertiary_text_color":"dark","variant":"primary"},"content":{"arrow":"right","icon":{"alt":null,"height":null,"loading":"disabled","size_type":null,"src":"","width":null},"tertiary_icon":{"alt":null,"height":null,"loading":"disabled","size_type":null,"src":"","width":null},"text":"Contact us"},"target":{"link":{"no_follow":false,"open_in_new_tab":false,"rel":"","sponsored":false,"url":{"content_id":230950468795,"href":"https://25145356.hs-sites-eu1.com/en/contact","href_with_scheme":null,"type":"CONTENT"},"user_generated_content":false}},"type":"normal"}]{% endraw %}{% end_module_attribute %}{% module_attribute "child_css" is_json="true" %}{% raw %}{}{% endraw %}{% end_module_attribute %}{% module_attribute "css" is_json="true" %}{% raw %}{}{% endraw %}{% end_module_attribute %}{% module_attribute "definition_id" is_json="true" %}{% raw %}null{% endraw %}{% end_module_attribute %}{% module_attribute "field_types" is_json="true" %}{% raw %}{"buttons":"group","styles":"group"}{% endraw %}{% end_module_attribute %}{% module_attribute "isJsModule" is_json="true" %}{% raw %}true{% endraw %}{% end_module_attribute %}{% module_attribute "label" is_json="true" %}{% raw %}null{% endraw %}{% end_module_attribute %}{% module_attribute "module_id" is_json="true" %}{% raw %}201493994716{% endraw %}{% end_module_attribute %}{% module_attribute "path" is_json="true" %}{% raw %}"@projects/aca-group-project/aca-group-app/components/modules/ButtonGroup"{% endraw %}{% end_module_attribute %}{% module_attribute "schema_version" is_json="true" %}{% raw %}2{% endraw %}{% end_module_attribute %}{% module_attribute "smart_objects" is_json="true" %}{% raw %}null{% endraw %}{% end_module_attribute %}{% module_attribute "smart_type" is_json="true" %}{% raw %}"NOT_SMART"{% endraw %}{% end_module_attribute %}{% module_attribute "tag" is_json="true" %}{% raw %}"module"{% endraw %}{% end_module_attribute %}{% module_attribute "type" is_json="true" %}{% raw %}"module"{% endraw %}{% end_module_attribute %}{% module_attribute "wrap_field_tag" is_json="true" %}{% raw %}"div"{% endraw %}{% end_module_attribute %}{% end_module_block %}

Reading time 4 min

Stijn Huygh

With Flutter it is possible to create applications that run smoothly on multiple platforms using a single code base. This means that in theory all mobile applications built with flutter could also function as web or desktop applications . This sounds too good to be true. So, we decided to put it to the test ourselves using our own application that is already in production, the Immovlan app . This real estate application allows users to list their properties for sale or rent. Overcoming challenges with Flutter Our journey began by integrating the necessary web folder into our mobile app. This step went smoothly, and we proceeded to test the app on the web to identify areas needing adjustment for web-specific requirements. First up was our integration with Firebase Crashlytics , which currently does not support web platforms. To address this, we added conditional checks to prevent initializing Crashlytics and sending events when building for the web—an easy fix to ensure smooth operation. Another solution could be to look for a good alternative for Firebase Crashlytics that does support web platforms. Next, we faced challenges with our user tracking setup for advertising. We use Didomi as our consent manager, but unfortunately, it's not compatible with Flutter Web . * Following a similar approach to Firebase Crashlytics, we implemented checks to disable it when running on the web. With these changes, we could run the application on the web. However, there were still a few things that we needed to adapt. * Remark : The existing Flutter SDK doesn't offer web support at the moment. However, Didomi offers a separate web SDK ( https://developers.didomi.io/cmp/web-sdk ). The integration of this web SDK wasn't part of our initial testing plan. The final obstacles to getting the Flutter mobile app running on the web We faced Cross-Origin Resource Sharing (CORS) issues because the API was initially designed for mobile use. Since CORS is managed differently on the web, we switched from the HTML renderer to CanvasKit. The CORS issues can be easily tackled by including the correct headers in the responses, yet for this project, the backend was not in our hands. Once we addressed the API challenges, we encountered another obstacle with our app's location-based map searches. Our existing map package, which relied on default device maps (Apple Maps for iOS and Google Maps for Android), was not supported. We fixed this small issue easily by adding it ourselves. Following these adjustments, our mobile app was successfully operational on the web. From mobile app to web platform: lessons learned and future considerations We successfully launched a new web platform within a short timeframe by making a few adjustments to the code base of a mobile app. This process would typically require much more time if implemented separately. Being able to create a web app by reusing the same business logic used in the mobile app can significantly reduce implementation costs. Moreover, it enables a uniform customer journey on all platforms. Also bug fixing can be done on all platforms at once, saving time and effort. However, this approach also presents some new challenges: While the app's functionality remained consistent across both mobile and web platforms, the user interface (UI) lacked optimization for the web, leading to a slightly disjointed user experience. It's imperative to prioritize further UI optimizations for the web to ensure seamless user interactions on each platform. By implementing platform-aware components, we can easily accommodate the differences between mobile and web interfaces without affecting the underlying business logic. These components would intelligently adapt based on the platform they're running on, thereby minimizing technical debt while ensuring a polished user experience across all devices. Adapting behind-the-scenes features like Firebase Crashlytics or Didomi to be compatible with the web is necessary. These challenges can be easily addressed by looking for alternatives and providing bindings for the native libraries. SEO (Search Engine Optimization) is not yet supported by Flutter. While Flutter emphasizes dynamic application experiences, including on the web, its focus on performance and consistency may not fully align with the needs of search engine indexing. This could present limitations in terms of web visibility and discoverability. However, it is possible to combine web technology and Flutter. Your landing page, which requires SEO, can be based on web technology, while the rest, which does not require SEO, can be Flutter-based. Should you consider Flutter for the web? The answer depends on the specific purpose of your web application. If you are developing a landing page, marketing website, or content site that requires optimization for search engine indexing, we recommend exploring alternative approaches rather than using Flutter Web. However, if your goal is to create a web application that is designed for authenticated user interactions, such as a banking app or energy consumption dashboard, and does not need to be indexed by search engines, Flutter can be an excellent choice. Flutter enables you to deliver a seamless user experience across different platforms, making it highly recommended for these types of applications.

Reading time 8 min

Stijn Huygh

In Part 1. The Scientific Method, we explored the scientific method's application to solving business challenges. In Part 2, we dive into a real-world problem and demonstrate how the scientific method is employed at ACA to revolutionize train arrival detection for a client. In Part 1. The Scientific Method , we explored the scientific method's application to solving business challenges. In Part 2, we dive into a real-world problem and demonstrate how the scientific method is employed at ACA to revolutionize train arrival detection for a client. The Challenge: Detecting Train Arrival with Precision The journey began with a client's question: "Can we accurately detect train arrivals and departures at a platform within a few seconds?" To address this, we applied the scientific method's iterative approach, encompassing five key steps: Identify and analyze the problem Form a hypothesis Conduct experiments to test the hypothesis Analyze data Conclude on the results Solving a question like the above usually takes a few iterations to come to a fully satisfying result. Iteration 1: Where do we even start? Step 1: Identify and Analyze the Problem The research question is the following: "Is it possible to detect the arrival and departure of a train at a platform with the time resolution of a few seconds using a smartphone?" In the first step it is important to analyze the problem: understanding the properties of arrival and departure. Taking into account the project limitations, these properties can be measured using the GPS functionality in a smartphone. Furthermore, the velocity is accurately available in the received data as it is measured using the Doppler shift of the carrier frequencies. In this case, we could rely on established knowledge and assumptions, providing a solid starting point for problem-solving. If no known truths exist, you should conduct preliminary investigations, in this case we had earlier work to rely on. Step 2: Form a Hypothesis Our hypothesis: “When we collect the position and velocity with aGPS, we will be able to reliably determine the arrival and departure at a platform based on the position and velocity characteristics, and with a good time resolution.” The hypothesis is measurable, which is important to setup an experiment where labeled data points can be compared to the predicted data. Step 3: Conduct Experiments to test the hypothesis In step 3, we set up a proof of concept focusing on essential data and the proposed solution to avoid unnecessary details before proving the hypothesis. We developed an app storing aGPS info and velocity labeled for driving or standing still. Knowing aGPS limitations, we applied filters using accelerometer data, train constraints, and predicted routes, significantly improving location accuracy. This resulted in a significant improvement of the location data. Step 4: Analyze Data The results of the experiments: Successful detection of arrival and departure at a platform Excellent system stability Unreliable velocity due to inconsistent availability based on location data origin Insufficient time resolution, resulting in unpredictable location output. Step 5: Conclude on the Results Despite good initial results, the proposed solution didn't meet the essential time resolution requirement. Constructing a system with a consistent output rate becomes unfeasible while driving within a massive Faraday cage capable of blocking signals. Iteration 2: Back to the drawing board Step 1: Identify and Analyze the Problem The first iteration didn't meet expectations, but that didn't discourage us. We realized the oversight in time resolution. Furthermore, during that time at ACA we successfully applied new techniques on a similar problem. The accelerometer provided reliable data, and by combining it with the gyroscope and magnetometer, we obtained directional acceleration. Anticipating distinct acceleration patterns for different transportation modes and states, such as standstill and driving, we decided to leverage a Naïve Bayes algorithm. This supervised learning algorithm creates a probabilistic classifier, predicting standstill and driving based on measured properties. Step 2: Form a Hypothesis A new hypothesis emerged: " Naïve Bayes classifier can be used to differentiate between walking acceleration pattern and its super position with a train in motion acceleration pattern. " Step 3: Conduct Experiments to test the hypothesis An application was created to collect data that was labeled with the correct state. Then, we trained the Naïve Base classifier using various data features, such as maximum, minimum, mean, norm, standard deviation, distance to the platform, and minimum required velocity. Step 4: Analyze Data Multiple classifiers were trained, tested, and assessed using confusion matrices. The results showed driving was correctly identified 94% of the time, but standstill was only identified accurately 48% of the time, with the classifier mistakenly labeling standstill as driving in 52% of cases. Step 5: Conclude on the Results The Naïve Bayes classifiers lacked the needed accuracy for our problem. The features had significant overlap, preventing differentiation between standstill and driving. Additionally, the classifiers couldn't capture the transient nature of arrival and departure accurately, prompting further exploration for a solution. Iteration 3: It is all about the change Step 1: Identify and Analyze the Problem The previous experiments revealed that velocity and position lacked sufficient time resolution, and probabilistic models struggled with the transient nature of arrival and departure. Recognizing the importance of the transient aspect, it's evident that properties like velocity or position aren't crucial; instead, acceleration is key. Arrival can be defined as a deceleration followed by a period of no acceleration, while departure is acceleration preceded by a period of no acceleration. Step 2: Form a Hypothesis A new hypothesis was formulated: “It is possible to use the transient nature of arrival and departure at a platform to detect the arrival and departure with a good time resolution and good accuracy.” Step 3: Conduct Experiments to test the hypothesis To focus on using accelerometer data for arrival and departure detection, we utilized data from the previous iteration, entering a new research domain aiming to build a signal analysis algorithm for classification. In the following steps, multiple graphs are added. The red background indicates that the train was at the platform, green indicates that it was in motion. Look at the data: Take a look at the graph of the Y-channel of the accelerometer. We chose not to project the acceleration onto the real-world axis initially to keep it in its raw form, minimizing the required computing power. There wasn’t much to tell our program with this data, it looks mostly random. Perform data manipulations to improve clarity: Velocity remains constant during driving and standstill, but arrival and departure are characterized by changes in acceleration. Arrival involves deceleration followed by no acceleration, while departure involves acceleration after a period of no acceleration. Accumulating acceleration over time reveals trends similar to velocity but with notable changes during arrival and departure, providing insights for program interpretation, though further signal processing is necessary. Calculate the Gradient: To avoid the original data being retrieved by taking the gradient from the cumulative curve, additional data manipulation is performed. The cumulative curve undergoes smoothening through a one-second moving average. On a macroscopic level, the curve retains its appearance, but noise in the data is reduced. The resulting graph, incorporating all three channels for completeness, is obtained by taking the gradient. Clean Up the Data: The current data remains noisy and challenging for program interpretation. In standstill regions (red area), minimal acceleration is observed, while the driving area exhibits significant fluctuations. This challenges the notion of constant velocity during motion, attributed to train vibrations and acceleration/deceleration. Contrary to constant velocity beliefs, this disparity between states enhances the likelihood of finding a viable solution, addressing both states rather than just the transition between standstill and driving. To enhance data quality, a high-pass filter is applied, removing drift (green and blue curve not centered around 0) and electronic noise (constant frequency in the green curve). The results are as follows: Ignore Sign of Acceleration: To disregard the acceleration's directionality, we eliminate signs and channels are combined by taking the absolute value and summing the three channels. To mitigate remaining data noise, a cut-off is applied, ignoring insignificant acceleration. Using this processed data, a straightforward algorithm is devised for determining arrival and departure. As previously mentioned, arrival is characterized by deceleration followed by no acceleration, while departure is acceleration after a period of none. This distinction is evident in the graph, where +1 indicates departure, and -1 indicates arrival at the platform. Step 4: Analyze Data Data analysis occurred primarily during the experiment. Subsequently, our algorithm was tested with unused data, revealing some false positives but no false negatives. This facilitates data optimization. While data cannot be generated from nothing, combining measurements with aGPS data helps filter out false positives. Step 5: Conclude on the Results The algorithm that was developed in this iteration of the scientific method, proved our last hypothesis. “It is possible to use the transient nature of arrival and departure at a platform to detect the arrival and departure with a good time resolution and good accuracy.” Conclusion: A Journey to Precision In this blog post, we detailed the complete process to solving a complex problem with precision. Through iterations, learning from failures, and discarding assumed knowledge, we crafted a reliable solution. The algorithm, combining known mathematics with aGPS data, can accurately detect train arrival and departure at a platform using only a smartphone, achieving a time resolution of less than 1 second. Do you want to know more about our proven IT problem-solving method? Or looking for an experienced app development partner? {% module_block module "widget_b675478f-9e23-4945-b86f-8a02d99d5dfa" %}{% module_attribute "buttons" is_json="true" %}{% raw %}[{"appearance":{"link_color":"light","primary_color":"primary","secondary_color":"primary","tertiary_color":"light","tertiary_icon_accent_color":"dark","tertiary_text_color":"dark","variant":"primary"},"content":{"arrow":"right","icon":{"alt":null,"height":null,"loading":"disabled","size_type":null,"src":"","width":null},"tertiary_icon":{"alt":null,"height":null,"loading":"disabled","size_type":null,"src":"","width":null},"text":"Contact our experts!"},"target":{"link":{"no_follow":false,"open_in_new_tab":false,"rel":"","sponsored":false,"url":{"content_id":230950468795,"href":"https://25145356.hs-sites-eu1.com/en/contact","href_with_scheme":null,"type":"CONTENT"},"user_generated_content":false}},"type":"normal"}]{% endraw %}{% end_module_attribute %}{% module_attribute "child_css" is_json="true" %}{% raw %}{}{% endraw %}{% end_module_attribute %}{% module_attribute "css" is_json="true" %}{% raw %}{}{% endraw %}{% end_module_attribute %}{% module_attribute "definition_id" is_json="true" %}{% raw %}null{% endraw %}{% end_module_attribute %}{% module_attribute "field_types" is_json="true" %}{% raw %}{"buttons":"group","styles":"group"}{% endraw %}{% end_module_attribute %}{% module_attribute "isJsModule" is_json="true" %}{% raw %}true{% endraw %}{% end_module_attribute %}{% module_attribute "label" is_json="true" %}{% raw %}null{% endraw %}{% end_module_attribute %}{% module_attribute "module_id" is_json="true" %}{% raw %}201493994716{% endraw %}{% end_module_attribute %}{% module_attribute "path" is_json="true" %}{% raw %}"@projects/aca-group-project/aca-group-app/components/modules/ButtonGroup"{% endraw %}{% end_module_attribute %}{% module_attribute "schema_version" is_json="true" %}{% raw %}2{% endraw %}{% end_module_attribute %}{% module_attribute "smart_objects" is_json="true" %}{% raw %}null{% endraw %}{% end_module_attribute %}{% module_attribute "smart_type" is_json="true" %}{% raw %}"NOT_SMART"{% endraw %}{% end_module_attribute %}{% module_attribute "tag" is_json="true" %}{% raw %}"module"{% endraw %}{% end_module_attribute %}{% module_attribute "type" is_json="true" %}{% raw %}"module"{% endraw %}{% end_module_attribute %}{% module_attribute "wrap_field_tag" is_json="true" %}{% raw %}"div"{% endraw %}{% end_module_attribute %}{% end_module_block %}