I would suggest that you evaluate a BLE beacon and a phone app as the receiver. Look into RSSI, which you would need to specifically evaluate programmatically.
I am not saying that this approach will absolutely work for you, but I think it is worth investigating because the hardware and software are out there and relatively cheap. Battery life would not be a problem.
Some searching, including; RSSI, ble beacon, programmable advertising interval and so on will give you a good idea of usability.
Let us know how this project progresses - ok?
Thanks for the suggestion. My use case would involve both sides being aware of the maximum distance violation, though. So both boxes need to transmit and also receive. But a BLE beacon could still be used.
The 10m distance doesn't need to be exact. It is a sensible value that allows a good degree of personal freedom for my son and at the same time peace of mind for me because I should still be able to see him and hear the alert from his box.
The solution can not be too simple, as both boxes need to sound the alert as soon as one of them loses contact. So, when one of them doesn't receive the transmission from its partner any more, it would change it's own signal from "I can hear you" to "I cannot hear you". This should counter asymmetric transmit/receive scenarios.
I will keep this thread alive, though when I start the actual development I will likely create a new thread.
Hmmm food for thought and a juicy problem. I don't manufacture or sell ble beacons. I have used them but have never tried to use RSSI for distance - it seems like it can be useful in non signal loss cases. But as an exercise, I wonder how you might go about evaluating suitability for the problem.
Let's say the device consists of a BLE beacon transmitter and an ESP32 receiver. Additionally, the ESP32 can run the alarm functions. So, in theory, you have one segment addressed, i.e., each device has to have a transmitter and a receiver.
The beacon sends a brief transmission (let's say a millisecond or so) at some interval. That interval can be programmed - let's say you use a 100 ms interval.
The esp32 is mostly scanning and scanning for all ble activity and then parses what it found and looks for the other guys beacon transmission. That part is easy because of the information in the advertisement, which easily includes a unique identifier and normally some other stuff (like rssi). The good thing for this problem is that there is no real standard in that there are usually some fields that you can manipulate - so, for example, this is how beacons can transmit temperature - the just stick the value in the field.
But, you want:
both boxes need to sound the alert as soon as one of them loses contact.
Well on your end, when you can't receive a beacon after a couple of scans (let's say 15 seconds), you can sound an alarm that you can hear. You can also change your advertising packet to reflect that you can't 'see' your son. If your son's unit has NOT lost reception of your unit, he can have a different alarm (one lost signal) and vice versa. Ok, so far so good.
What happens when both signals are lost? Both unit start alarming - so far, so good.
Beacons can have a range that exceeds your 10 m - so far so good. This allows your device to have a comfort zone and an alerting zone and a caution zone. You can take multiple readings before determining that an alarm has occurred.
Batteries - always an issue. Not so much for the beacon but the ESP32 is a bit of a hog but probably not insurmountable because you say:
Battery autonomy should be a couple of hours from a full charge.
Belt wearable is no problem with the battery probably being the largest part.
But what about how good rssi will be for distance? That is a big one. As I recall, in the heyday of advertising beacons, zones were setup to determine which advertisement (in this case an actual market advertisement) would be received/displayed - in the case of inside one large building, they probably could determine which junk stand you were closest to, but you are doing something different.
You could evaluate one beacon and one esp32 receiver and a battery for about $25 I would guess. That's important because it would first have to work well in no-loss situations, like an open area. Then advance to more complicated areas with walls and beams and so on.
You do have the benefit of recent work, not just in beacons but in patient tracking (for hospital and dementia centers) and even pandemic-inspired social distance detection (although you want the inverse, it is still relevant).
Don't know. It's a good problem.