I have concluded that Eddystone and iBeacon may each have their uses - at least if I want to have the best possible beacon support in my Android + iOS apps.
It seems to me it would be simplest to have physical beacons that work with both - but since beacons are very new to me, I am not sure if they will be feasible:
In use (i.e. no major delays in broadcast and similar)
With concerns to battery drain in the beacon
Since I have zero experience with beacons, it is difficult had to evaluate the different maintenance aspects.
If you do not have day-to-day access to where beacons are placed - is it possible to acquire beacons that can do both without requiring constant maintenance?
While both iBeacon and Eddystone work well on Android, there are real disadvantages to using Eddystone on iOS, as detection times in the background are much slower, and it is not possible to launch a non-running app into the background on iOS with Eddystone. For iOS, Eddystone is best used with foreground-only apps.
From a beacon hardware perspective, both formats are similar. Hardware beacons come in battery powered and wall-powered variants. For best responsiveness and best distance estimating capability, it is important that the beacons be configured to transmit at their highest advertising rate and power.
If you do not have physical access to the installed beacons to change batteries, use wall-powered or USB-powered beacons if at all possible. Be very wary of manufacturer claims of battery life lasting a year or more. These claims are often based on low advertising rates and power levels that save battery but adversely impact performance for many use cases. Also, if both Eddystone and iOS are configured for transmission at the same time, battery life is cut in half.
If you use wall or usb-powered beacons maintenance is minimal. The main problem is people unplugging your beacons (e.g. to get a wall socket to use a vacuum or to get a spare USB port to plug in another device.) You can use locking covers over your beacons to help prevent this, but you cannot eliminate the problem entirely.
Related
Whilst this question has obviously been asked before, year's have gone by since then. Apple has released a new NFC spec in that time and further software updates indicate more speculation in this area.
A smartphone has an NFC chip. Is it possible to harness this to take an EMV payment from a contactless card or eWallet? This would obviously require an installed EMV kernel to securely process the payment and possible a means of accessing the secure layer for any PIN entry.
As much as this may seem like an ambiguous question, clearly the hardware is capable. Is it possible / legal / licensed in anyway yet. There is a service that claims to be working on it called PHOS.
Quite obviously, SO is not the right place for such a question as it's unrelated to programming. There's quite a lot of discussion regarding the topic and answers also will tend to be opinion based.
Up to this moment, it hasn't been possible on Apple (due to closed ecosystem, not hardware incompatibility) and became allowed for Android. Technically it's been possible for a while already, but regulations made consumer grade devices incapable of acceptance - they are still quite terrible in the physical aspect as they are not designed to either handle entries securely as well as generate the electromagnetic field according to EMVCo requirements as to the shape and operating volume. Payment schemes have generated as list of special criteria for solutions based on consumer grade devices and the company you mentioned is one of many that have been working on it. There certainly are already some production deployments with limits that have been set by the schemes.
There might be changes in Apple approach (especially as they acquired a company dedicated to such solutions) or not. This is just speculation. The fact is that consumer devices tend not to be as good as dedicated hardware but only time will tell if this stays true. Security research is ongoing, we shall see the results and how will that affect companies policy and further development in the area. It's just too early too tell.
I am hoping this is a relatively simple answer. Ive always been interested in ar, and I've been debating about tinkering with a possibly ar driven ui for mobile.
I guess the only real question would be having the camera continuously turned on, how much battery would that use? i.e. would it be too much for something like this to be worth doing?
Battery drain is one of the biggest issues in the smartphones nowadays. I'm not a specialist in power consumption or battery life or whatever but anyone having and using a smartphone (not only for calls of course) would not be wrong by saying this. There are many tips on the internet teaching you how to increase the battery life. In fact processes running on your device need energy and that energy is provided by the battery.
To answer your question, I've been using the smartphones' cameras for AR applications since quite long time now. It's a heavy process and indeed it drains the battery faster than other processes. On the other hand you also have to consider the other processes running on your device while your AR application is used. For example your app might use the device's sensors (gyroscope, GPS, etc); these processes are draining the battery also. A simple test that you might do is to charge your device, start the camera and leave it until the battery dies. Well that's exactly how much the camera would drain the battery (you can even measure the time). Of course you might want to turn off everything else running on the device.
To answer your second question, it depends how the application is created (many things can be optimized a lot!) and how it's going to be used. If the goal of the application is to be used continuously for hours and hours then you need to wait for some other kind of technology being discovered (joking..I hope) or having extra power supply attached to your device. I think it's worth doing the application and optimize it on the fly and also in the end when everything is up an running. If the camera is the only issue then I'm sure it's worth trying!
I am learning about mobile web apps, and they look interesting. Among other things, I am wondering whether there is a significant difference in battery consumption between the native apps and web apps? (Phonegap, intel xdk, etc)?
There can be a significant difference due to use of transceivers (i.e. the receiver and transmitter on your phone/tablet). On any mobile device, whether notebook, tablet or phone, the processor and peripherals drop into power conserving sleep states. Processor sleep states are called C-states. Peripheral sleep states are called D-states. Thus the greater battery life when your phone is idle. The longer the period of idle, whether processor or peripheral, the better the battery life.
What does this mean for web apps versus native apps? Native apps will use more of the processor but less of expensive peripherals (read that as transceiver include GPS). Both the processor and transceiver are power hogs. So here's the bottom line:
If your web app does a lot of cloud access, it's going to pull down the battery. This is why using the GPS to give you turn by turn instructions kills your battery life (and makes your phone a little heater).
If your native app never goes to sleep or gets any rest (e.g. it does polling instead of using interrupts, or if the interrupt period is too small), you'll pull down your battery.
So the ideal app balances native and web computation to
minimize processor usage (more specifically, maximizes periods where the processor is idle)
minimize peripheral usage (read that as minimize the number of web accesses)
As you can see, these goals are a little contradictory. From a designer perspective, you want to move as much computation onto the cloud while keeping data as local as possible.
Some computers (e.g. Dell, Vaio) come with software that prevents a battery from charging.
This functionality allows me to use my laptop with battery (protected from power outage) and keep my battery from charging until it's down to, at most, 50% battery/charge remaining.
I want do write some code to automate this task.
I searched Dell Support Center for a solution, and I searched Google, too - no luck with either.
I thought about downloading the program and debugging it, but I couldn't find it.
Has anyone ever seen something like this?
Thanks
PS: I want to do this on a Dell Inspiron, and the code can be in C++/C# (or something)
I've never heard of a program that disables battery charging. (Why on earth would you want this?) If such programs exist, I imagine that they interact with the firmware or hardware at a very primitive level.
One thing you can try is a busy loop (burning power like mad) that checks the battery level and sleeps for a bit once it gets down to the target level. This won't do good things to the cpu temperature, however.
Some laptops come with battery charge limiting functionality - it is not via software though, but via firmware plus dedicated internal hardware I guess. Some Lenovo and Acer have such capability. The logic is not in software as the charge limiter kicks in even when the laptop is off.
The reason is that battery degrade when kept at 100% - as it is the case with laptops that are always plugged in. The new Acer Swift would limit at 80%, some Lenovo let one input a particular value.
If interested I can provide you with the software side - it works on Windows and Linux but can easily be available on MacOS. It works in conjunction with external hardware - i.e. a homeplug.
The code works but it's by no means production ready. It would need a bit of tweaking for a particular operating system and homeplug. Let know if interested.
Available on github: Charge Limiter
There is some easily available information on finding the status of a battery, or whether it's charging or not. (GetSystemPowerStatus API or System.Windows.Forms.SystemInformation.PowerStatus).
I want to be able to stop a battery from charging based on some criteria, e.g. battery power > 20%.
Is there an API to do this?
I think it's impossible, because you have need some API for battery or battery charger.
And this API can provide to you manufacturer of notebook and battery or battery charger support this.
I honestly don't know, but I'd have a look at the APM or ACPI APIs.
Other than that, the only option I can think of right now is a USB controlled robotic arm that ejects the battery when you need to stop charging, but that's probably not what you are looking for, and borders on the complicator's glove in terms of level of over-engineering. :)
I would just get a UPS and programatically tell it to cut all power... most should have an interface for doing this. Otherwise, as someone already said - a computer-controlled power strip would do it ^^
I've actually played with this idea when I was testing/writing about way too many new laptop models a while ago and the battery testing was annoying to set up, monitor and analyze.
I wrote an app that would do exactly everything (setup, listening, measuring, reporting) except unplugging the power and then replugging it and starting the computer again...
One of the options is to get hold of the device(I) for battery (Microsoft ACPI-Compliant Control Method Battery).
Listen for PowerNotification events forever. On each notification check the PowerStatus of the battery.
There are APIs for all of the above purposes in .Net and win32
Keep the device(I) disabled as long as the powerstatus is >threshold. Enable it as soon as goes below that or when you are not on AC power (i.e. before removing AC power, your continuously monitoring software should enable that battery device - or you manually enable it).
hmm,...this is a very buggy solution, but it can achieve what you want, although you have to be very careful.
Actually I use such a charge limiter. There is the control software - a Python script that monitors the battery level (psutil module) and controls external hardware - i.e. a switch that can be software controlled. I have Energenie and TP-Link homeplugs plus my own hardware contraption.
As it is for home use the software it's not polished at all, but with minimal effort can be adapted to any OS or hardware.
Let know if interested. The software lives here: CCC