Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add support for multiple beacons from the same device #150

Open
wz2b opened this issue May 27, 2021 · 1 comment
Open

Add support for multiple beacons from the same device #150

wz2b opened this issue May 27, 2021 · 1 comment

Comments

@wz2b
Copy link

wz2b commented May 27, 2021

Is your feature request related to a problem? Please describe.
If you create a device that has multiple beacons - for example both iBeacon and Eddystone - the nRF Connect tool for Android just shows the most recent beacon received. If they are being transmitted at the same interval then the too just flips between them, always showing the most recent.

Describe the solution you'd like
It would be nice if the tool recognized that for a single MAC address it was receiving multiple beacons. It could show them in a hierarchy (like a tree) or it could just show them as two separate entries in the list view.

Describe alternatives you've considered
The main way around this for now is to click on the beacon in the scan results and then look at the log (beneath the graph) by clicking MORE. This lets you see what's going on and is helpful for debugging. I don't think that log is meant to be used that way, though, and with rapid beacons that list gets pretty long quickly, so it's not ideal.

Additional context
I realize this may be a fairly significant change in that the listview that shows scan results is likely using the MAC address as the primary key. I also understand it may be challenging to figure out that two different beacons are being transmitted nearly-simultaneously and are therefore really part of a set of related advertisements. The easiest way to implement this might be to just have the listview key off of the mac AND beacon type as best it can. This probably would only work for known beacon types though, which would be a bit of a problem for me as my end goal is a custom beacon format. I'm not sure of the solution here.

@philips77
Copy link
Member

The Device Details (MORE button) is intended exactly for this use case. I understand you'd like to see the 2 last different advertising packets on the Scanner tab directly, but imagine you have a device that's switches between 3, 5, or 10 packets. Or, in other use cases, like a temperature sensor, that's advertising with a temperature value, so the value in the adv packet depends on the sensor. Currently, you can see all of that in the Device Details screen on HISTORY tab. I see that this log gets very long and perhaps you don't need all of this information in your case, but from the top you see the most recent packets. You can see the intervals, advertising intervals and the graph. What could be done is:

  • on Scanner tab there could be an info that a device was changing advertising packet. I'm not saying I'd display it there, but some visual indication, that it's a good idea to go into MORE.
  • a new tab in Device Details, where the different packets would be shown without the graph and intervals. Just different packets the device advertised with since scanning was refreshed.

Also, nRF Connect for Android has some more features you may find useful:

  • You may select 2+ devices and tap on the TIMELINE icon on the top. This will give you similar log, but with packets from more devices. This is useful e.g. in Bluetooth Mesh, when more devices are talking to each other on ADV Bearer (advertising) (however, currently we do not decode packets).
  • If a device advertise with a value that can be parsed to a number (INT8, SINT8, INT16, SINT16, INT32, SINT32, FLOAT16, FLOAT32), in Device Details you may see more tabs showing how the value is changing.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants