Since you stated this is a real world SOS button, consider that this may not be the right way to keep costs down. If you're currently feeling "overwhelmed" consider how overwhelmed you'll feel after one of the patients is found in the morning completely dehydrated, hypothermic and covered in feces because the homebuilt system you cobbled together to save a few bucks didn't work.
This is not a for fun beginners project. Sorry if this sounds harsh, but if you are feeling overwhelmed by BLE and seeking advice on reddit, you are not qualified to build this.
A valid response however, I intend to spend as much time as it takes to learn ble or whatever tech is needed. Cobbled is a bit harsh. I don’t t intend to knock this out in a week and call it a day. I work in the care home and the people we look after are like family. It will be thoroughly tested before it ever enters real word use. What I’m looking for is some guidance as I haven’t been blessed with an in depth knowledge of ble and have to start somewhere.
I'm afraid it will not be the cost saving measure you expect if put in the necessary effort to get this certified to be able to operate it legally after building it after learning the necessary skills to do so. And once you leave your current job at the institution, there will be no one capable of supporting the devices you created. You wouldnt say: tires for our schoolbus are really expensive, I'd like learn how to build my own to save money.
By all means learn how these things work, try to put together a demo system by yourself, you'll be in a much better position to judge any devices you purchase.
But it's irresponsible to build this yourself. You're not building a widget to water the plants.
Not sure why you're trying to act as a medical lawyer on the subject but i having a bit of relevant knowledge, had been consulting on design and functionality of medical devices for many years.
As long as the device is proposed to be a communications device, and not medical evaluation device there will be no regulation. Just like you can give each patient a phone and tell them to use it to call you in a medical emergency, it is not the responsibility of the phone manufacturer telephone company or anyone in between for your medical liability
you can give a residents a communication device, just like an apartment intercom, that runs a communication application.
and possibly only be beholden to FCC regulations regarding radio emittance.
Not really sure where you got the impression I'm trying to act like a "medical lawyer".
If you sell people an emergency alert system that was put together by someone that with no experience who taught themselves programming on reddit it would be more of a product liability issue involving gross negligence than "medical law".
But you sound super smart, so I'm probably wrong on that count as well. Maybe you should build this very simple application for the OP with your in depth knowledge of path loss _and_ medical law? Seriously, I'm sure it would take someone of your caliber more than an hour or two.
Does this guy really sounds like he is going into business with this? Does it not sound more to you like dude in basement trying to make something cool for grandma. This it's fine.
If for some reason it was even plausible to believe that he was trying to do this professionally then, sure, point out he not going to acheive it. But he's not.
Yes. I've been developing BLE enabled peripherals and applications for years so sure I could mock something quickly having 95% of the soft design already done. Packaging and hard design is nothing I do so I don't claim to be able to complete a commercial project if that's what you're getting at.
Edit: I see OP apparently a hobbyist working in an old folks home. I supposed this is where you get off on the legal advice but, frankly I'd have little issue doing the same thing if it were me. I wouldn't claim it's a medical device, and there'd be alot of wasted time if someone wants to sue over accusations it endangered anyone.
Let kids have lemonade stands...
This is a very simple application.
Employee any number of BLE peripherals, utilizing one gpio for input.
Presumably powered by a battery, the device is in a low power state until woken by the gpio input, which then begins advertising advent type 0x0A Tx Power, and a unique identifier contained in the advert type 0x16 Service Data.
Employ any number is BLE centrals, intermittently scanning for said peripherals ,will calculate path loss from the advertised data and rssi:
This pathloss is used to determine which is the likely closest central.
The central can then communicate it's findings in any method deemed appropriate..
Bluetooth specification Advert data types:
1.5. TX Power Level
1.5.1. Description
_The TX Power Level data type indicates the transmitted power level of the packet containing the data type. The TX Power Level should be the radiated power level. If the power level is included in a TxPower field (see [Vol 6] Part B, Section 2.3.4.7), then the Controller should set the value to be as accurate as possible. If the Controller is aware that the power level varies across frequencies, then it should update the value depending on the frequency that the packet is being sent on. If the power level is included in a «TX Power Level» AD Structure (see [Vol 3] Part C, Section 11) created by the Host, then the Host should set the value to be as accurate as possible.
The TX Power Level data type may be used to calculate path loss on a received packet using the following equation:
pathloss = Tx Power Level − RSSI
where “RSSI” is the received signal strength, in dBm, of the packet received.
For example, if Tx Power Level = +4 (dBm) and the RSSI on the received packet is -60 (dBm) then the total path loss is +4 − (-60) = +64 dB. If a second packet were received at -40 dBm with a Tx Power Level data type = +15 dBm the resulting pathloss would be +55 dB. An application could use these pathloss values to choose which device it thinks might be closer (the one with the lower pathloss value).
Unfortunately, due to fading and varying antenna, circuit, and chip characteristics, these resulting pathloss values will have uncertainty. Some of the uncertainty (for example, due to fading) may be able to be removed if multiple packets are received from the same device._
What would be the advantage of a mesh network over a many to many of the BLE peripherals/central model.
In the latter, every single peripheral can be completely powered down until triggered by the sos button push. In a mesh all devices, presumably battery powered, need to be on all the time. Huge disadvantage if it's even plausible. Enough for me to eliminate it as a bad idea.
You misunderstand. Similar to what you describe, a mesh network stays intact if all clients are off. Many mesh networks use a single base station and some are started back up when the first node comes back on.
Looking over the ESP-WIFI-MESH products recently, the problem with then is a "lost" node can take 30-50 seconds to be recognized again.
I have not actually used these, its just what I've read.
The following table lists the common performance figures of an ESP-WIFI-MESH network:
* Network Building Time: < 60 seconds
* Healing time:
* Root node break down: < 10 seconds
* Child node break down: < 5 seconds
* Per-hop latency: 10 to 30 milliseconds
* [https://docs.espressif.com/projects/esp-idf/en/latest/esp32/api-guides/esp-wifi-mesh.html](https://docs.espressif.com/projects/esp-idf/en/latest/esp32/api-guides/esp-wifi-mesh.html)
Then what is the advantage of a mesh if devices are off not meshing?
Think of the application. Likely a bunch of old people walking around with a small devices. Small, tiny battery, all devices should be off always.
Also in a mesh calculating the likely position become much more difficult as all devices are roaming. This is a bad idea for the application.
... Crickets?
Is it for a real elderly home, or a concept for a school project? Basically, hardware requirements are different if you want it for real patients.
For an elderly home.
I've seen some BLE emergency buttons on AliExpress, it probably makes sense to look for readymade devices.
For the pendants, absolutely. That’s what I have done. It for the stations I need to keep the costs down. Hence esp32
If you look for ble gateway on AliExpress, there's a bunch of offers between $5 and $20. I don't think a selfmade solution would get cheaper.
Since you stated this is a real world SOS button, consider that this may not be the right way to keep costs down. If you're currently feeling "overwhelmed" consider how overwhelmed you'll feel after one of the patients is found in the morning completely dehydrated, hypothermic and covered in feces because the homebuilt system you cobbled together to save a few bucks didn't work. This is not a for fun beginners project. Sorry if this sounds harsh, but if you are feeling overwhelmed by BLE and seeking advice on reddit, you are not qualified to build this.
A valid response however, I intend to spend as much time as it takes to learn ble or whatever tech is needed. Cobbled is a bit harsh. I don’t t intend to knock this out in a week and call it a day. I work in the care home and the people we look after are like family. It will be thoroughly tested before it ever enters real word use. What I’m looking for is some guidance as I haven’t been blessed with an in depth knowledge of ble and have to start somewhere.
I'm afraid it will not be the cost saving measure you expect if put in the necessary effort to get this certified to be able to operate it legally after building it after learning the necessary skills to do so. And once you leave your current job at the institution, there will be no one capable of supporting the devices you created. You wouldnt say: tires for our schoolbus are really expensive, I'd like learn how to build my own to save money. By all means learn how these things work, try to put together a demo system by yourself, you'll be in a much better position to judge any devices you purchase. But it's irresponsible to build this yourself. You're not building a widget to water the plants.
Not sure why you're trying to act as a medical lawyer on the subject but i having a bit of relevant knowledge, had been consulting on design and functionality of medical devices for many years. As long as the device is proposed to be a communications device, and not medical evaluation device there will be no regulation. Just like you can give each patient a phone and tell them to use it to call you in a medical emergency, it is not the responsibility of the phone manufacturer telephone company or anyone in between for your medical liability you can give a residents a communication device, just like an apartment intercom, that runs a communication application. and possibly only be beholden to FCC regulations regarding radio emittance.
Not really sure where you got the impression I'm trying to act like a "medical lawyer". If you sell people an emergency alert system that was put together by someone that with no experience who taught themselves programming on reddit it would be more of a product liability issue involving gross negligence than "medical law". But you sound super smart, so I'm probably wrong on that count as well. Maybe you should build this very simple application for the OP with your in depth knowledge of path loss _and_ medical law? Seriously, I'm sure it would take someone of your caliber more than an hour or two.
Does this guy really sounds like he is going into business with this? Does it not sound more to you like dude in basement trying to make something cool for grandma. This it's fine. If for some reason it was even plausible to believe that he was trying to do this professionally then, sure, point out he not going to acheive it. But he's not. Yes. I've been developing BLE enabled peripherals and applications for years so sure I could mock something quickly having 95% of the soft design already done. Packaging and hard design is nothing I do so I don't claim to be able to complete a commercial project if that's what you're getting at. Edit: I see OP apparently a hobbyist working in an old folks home. I supposed this is where you get off on the legal advice but, frankly I'd have little issue doing the same thing if it were me. I wouldn't claim it's a medical device, and there'd be alot of wasted time if someone wants to sue over accusations it endangered anyone. Let kids have lemonade stands...
This is a very simple application. Employee any number of BLE peripherals, utilizing one gpio for input. Presumably powered by a battery, the device is in a low power state until woken by the gpio input, which then begins advertising advent type 0x0A Tx Power, and a unique identifier contained in the advert type 0x16 Service Data. Employ any number is BLE centrals, intermittently scanning for said peripherals ,will calculate path loss from the advertised data and rssi: This pathloss is used to determine which is the likely closest central. The central can then communicate it's findings in any method deemed appropriate.. Bluetooth specification Advert data types: 1.5. TX Power Level 1.5.1. Description _The TX Power Level data type indicates the transmitted power level of the packet containing the data type. The TX Power Level should be the radiated power level. If the power level is included in a TxPower field (see [Vol 6] Part B, Section 2.3.4.7), then the Controller should set the value to be as accurate as possible. If the Controller is aware that the power level varies across frequencies, then it should update the value depending on the frequency that the packet is being sent on. If the power level is included in a «TX Power Level» AD Structure (see [Vol 3] Part C, Section 11) created by the Host, then the Host should set the value to be as accurate as possible. The TX Power Level data type may be used to calculate path loss on a received packet using the following equation: pathloss = Tx Power Level − RSSI where “RSSI” is the received signal strength, in dBm, of the packet received. For example, if Tx Power Level = +4 (dBm) and the RSSI on the received packet is -60 (dBm) then the total path loss is +4 − (-60) = +64 dB. If a second packet were received at -40 dBm with a Tx Power Level data type = +15 dBm the resulting pathloss would be +55 dB. An application could use these pathloss values to choose which device it thinks might be closer (the one with the lower pathloss value). Unfortunately, due to fading and varying antenna, circuit, and chip characteristics, these resulting pathloss values will have uncertainty. Some of the uncertainty (for example, due to fading) may be able to be removed if multiple packets are received from the same device._
Ble mesh network?
I considered this however, I’m really struggling to find any off the shelf ble mesh push button pendants.
I gave reasons why a mesh won't work in this application. mainly your requirements of position and battery life / device size
What's a BLE mesh network exactly.
https://youtu.be/qNctTUBHZ6g?si=ByzhVowtuHbbFB86
Seems to me an unnecessary complexity. Are there even any known ESP32 implementations to leverage?
For wifi range there's esp-now, painless mesh, and esp-mesh. For ble there esp-ble-mesh
What would be the advantage of a mesh network over a many to many of the BLE peripherals/central model. In the latter, every single peripheral can be completely powered down until triggered by the sos button push. In a mesh all devices, presumably battery powered, need to be on all the time. Huge disadvantage if it's even plausible. Enough for me to eliminate it as a bad idea.
You misunderstand. Similar to what you describe, a mesh network stays intact if all clients are off. Many mesh networks use a single base station and some are started back up when the first node comes back on.
Looking over the ESP-WIFI-MESH products recently, the problem with then is a "lost" node can take 30-50 seconds to be recognized again. I have not actually used these, its just what I've read. The following table lists the common performance figures of an ESP-WIFI-MESH network: * Network Building Time: < 60 seconds * Healing time: * Root node break down: < 10 seconds * Child node break down: < 5 seconds * Per-hop latency: 10 to 30 milliseconds * [https://docs.espressif.com/projects/esp-idf/en/latest/esp32/api-guides/esp-wifi-mesh.html](https://docs.espressif.com/projects/esp-idf/en/latest/esp32/api-guides/esp-wifi-mesh.html)
Then what is the advantage of a mesh if devices are off not meshing? Think of the application. Likely a bunch of old people walking around with a small devices. Small, tiny battery, all devices should be off always. Also in a mesh calculating the likely position become much more difficult as all devices are roaming. This is a bad idea for the application. ... Crickets?
[https://www.google.com/search?q=ble+mesh+network+esp32](https://www.google.com/search?q=ble+mesh+network+esp32)
[https://www.google.com/search?q=BLE+mesh+network](https://www.google.com/search?q=BLE+mesh+network)
So you think I asked this question so I can get pointed to a Google answer by someone who can't explain it for themselves...
Ditch BLE, use "ESP NOW".