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.
Related
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 have an Arduino based device interfaced to a 3G modem which I use to record data from several sensors in a remote environment. I would like to be able to send commands and stream some data from the device every now and then back to my standard network connected PC. If the remote device was connected to a WIFI or other local area network this would be relatively straightforward, but as the device connects over 3G this means that it is behind the 3G carriers NAT and so establishing a connection to the device becomes difficult.
The device can, of course, open a TCP connection to my host PC any time it wishes, the problem is telling the device when i want it to do so. I need some way of getting some kind of message to the device to notify it that I would like it to initiate a connection to my PC.
I've been reading up on NAT traversal techniques that app developers use to initiate P2P comms between 2 devices both behind NATs such as UDP and TCP 'hole punching' but this method seems rather too complex for my arduino system. Another general idea is to have the device polling a web server periodically looking for a signal to initiate a connection, but I'm not sure how much traffic (and data usage costs) this would generate as the device would have to poll every 10 seconds or so in order to make sure it initiates it's connection within a reasonable time frame of the request being set on the web server that it polls.
Is there any commonly used method of achieving something like this? Any general ideas or insight would be much appreciated
Thanks,
James
I think the solution will depend largely on your particular applications and requirements.
There are several ways to achieve this type of functionality and it looks like you have covered some of them already. The most common are:
have the device poll the server. This may be ok depending on the response times you need. If you need to poll as regularly as you suggest above then I imagine power may be more important to you than data rates, especially if you are battery connected. With a typical 3G data plan the polling itself will have a negligible data overhead, I would think.
have the server send a SMS which then triggers the device to contact the server. You need to make sure the SMS variable delivery time is ok for you and you also have to be aware that SMS delivery is not guaranteed so you would have to build in some sort of check for delivery at a higher layer (or into your application).
use some low cost Android based device for your 3G connectivity and leverage the Google push notifications mechanism
It is worth noting that server polling typically gets very bad press as it is seems intuitively wasteful to have the client and the server constantly checking for messages, especially when the actual messages are fairly infrequent. However, underneath most push solutions there is still a pull mechanism in the background, albeit generally a very efficient one that may, for example, piggy back on other messages between the network and the mobile device and hence have minimal power and data overhead. Personally, I would say that if you do not have major concerns with battery/power or with the load polling might generate for your servers, then it is worth exploring if the simplicity benefits of a polling solution outweigh its other disadvantages.
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 trying to create an iOS application that sends data over UDP continuously over wifi/3G network.
I have an issue when I launch my app over 3G network after like 10 seconds I get this message :
sendto() : No buffer space available
It's not that a big deal because my app still works well BUT when I quit the app, I guess my buffer stays full because I can't use 3G anymore (I have to wait some time or reboot my phone)
Is there a way to flush this buffer before I quit my app ?
It sounds as if you're hitting the outbound bandwidth limit. If your app does this continuously while in use, isn't that going to make it very expensive for users to run? Most mobile users, I would guess, are on some kind of metered plan where they pay for transferred data.
I would guess that closing the socket normally before exiting should flush it first, since you've requested the data to be sent after all, but sometimes UDP sockets don't try very hard to deliver the data (since they are "lossy"), perhaps that's what's happening in your case too.
I want to log the number of bytes being transferred from my iPhone app to server so that I could put a watch on the bandwidth being eaten up and could take necessary actions.
How can I do this?
In Instruments there is Network Activity Monitor that does what you need. You can always correlate your findings with network usage numbers in your Settings.app on actual device. Settings->General->Usage
Update:
Second approach:
Make sure you use cellular connection first
Reset your data counter.
Launch your app and perform operations that interested in
Quit your app and see the traffic used in Settings.app
On the picture below is traffic used for my app in 2 minutes.