![]() What I observed: In order for the event to trigger one critical part of the process is the ibeacon reporting it presence to PHlocation2. I did extensive trouble shooting and learned that this is tied to the ibeacon. I have been having issues with getting the event to trigger reliably. Whats involved: Homeseer 3, PHlocation2, Driveway motion detector, Geofency and an Ibeacon. It isn't so important that the advertising rate be set to a specific value as it is to set it to a high enough value to get good results, and many beacons are set to 1Hz or less frequent by default.My goal: Setting up an event that runs reliably and securely when I arrive home. But I'm not sure it is worth introducing a difference from the behavior of iOS given that it is not possible to make iOS work consistently. Yes, on Android, the calibration could be based on a packet count. On iOS at least, there is no way to get access to how many iBeacon packets were detected in a one second period - the operating system automatically averages the RSSI for all packets received in a one second period, so calibrations must be done for a fixed period of time and not based on packet counts. (Perhaps we should just rely on the latest iPhone device available and document what it was?) (I personally no longer have access to one, only an iPhone 6 and and iPod touch 5th Generation.) I'm not sure what to suggest as a tool for an easily accessible reference measurements that won't soon become obsolete. The problem with using iPhone 5 as the reference device, of course, is that as time goes on it gets harder to get your hands on an iPhone 5. It may be useful info in the future to remind you of how you did the test, and help you reproduce the results (or understand why you cannot reproduce the results) later on. I suggest recording it only as a best practice for recording your equipment for any lab measurement. I agree you cannot figure out the transmission characteristics by recording the beacon model. (I do see a few calculations are showing #REF! or #DIV/0.) I'll add those iPhone reference values if you give me edit access. Hey, great news on Google Sheets, Nice progress. If you could add new measurements, that would be great! I'll improve the Excel/Google sheets value later on, but for now, i just wanted to show you the progress and also show that the newer formula doesn't seem to add value. After all, it's not the speed, but the amount of measurements that improve the quality? For example, you could set the app to need at least 1000 samples. However, I think it would be a better idea to change your calibration app. Then, we could add some correction factor depending on the dBm of the iPhone 5s at one meter. That way, we could see what the curve difference for different output power settings is (might be different?). What I want to do next is do all the measurements again, but then for a lower power output. I think it's safest to rely on the iPhone 5s measurement.Different antenna types will transmit the signal to a different position. I don't see how we can correct for such a factor in the future. We for example use a prototype board of an Cypress and a prototype board of a Dialog chip. Difficulty here is that there are many different ones. Especially for the phones that you added, as sometimes I was not sure what the iPhone 5 reference value was, for example, as I found multiple values here on the board. It would be great if you could have a look at the spreadsheet. ![]() I got it running on Google Sheets, it just needed some omitted arguments. Would you all please add more readings, and verify current readings in the Excel file (attached)? I'm missing quite some data for what I found on this forum. Therefore, at every measurement, we killed and restarted the locate app, just to be sure. The iPhone app only took a few seconds for a reading, while the Android app started to give very different values.įirst column the values after killing and restarting the app. After about 5 measurements with the locate App, the app seemed to misbehave.Except for one Samsung phone, which always gives the same RSSI, and is useless anyway. The residual sum of squares (RSS) for the original formula is lower than the offset-formula for the phones I tested.It has been pretty rainy/misty here, but Friday I finally managed to do some measurements. Some test data can also be found in a couple of issues and pull requests: Good point about the test data - we really don't have it centralized, but it might be nice to make a shared google doc where we can keep them all in one place.īelow is a very old table of data collections from Radius Networks in 2015 MetersĪnd this is the data set from when the library's formula was first developed: Distance (m) I do not have any test results from following the exchange above. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |