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
Related
Is it possible on Wear OS to constantly record heart rate data and/or other sensor data in the background and send it via WiFi/4G without a phone?
Can such a service start on boot?
Yes - but if long lived you must use passive updates to get batched data, otherwise you will likely ruin battery life.
https://developer.android.com/training/wearables/health-services
https://developer.android.com/training/wearables/health-services/passive
You can request an LTE or Wifi network to sned data when you have enough to send. But you shouldn't try to keep the network open permanently.
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.
I'm building a progressive web application (target is smart phones for now). The app needs to be able to access heart rate and heart rate variability, ideally in real-time. While it seems totally asinine, I'm open to using REST calls to some remote server if that is the only way. I'm also fine with restricting the app to only work with certain hardware if necessary. In this case, the ideal hardware would be some sort of earbud that uses optics to scan for heart rate, but at this point, I'm open...
The best that I have thought up is to find a heart rate monitor that converts the direct signal into audio and use the microphone web API. That seems like a lot more work than ideal, so I'm hoping someone has a better idea. Any ideas are welcome. Please, no one downvote anyone if it doesn't solve all my constraints. I've been working on this for a bit and I'm not sure that there is a clean and perfect solution yet. Thanks in advance!
If the sensor can speak Bluetooth, the Web Bluetooth API can perhaps help: https://developer.mozilla.org/en-US/docs/Web/API/Web_Bluetooth_API
https://developers.google.com/web/updates/2015/07/interact-with-ble-devices-on-the-web
How about use a Web Bluetooth that lets you control any Bluetooth Low Energy device like heart rate monitors. It will read the Service Location Characteristics (which tells your where the sensor is placed - which body part) and subscribe to notifications from the Heart Rate Characteristics, meaning you will get an event whenever the device performs a new measurement. Then use a service worker that will define the behavior of the app to mimic native app capabilities like offline support and notifications.
It's like a Physical Web that you can send a link to your website from a Bluetooth beacon to a user's device and with PWA, that link can be to your web app that looks, feels and functions like a native app. Then with Web Bluetooth, you can then speack to the device. Visit this blog post for more details.
Is it possible to track motion sensor events on Android continuously, even if the app is not in foreground?
If yes - what's the drain on battery?
A client asked if it would be possible to write an app that would initiate an action if the person "falls" - which basically means continuously listening to the motion sensor for rapid movement.
First, you can definitely monitor the sensors in the background. You need to use a service for that type of application. Here is an example of someone creating a barometer data logger. There's not really any reason you couldn't use different sensors.
Second, as far as I'm aware, running the sensors continuously like that would drain the battery quickly. This presentation suggests that depending on your sampling speed, you could burn through about 4% of the battery per hour on the sensor use.
Lastly, you can definitely wake the phone and take action upon an event received by that service. See this question.
I'm planning to setup some sensors for a project I am working on. I plan to use a simple xmpp client on each device hosting sensors and posting the readings via PEP/PubSub.
I would like to run a program which dynamically displays this sensor data upon receiving the push notifications from the sensor clients.
I intend to communicate on a LAN with 100Mbs connections and several WIFI APs as needed for the sensor locations.
Is XMPP a good choice for a backend?
Would this scale well at say 100 devices running 6-24 sensors each updating every 15-30 seconds?
XMPP would certainly be able to handle this use case, and seems a good fit based on the small set of requirements you have shown. I am assuming that the sensor data is small amounts of textual information.
From what I can see, I would not use PEP though, just straight up pubsub with a single node for all the sensors to publish to. Pretty much as simple as it gets.
I would think that any XMPP server should be able to easily handle that load. I know I was able to publish 800,000-1,000,000 items to a persistent node in Openfire in about 5 minutes (3.7.2 alpha version). A non persistent node would probably do a little better.