mushfiq/rssi-system

This repository is a three-tier RSSI indoor-localization system with a clear split between acquisition/processing, server-side persistence/API, and mobile visualization.

1. End-to-end data flow

Physical receivers capture RSSI from a watch/transmitter, the Java application ingests those readings, runs localization algorithms to compute position, then posts results and metadata to the REST API. The Python/Django API stores records in MongoDB and exposes them to clients, including the Android app, which fetches and renders the latest watch position.

2. comReader: the Java localization hub

This is the central processing application. It combines device I/O, algorithm execution, data persistence, and a Swing desktop UI for monitoring/configuration. It is the main boundary where raw RSSI data becomes localization output.

3. Data acquisition layer in comReader

The data package contains readers for serial/COM input and file-based input, plus runnable wrappers and writer abstractions. This suggests the system can operate live from hardware or replay from files for testing. Reading, WatchPositionData, and Controller are the main in-memory data carriers/control points.

4. Localization algorithm layer in comReader

The algorithm package holds multiple strategies: proximity-based, probability-based, and random, with a shared PositionLocalizationAlgorithm abstraction. Supporting components include Kalman filtering, convex hull math, probability maps, and weight functions. This layer is where RSSI readings are transformed into x/y estimates.

5. Map and receiver model layer in comReader

components and dao represent the map/receiver domain and data access. There are hardcoded DAO implementations as well as Mongo-backed DAOs, indicating the application can load map/receiver definitions from either static config or the database. This is the boundary between localization logic and environment configuration.

6. Desktop UI in comReader

The gui package is a full Swing client for operators: map panels, receiver panels, parameter controls, status, dialogs, and custom views. It likely visualizes live receivers, selected maps, and algorithm state while allowing map/receiver setup and parameter tuning.

7. Outbound integration from comReader to the API

The rest package and REST-related tests indicate that comReader also acts as a client to the server. It uploads maps, receivers, and computed watch positions to the Django API, making the Java app the producer of canonical localization data.

8. RESTApi: Django/Python backend

The RESTApi/restApp project is the persistence and service layer. It uses Django/WSGI, REST-style resources/views, serializers, and middleware/auth code. This is the system’s backend boundary for storage and retrieval rather than computation.

9. MongoDB as the persistence store

The API’s models/resources and the Mongo-specific scripts/tests indicate MongoDB is the primary database. The server persists maps, receiver records, and watch positions there, and the Java app has Mongo-aware DAO/wrapper code for some shared entities.

10. Server-side test and support tooling

The API includes dummy data, setup scripts, and tests for map, receiver, image retrieval, and watch records. This suggests the backend is exercised as a data service with predefined fixtures rather than complex business logic.

11. AndroidApp: mobile visualization client

The Android app is a lightweight consumer of the API. Its code centers on WatchUserActivity, a custom MapImageView, and simple data objects/parsers for map/receiver/position records. It is primarily a read/display client for the latest localization state.

12. Android app data flow

RestMapService appears to fetch remote JSON from the REST API, ResponseParser converts responses into local records, and the UI renders the position on top of a map image. The app depends on the backend for map geometry and live position updates rather than computing localization itself.

13. Cross-cutting technologies and boundaries

The project spans Java desktop/Swing, Android, and Python/Django REST services, with MongoDB underneath and hardware/serial input at the edge. Third-party jars in comReader/main/resources and the Android support library indicate the repo is self-contained and designed around those runtime boundaries.

14. What to emphasize in an architecture diagram

The main boxes should be: hardware receivers/watch input → comReader ingestion and algorithms → REST API → MongoDB → Android client, with the comReader Swing UI and backend admin/test scripts shown as auxiliary paths around the core pipeline.