I'm using the Estimote SDK (3.6.0) for the communication with my beacons. Now I have read somewhere, that it is possible to get the advertisement package of the beacons with 5 Hz. Is this only possible with Estimote beacons or does this work with beacons of other vendors too?
Where can I change this update interval in the source code?
Thanks.
Each beacon vendor usually provides some means to adjust their beacons' settings. Most often, that's in form of an app that you can download from the App Store or Google Play Store. In this particular case (Estimote), that'll be an app is simply called "Estimote." For more details, you should consult the vendor's documentation or inquire with their support team (:
One final thought: with Estimote Beacons, you operate on advertising interval of the beacon (i.e., the time between packets being broadcast) instead of frequency. Since one is just an inverse of the other, 5 Hz frequency (= 5 times a second) is equivalent to a 200 ms interval.
Related
I am building an app in swift that helps me detect beacons and display their RSSI values. I was using the native CoreLocations library from apple to detect beacons but noticed that the rate of detection is set to 1 second and it cannot be changed. Is there a way to reduce the detection interval to say 100-500ms so that I can get more RSSI values?
You can also use CoreBluetooth APIs to detect beacons, which give you a separate RSSI measurement for each packet detected. For a beacon advertising at 10 times per second, this would give you an RSSI update approximately every 100ms.
There are two big catches to using CoreBluetooth:
It cannot detect iBeacon because Apple blocks it. CoreBluetooth can detect AltBeacon and Eddystone.
The API is harder to use with beacons — you have to parse out the identifiers from the packets manually.
Also, be aware that the RSSI value returned by CoreLocation once per second is actually an average based on all packets received over the previous second, so it is more stable than individual samples taken at a higher frequency. Depending on what you want the samples for, you may find the higher variation is a problem.
Finally, be aware that the max rate at which you get samples with CoreBluetooth depends on the beacon transmission rate. Some beacons advertise only once per second. If you are working with such a beacon, you will not get any more samples with CoreBluetooth.
Our application uses the Twilio voice SDKs for iOS, Android, and Web. Our use case relies on precise device synchronization and time stamping. We are playing an audio stream on multiple adjacent devices (in a Twilio conference call) and we need that audio playback to be in sync. Most of the time, it works great, but every now-and-then, one of the devices falls a little bit behind and throws off the whole experience. We want to detect when a device is falling behind (receiving packets late) so we can temporarily mute it so it does not throw off the user experience we are going for.
We believe that Twilio voice uses real time communication (web RTC) and real-time transport protocol (RTP) under the hood. We also believe RTP has time stamping information for when packets are sent out and when packets are received.
We are looking for any suggestions for how we might read this timestamp information (both sent & received) to detect device synchronization issues.
Our iOS and Android clients are built using Flutter & Dart, so any way to look at this packet information using Dart would be great. If not, we can use native channels through Swift and Kotlin. For the web, we would need a way to look at this timestamp data using javascript.
If possible, we'd like to access this information through the SDK. I don't see anything about timestamps in Twilio's voice documentation. So, if not possible, we might have to sniff for packets on the devices? This way, we could look at the RTP packets coming from Twilio to see what information is available. As long as this does not break Twilio terms of service, of course :)
Even if you could get this information I don't think it will be useful. The timestamp field in RTP has little to do with real time. In voice it's actually a sample offset into the audio stream. With a typical narrowband codec with a fixed bit rate and no silence suppression it's completely predictable from the RTP sequence number. For example, with 20ms packets of G.711 it will increment by exactly 160 each packet.
RTP receivers expect there to be random variation between the receipt time of a packet and its timestamp - known as jitter. This is introduced by delays at the sender, in the network and at the receiver. This is why receivers use jitter buffers to reduce the likelihood of buffer underrun on playing. The definition of jitter for RTCP - the interarrival jitter - is a calculation that measures this. That is - the variation between the (predictable) RTP timestamp and the measured wallclock time at the receiver.
Maybe you need something more like an NTP protocol between your client and your server.
On the Maxim EKG chip, INT2B can be set as a peak detection trigger. How do I send a BT notification, preferably with a timestamp as soon as possible through the Nordic platform? Thank you.
In Movesense architecture there is no direct access to hardware, everything happens via Movesense API (defined in MovesenseCoreLib/resources/movesense-api as ".yaml"-files).
The Maxim 30003 peak detection is accessed via /Meas/HR -resource which gives notification each time a peak is detected. That resource can be subscribed to directly from the mobile (via the MDS library, see: movesense-mobile-lib). The delay from the actual peak to the mobile notification should be relatively constant and dominated by Maxim chips detection delay (read: I have not measured). The BLE connection causes itself some delay that should be 20-100ms or so depending on the BLE connection parameters etc. This is the way I'd go for since later when we add the timestamp to /Meas/HR (it has been requested from us already) it's a simple modification to use the included timestamp.
Alternatively you can write your own sensor app (firmware) with its own API, that can subscribe to /Meas/HR and for each notification do GET to /Time/Detailed and return just the timestamp each time a peak is detected. For a starting point for that I'd recommend the jumpmeter_app and modify it accordingly.
Full disclaimer: I work for Movesense team
I'm new in beacons and I don't understand how the application manages the signals of the beacons. Because the app can receive in a short period of time many signals from the beacon. How the application does to manage that repeated signal? If for example a beacon sends a message and half a second latter the same beacon sends another message then the application get two signals of the same beacon. It means that each time the beacon sends a message the app shows a an add to the user? or how the application knows that this message was already displayed by the app?
Beacons do not send messages to users. They only transmit a unique numeric identifier over and over again, at a typical rate of 1-10 times per second. That's it! That is all they do!
Most of the functionality people associate with beacons is really provided by software that runs on a mobile phone, or even running on cloud servers. An iOS framework or an Android library detects the beacon transmissions and converts them to one of two basic event notifications for mobile apps to process:
Beacon appeared/disappeared (called monitoring)
Beacon is still in range at an estimated distance (called ranging).
By using monitoring events, mobile apps are told when beacons first appear, and can then convert the beacon's unique identifier into a message to be displayed to the user via a lookup table bundled with the app or on a cloud server. Thanks to the monitoring event notifications, the message only displays once for each time the beacon is first detected by the phone. It will be displayed again only once the beacon goes out of range and comes back in range again.
In my app I get the information of the beacons with CoreLocation and and the LocationManager.
I've set the advertising interval of the beacons to 200ms.
Is it possible to call the didRangeBeacons delegate method faster, so that i get the values of the advertising package according to the advertising interval of the beacon?
No, you cannot alter the frequency of the didRangeBeacons:inRegion callback, which is 1 Hz regardless of the beacon advertising frequency.
You can get callbacks for each beacon advertisement (every 200 ms in your case) using CoreBluetooth APIs, but there are a couple of restrictions:
It will not work with iBeacon transmissions as iOS blocks access to iBeacon advertisement data in CoreBluetooth. You can use AltBeacons, which are iBeacon compatible, and get the more frequent updates with those. You can buy beacons that send out both iBeacon and AltBeacon transmissions.
It will only work in the foreground. You cannot get Bluetooth LE manufacturer advertisements in the background on iOS.
Full disclosure: I am Chief Engineer at Radius Networks which sponsors the open source AltBeacon standard.