This page describes how the system actually works, with no commercial shortcuts. At each step it also states what has been proven and what has not.
Five steps separate the press on the button from the text message arriving. The first three happen inside the beacon, the last two on our servers.
The beacon sleeps permanently to save its battery. The press wakes it, but it does nothing until that press has lasted two seconds. Rubbing inside a bag therefore triggers no alert. A vibration confirms the press was registered.
The navigation satellite receiver looks for the position, and the battery level is measured. Both are written to the beacon's memory before any attempt to send: if the device switches off along the way, the alert is not lost and goes out again on the next power-up.
The message is deliberately tiny. Every byte transmitted has a real cost on a satellite subscription, and the shorter the message, the better its chances of getting through on a weak signal. If sending fails, the beacon goes back to sleep and retries automatically five minutes later, with no intervention.
The satellite operator passes the frame to our server, which decodes it and finds the owner from the only identifier the beacon knows: its modem serial number. No personal data travels inside the message.
Each saved contact receives a text message containing the coordinates and a map link, readable on any phone, even with no app installed. A failure to reach one contact never prevents the others from being notified.
Nine bytes, not one more. This format is the contract between the beacon's firmware and the server: both define it identically.
| Position | Content | Encoding |
|---|---|---|
| 0 – 3 | Latitude | Signed integer, degrees × 1,000,000 |
| 4 – 7 | Longitude | Signed integer, degrees × 1,000,000 |
| 8 | Battery | Integer from 0 to 100 |
This encoding keeps the position to within about eleven centimetres, far below what the receiver itself can achieve. Any accuracy lost therefore comes from the sensor, never from the format.
The distinction is drawn here because it is the only thing that matters when judging a project at this stage.
The figures given elsewhere on this site are design targets. Not one has been measured on a prototype, for the simple reason that none exists yet.
A short-burst data service is paid for in two ways: a monthly subscription per device, and every message sent. Ignoring that would mean missing the project's main constraint.
| Item | Order of magnitude | Nature |
|---|---|---|
| Iridium 9603 module, single unit | 220 € | Recorded price, single unit |
| Satellite line, per month activated | 15 € | Estimate, no contract signed |
| One alert message | 0.09 to 0.37 € | Estimate, depending on the plan |
| All components, per beacon | 315 € | Sum of unit prices |
The satellite module alone accounts for more than two thirds of the hardware cost. That is what sets the beacon's floor price, and it is also why the first unit has not been assembled yet.
The battery capacity has not been settled. Rather than announce a battery life, here is the calculation that will let us choose one.
| Item | Assumption | Energy cost |
|---|---|---|
| Deep sleep, two weeks | 10 µA × 336 h | ≈ 3,4 mAh |
| One position fix | ≈ 30 mA × 30 s | ≈ 0,25 mAh |
| One satellite transmission | ≈ 190 mA × 30 s | ≈ 1,6 mAh |
| One complete alert | fix, then transmission | ≈ 1,9 mAh |
What this calculation shows, and what it does not. Two weeks of standby followed by ten alerts costs about 22 mAh; fifty alerts cost 98. A battery of a few hundred milliamp-hours would therefore be ample. In other words, it is not usage that will limit battery life, but the battery's own self-discharge and the residual draw of the circuits, which only a measurement on a prototype will reveal. The consumption figures used here come from the datasheets of the chosen components; not one has been measured on Teskideh hardware.
This drawing is a design rendering. Not one unit has been built: neither the dimensions, nor the durability, nor the battery life have been measured on hardware.
What this drawing is, and what it is not. The components shown match those in the firmware already written: ESP32-S3 microcontroller, Iridium 9603 modem, GNSS receiver, LiFePO4 battery. The dimensions marked on the drawing are design targets. Resistance to dust and water is a target, not a certification: a standard of that kind is earned through laboratory testing, and no test has been carried out.
What follows describes the implementation as it runs today, not an intention.
Positions are recorded in a PostgreSQL database hosted at Supabase, with the time of the fix and the battery level. Traffic between the app, the site and the server goes over an encrypted connection.
Every table is protected by rules checked on the server, forty-seven in all across fifteen tables. An account can only read its own data. A relative invited to the family circle gets read-only access, and only while the invitation stands. An organisation sees only the beacons attached to it.
No automatic deletion is in place to date: an alert stays until its owner erases it. Each alert can be deleted from the history, and deleting the account removes all associated data in cascade. A retention period will be set before deployment.