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.
Related
I'm researching and trying to building a RC car that can be controlled by the internet. I've started looking into how communication over the web works, but I seem to be going nowhere. My goal for the project is straight forward:
The RC car has an on-board camera and 4g wifi router that enables communication (driving commands, video streaming) over the internet. A Raspberry Pi will serve as the on-board computer.
I will be able to control the car with my PC even across the globe, as long as I'm connected.
I want to preferably do as much by myself as possible without relying too much on other people's code.
So here are my questions:
How does an application communicate over the internet? What is the interface between the application's logic (e.g pressing "w" to go forward), and transmitting/receiving that command over the internet?
How is video data stream handled?
I've looked into WebRTC and WebSockets for communication, but they are aimed at providing real time communication to web browsers and mobile, not something like a raspberry pi, and I'm still in the blind as for exactly what technology should I use, and in general the overview and architecture of real time communication.
All I've achieved so far was an app that sends text messages between devices through a server on my network, with very primitive reading/writing using java Socket.
In short, what does messenger/skype/zoom do in the background when you send a message or video call?
Any guidance would be greatly appreciated.
First things first. You cannot do real-time control over Internet, period. There is absolutely no way to guarantee the delivery latency. Your control commands can arrive with a delay from milliseconds to seconds, or never. No way around it.
Now, you can still do a number of reasonable steps to absorb that unpredictable latency as much as possible and safe-guard your remote robot from the consequences of the unreliable communication.
For example, instead of sending the drive commands directly - as in, acceleration, deceleration, turn angle, etc., you can send a projected trajectory that is calculated from your drive commands locally on a model. Your RC car must be sufficiently smart to do some form of localisation - at the very least, wheel odometry, and with a good enough time sync between the sender and the RC car you'll be able to control the behaviour remotely without nasty consequences of drive commands executed at an unpredictable delay.
You can add a heart-beat to your protocol, to monitor the quality of the communication line, and if hear-beat is delayed or missing, initiate emergency stop.
Also, don't bother with TCP, use UDP only and maintain your own sequence counter to monitor missing packets. Same applies to the telemetry stream, not just command channel.
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.
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 would like to trigger an event (e.g. play music) on multiple iOS devices at the exact same time (by means of milliseconds)
My approach is to keep a socket connection and send a timestamp to iOS devices (10 seconds later from current time) and trigger the event on iOS devices at that timestamp.
Problem is iOS devices might differ 1 or 2 seconds and that would cause a desynchronize. And even timestamps are pointing out the same time on each devices (AFAIK) they are not on millisecond sensivity.
Is there any way to trigger an event simultaneously on multiple devices, or an approach which should be followed?
Don't send the data over the Internet. You can't assume the connection latency will be low enough for your needs. Use Bluetooth instead. You can do with with GameKit, with dns-sd, or with a library like HHServices.
Pick a device that will act as the controller. Apple provide sample code to do so with GameKit, but it's not difficult to think up your own method. When you want to trigger the action, that controller will send a packet over Bluetooth to the other devices.
I doubt you need lower latency than that, but if you do, have the controller send packets to each connected device to ascertain the latency for each connection, have them send their timestamps to the controller, then the controller should be able to calculate a timestamp for each of them that will occur at the same time.
I need to receive data periodically through a BlueTooth External Accessory.
I implemented an event-driven model of EA's streams. However, the initial transmission from bluetooth is always delayed. For example, if each packet was 15 bytes long, the stream delegate would not fires until about 150 bytes.
Will polling help?
EDIT:
Also I found it hard to recover the session after the app switching back from background to foreground. Trying to open session again would fail. Any idea?
Read every bytes when NSStreamEventHasBytesAvailable arrives.
Did you develop your own Bluetooth accessory? May be the MCU only flushes after sending every 150 bytes.
Also you mentioned initial transmission. Do you know once the Bluetooth device is paired and connected to iPhone, it has to go through some identification process, handshaking some secret certificate. This may take few and even 10 seconds, depending on signal quality. This may be the cause of delay.