The Setting:
Imagine a small indoor venue. Audience seating in the venue is rectangular and has 10 rows, with 20 seats in each row. The venue is full of people, 200 obviously, and each has a UWB-capable cell phone in their hand. The venue has several Qorvo UWB+BLE devices placed throughout the venue and configured/calibrated ahead of the event.
The Solution needed:
Each of the 200 cell phones is running a mobile app with the Qorvo SDK embedded in the Parent App. The parent app knows there are 10 rows and 20 seats per row in that venue but it does NOT know which device is in which seat. Seats are numbers back-to-front, left-to-right 1 thru 200. I’m in search of a UWB+BLE beacon solution whose SDK will allow my Parent App to enumerate which device is in which of the 200 seats.
Will the phones actually be in their hands? In their hands it is probably doable, if they are in pockets/bags then probably not. You could probably get close but a few seats would probably end up swapped some of the time.
In their hands the signal blocking from their bodies is minimal and similar for each device. If it’s in a pocket then signal blocking is going to be a lot worse, non-uniform and directional.
As for actually implementing it, there is nothing off the shelf to do this that I know of. You would be looking at custom software built on top of the SDK but with some effort it should be possible.
Thanks Andy. Yes. In their hands. and even better, held up in the air. (Think fans at a music concert holding up their phone)
I’m the owner/developer of the app on the phone. It is also my believe as well that I could add some custom code on top of an SDK from Qorvo’s products to solve for this.
I would have the advantage of knowing the physical grid of seating and the desired numbering system ahead of time. As such, I’m guessing wherever a device “sees itself” in the grid could be a point looked up in a table that maps seat numbers to the set of x/y points expected in that venue.
Am I thinking about this correctly?
In this method, and depending on positioning accuracy, it’s possible two phones will believe they’re the same seat # as there’s no phone-to-phone awareness going on. This is actually ok for my use case if it happens occasionally in a 200-seat room. But the hope is that accuracy is tight enough in the technology that the average square footage of a seat in any given venue is within the accuracy of the positioning hardware.
Lastly, not all phones will have UWB radios. Some will be BLE Only. Is Qorvo’s SDK and Hardware solution able to be “hybrid” in that it’ll automatically chose the radio available on the phone (BLE or UWB) in the SDK?
I’m not too familiar with what exactly you can and can’t do with their SDK on a phone. I run the devices in a bare metal embedded system, I don’t even use their device driver code.
As you say once you have a position on a local grid converting that to a seat and calculating how central to the seats area it is as a confidence measure is fairly simple.
With a few devices in known fixed locations around the area the underlying UWB system should be able to get a position to a good enough accuracy to identify the seat, or at least a couple of seats if the calculated position is on the boarder between two. Under ideal circumstances the position errors are under 10cm, easily good enough to identify a seat. Circumstances are rarely ideal so you may get some ambiguity but with a little bit of filtering and averaging you should be able to be within one seat of correct the virtually all the time.
You may also hit 2D vs 3D issues. Due to the geometry you end up with in most real world installations height is always a pain to measure accurately. But if you treat everything as 2D and the devices aren’t all at the same height (or at least at known heights) then the numbers won’t add up you’ll get errors in the horizontal location. In your situation since you can’t control the height of the phones you may want to calculate a 3D position and then ignore the height. But this has the down side that 3D calculations require more range measurement points.
Assuming you can put enough fixed points in the area a pure phone to infrastructure system is probably far simpler than trying to measure phone to phone and create a mesh positioning system. How many is enough would depend a lot on where you can put them, if they are at seat level you’ll need lots due to bodies blocking the signals. If you can put them up in the ceiling then you’ll almost always have a clear line of sight. This means less needed, better range and more accurate results. In that situation a half dozen may be enough depending on how the ranges work out, adding more would allow more accurate position calculation.
If you could add some phone to phone ranges then even if they aren’t used for seat calculation they could be used as a way to verify the data and give a confidence indication in the results. If two phones are measured as 1 meter apart but you’ve calculated them in seats at opposite ends then you know something has gone very wrong.
I hadn’t thought about implications of 3D. Some venues will certainly have a slope to their seating, and maybe even a curve - or both. As I develop myself into this solution one step at a time, I was planning to leave any mesh or phone-to-phone communication off the table. Bang for the buck right now would be to get 2D working with no mesh and flat seating and beacon anchors mounted up high.
To give usage context, see the attached picture. This is a WORSE CASE venue :), but one I hope to solve for as I develop out this use case.
My startup, KrowdKinect, already handles the phone communications to set pixels (phones) to whatever color is necessary to create the images. Today, position is manually input by the user in the app by entering their seat number - but I want to automate that with a BLE/UWB positioning solution!
Whenever KrowdKinect sends out an image to be displayed on the cellphones of the entire crowd, I want to be able to account for a user having moved seats. Plus, venues where assigned seating isn’t at play, I need a way to create my x/y grid, so position mapping solutions like this are what I"m going after. As long as the phone has it’s seat # (even if it changes) at the moment the image is sent out, the phone will turn the color assigned to whatever seat number they have at that moment.
when we say 2D that just means in a flat plane that only requires an X and a Y to locate a point. There is no requirement for that plane to be parallel with the ground, as long as your anchors are at a slope that matches the stand then you do have an essentially 2D situation.
why do you care about seats? If you have an X/Y location for the phone then why do you need to map it to a physical seat in order to work out what colour to use? Surely the next layer in your software is taking that seat location and mapping it to an X/Y location in the required image. Why not skip the whole seat abstraction and map directly from phone X/Y to location in the required image? Or if that causes too many issues for the existing software layers create a virtual seat map to convert between the two, it doesn’t need to bare any resemblance to the actual locations of physical seats.
Getting good locations in an environment like that will be tricky, it would be hard to put many fixed reference points in locations with a good view over lots of people. At least not in all directions and if the reference points are all off to one side the accuracy sucks.
I was thinking indoors where you would have a ceiling to mount things on. In an essentially outdoor environment like that it gets harder. Have you considered using GPS? The absolute accuracy of a phone GPS wouldn’t be good enough to get an individual seat but a lot of the error sources would be common to all the phones, if the whole image ended up being half a meter to the side it wouldn’t be the end of the world.
Or a combination of GPS and UWB, GPS gives you a rough location for all the phones and then you could use UWB between phones that you already know are close together to fine tune the map.
X/Y position isn’t used in the app actually, but rather a sequential numbering scheme applied to the full physical seating structure of the venue; seat 1 is back-left, seat n is front-right. To recreate a digital beachball, for example, bouncing around the crowd, screen pixels are only defined by where the image of the beachball needs to be at any given moment. Only pixels that need to change color to create that motion are updated in subsequent messages from the server.
I’m thinking If an indoor positioning SDK sitting atop the KrowdKinect app on each device can work out a “place in the room”, and pass that variable down the stack, then all I have to do is create a static lookup-table that says what seat number (in KrowdKinect’s numbering scheme) is at that position in that room. b.t.w. GPS isn’t being sought after because it’s not going to be usable indoors. For large outdoor venues (like the screen shot above) we generally use the seat number from ticket sales passed in from a Parent/Host app. In that case, the same static lookup table is used to convert the stadium’s seat number to the seat Number KrowdKinect uses.
