Yesterday, I went to a larger local park, primarily because there might be more Pokemon there but also because it would give the opportunity to perform another micro:bit Bluetooth range test.
Once again though I ran out of park.
This time I got to...... <drum roll>........
354 metres and my phone was still receiving data!
Phenomenal.
I stopped when I would have had to turn a corner and go out of line of sight from the micro:bit, held once again by my Trusty Assistant. To be clear.... Bluetooth does not require line of sight. Radio signals pass through objects including walls. But for optimum conditions, line of sight is best and optimum conditions is what you want when investigating maximum range.
I had started to notice that I wasn't getting all data that was being transmitted. Bluetooth accelerometer data was being transmitted by the micro:bit regularly but I could tell from my phone, not all were arriving. So 354 metres is probably close to the maximum range. That said, I walked slightly down hill and then up hill so line of sight to the micro:bit was almost at floor level and there were quite a few people using the path in between me and the micro:bit as well. So I think a bit more range can be squeezed out of the micro:bit in ideal conditions. I'll certainly test again to see if I can find that so far illusive limit.
and just for good measure, here's what I could see of Trusty Assistant at the end of the path 354 metres from me.
 |
| Yes, 354 metres is a long way! |
More importantly, I caught a couple of Haunters and a few Ghastlys!
The hunt for Pokemon and micro:bit Bluetooth maximum range continues ......
Great info. Considering using radio vs. bluetooth.
ReplyDelete"Radio" uses a broadcast, connectionless model i.e. all micro:bits in range can receive the data. This is good in that you can do direct, micro:bit to micro:bit communication. It's also very simple to use and a great introduction to wireless communications for youngsters.
ReplyDeleteBut it's not Bluetooth, a technology which was in over 3 billion products which shipped last year. It's a proprietary protocol you're unlikely to find elsewhere and so not a particularly useful thing to learn about in terms of its future usefulness of value on a CV / resume.
It also has no security whatsoever.
It's not supported by smartphones or tablets.
So, for smartphone related projects, for using a ubiquitous technology which has good security available, for topologies that a connection-oriented rather than broadcast based, Bluetooth is the way to go.
Great stuff. Have you tried to correlate distance to RSSI? I ask because using nRF on the phone, once connected it is then possible to request RSSI, I'm wondering if from the uBit, when we know we're connected, can the RSSI be requested by pinging the phone and checking the strength of the last packet? I've had a hunt around and the only "get RSSI" type function I can find doesn't work when BLE is enabled so confused as to how this might be possible. And if it is, then does RSSI actually correlate in any meaningful way with distance between phone & uBit.
ReplyDeleteMany thanks
Paul
I can't think of a reason why you shouldn't be able to measure the RSSI at the micro:bit i.e. no need to "ping the phone" since a connection is bidirectional and so there's a received signal whose strength can be measured at both ends. The rssi API function you mention belongs to micro:bit's "radio" feature which is not Bluetooth but a simple, proprietary radio, good for basic micro:bit to micro:bit communication but non-standard and so no good for much beyond that. You'll have to look under the hood at the mbed APIs which the micro:bit DAL APIs use to see if you can find a BLE RSSI API you can use.
ReplyDelete