Basically, I've had to come up with a 9-month project for my final year at university, and I've wanted to do something that incorporates the use of NFC and most likely Android devices. The project itself doesn't require to be entirely completed in the time, with good reasoning.
The concept I have thought of is to produce two seperate pieces of software, a Windows-based C++ application and a paired Android application which communicate via an NFC connection, using a USB NFC device.
The purpose of this would be to act as a form of remote for the PC, such as media controls, sleeping and waking the PC etc.
I would use something such as this: http://www.amazon.co.uk/Andoer-ACR122U-Contactless-Reader-Writer/dp/B00KX00WLE/ref=sr_1_1?ie=UTF8&qid=1441900306&sr=8-1&keywords=ACR122U for the connection, and the SDK provided by the developers https://www.dropbox.com/s/i3g3az3e7k1kfpo/H10391.zip
My question is just whether anyone, preferrably with some experience in at least a related area, would be able to enlighten me as to whether they think this would be possible?
Thanks for any help in advance,
Stephen
Related
Out of curiosity... has anyone ever been able to integrate AirDrop functionality into an Android app?
I really don't care about receiving any information on the Android side, but am hoping I can send information to the iOS side from Android. I'm hoping to find someone with a more in-depth understanding of how it works and if it is physically possible. Also, any direction on whether Apple has proprietary use over the protocol (or if it is just the name and branding) would be awesome!
Trying to build a cross-platform app and getting pretty close, but this would just extremely convenient if it works out :)
Currently, it is not possible as AirDrop uses Bluetooth to create a peer-to-peer Wi-Fi network between the devices. Each device creates a firewall around the connection and files are sent encrypted, which actually makes it safer than transferring via email. AirDrop will automatically detect nearby supported devices, and the devices only need to be close enough to establish a good Wi-Fi connection, making it possible to share files across several rooms.
Some Android devices use a combination of Near Field Communications (NFC) and Bluetooth to share files. But both Bluetooth and NFC are relatively slow compared Wi-Fi, which makes sharing larger files using AirDrop much faster and more convenient.
Regarding protocol, I don't think Apple has made it public and as far as I know Apple they must have patented it. Since AirDrop uses Bluetooth as well, and Android and iPhone Bluetooth are not compatible. Hence, due to all these reasons, we did not see any Android app that can send data via AirDrop.
I am currently trying to develop a mobile application for both iOS and Android. It basically will be a game buzzer app, determining which of the players is granted a right to answer a specific questions.
The problem is that I struggle to determine which technology / framework I should use for that. Now, some details:
In this app there will be a "base" - it is the phone that gives
"start" signal for all the other players. Each buzzer pressed before this signal corresponds to a false start. Eventually, information
about which player is granted a right to answer or is penalized due
to false start should be displayed on the base device.
App is done for people who have no access to the internet. All the
communication should exists given ONLY mobile phones with no data
plan.
Max number of communicating devices is 9 (1 base and 8 players)
I investigated a lot of resources and this is what I discovered:
Regular WLAN with TCP sockets and etc won't help, since it assumes that all devices are connected to same wireless access point - it violates my requirements.
Regular bluetooth won't help either. This would work across a specific platform, but making Android talk to iOS is impossible.
Situation with Wi-Fi direct is same as with regular bluetooth. Both platforms support this, but Apple's MultipeerConnectivity framework works only with iOS devices.
Now the last option I am left with is BLE. Both platforms support this and are able to intercommunicate (acting both as central or peripheral devices). However, due to my requirements for an app, I assume that base device should act as peripheral, and according to (sometimes conflicting) articles on Internet, one can't connect several central devices to single peripheral.
Now, my questions:
I still assume I might have done some mistakes in the bullet points above, so please, correct me if I am somewhere wrong.
Now when I am left only with BLE option, are there any possible solutions to the above issue? Maybe it is possible to use all devices as centrals (?). I recently saw this example, where everything works cool. Sorry in advance, if I said something stupid.
Of course, there is a counterexample - FireChat, which employs OpenGarden's MeshKit. But the framework is not available. I tried communicating OpenGarden people, but no response. Does anyone know if it is planned to go opensource soon, or maybe there exists any analog of this?
Try the Hype SDK by Hype Labs. It's a multi-transport, multi-hop mesh SDK. It supports interoperable Bluetooth Low Energy (and other transports as well). The SDK is currently in private beta but will be made available upon approval of the subscription.
This isn't a highly technical (or specific) question. I just want to know if it is possible to use an android app to control 12V relays.
I want to use this running android:
http://www.mini-box.com/pico-SAM9G45-X
with this touchscreen attached:
http://www.mini-box.com/INNOLUX-7-TFT-with-touchscreen
I want to mount this in my car and write a simple android application that can be used to control my lighting in the car (via several 12V relays). I have a lot of background programming in many different languages, so I am not worried about the application part. However, I have very little experience using software to control hardware.
Any ideas for this would be great. Thanks!
First you'll need to get Android running on your Pico board. There are several releases of Android ported to Pico for you to play with here: http://arm.mini-box.com/index.php?title=Releases
Once you accomplish this, I recommend wiring up an ADK board to the pico and using that to interface with your relays. http://developer.android.com/guide/topics/usb/adk.html The most popular and widely documented ADK board designs are based on Arduino or PIC chips so if you have experience with either I don't think it will be too much trouble. Writing the application would entail writing a program on the ADK which listens for input from an Android app which you also create and reacts accordingly. There's a handful of good information you can find with google searches to help you out and also some dedicated discussion groups.
Alternatively, it may be possible to use the remaining unused pins on the Pico to talk to your relays. I don't know for certain though if the Android ports support this or not.
It should be a fun project to keep you busy for a couple weeks. Good luck, and be sure to write up some information on it if you get it working!
you can find so many relay boards which come with wifi and they have their own app. which you can install in your Android phone or PC or iphone(you can find a ios app for same board). and you can also modify apps according to your choice and there are products which come with input pins also so you can control lights or anything else using those input. you can check this product check this Android control realy and there are so many products available.
what do you think about using android in an industrial embedded environment?
I'm thinking, for example, about a vending machine with a touch screen monitor. I can think about many advantages:
It would increase the ease of making an advanced user interface
Android provides tuned libraries to handle task like low power internet connection or encrypted connections
Thanks to dalvik VM, it is easier to run on different HW platform (Arm9 - Arm11 - ....)
but there are also some cons like:
Android is not thought for a mission critical environment (like a device handling money)... at least not to some extent.
If not kept up to date, the software may have some bugs that compromise safety. Issue is worsen by widespread adoption.
Someone might regard Android as resource hungry compared to a real time implementation of linux, with code written in C rather than java.
On the internet you can find some resource on the subject, but most is out of date:
http://www.hsc.com/Portals/0/Uploads/Articles/Android-Porting-on-Embedded-Platform_v2_0633850602027036930.pdf
http://www.androidforembedded.com/whitepaper/android-for-embedded.pdf
anyone has direct experience on the matter or can link me to some resource? What do you think about it guys?
Cheers,
I know of a Swiss company - Noser Engineering AG, which provides development of Android Software for embedded devices. Also check-out their showcase android to market
Android can definitely be used in a non-cell phone device. There will be pros and cons that you can find all around the web, which could be discussed during weeks.
On our side, we have been playing with Android for a while now (from the port of the OS on custom ARM board to app dev) and we see real interest from customers. Regarding reliability, as in any embedded device, it is important to validate it by yourself against the use cases that your system will have to deal with.
Eventually, if cons make you decide not to move to Android, you can have other ways to develop interesting HMI such as QT which runs efficiently great HMIs.
Anyway, you can check out our website (http://www.adeneo-embedded.com) and contact us if you need some help.
Touch screens in anything industrial is pretty much out of the question, believe me. You'd just get laughed at and wouldn't be able to sell it. Luckily, a vending machine isn't an industrial application and there a touch screen would be more suitable.
If you just want a touch screen with some GUI pre-made, there are probably 1000 companies already making such products, no need to re-invent the wheel. It would need to be > IPx5 classed too, if you want to put it outdoors in the rain and snow.
The main challenge for this kind of application is the money transactions, not the user interface. You should start there. What good money transaction software is there already available on the market, and what hardware is most suitable for it? To handle the transactions will be the real software problem for this application. Anyone can make some GUI touch screen fluff and have it toggle some relays or drive a stepper motor.
Also, I reckon the market for this application will mainly need 1) reliability 2) reliability and 3) reliability. The design, user-friendliness, visual appeal and fluffiness may let you sell one machine to a customer, but reliability will make you sell several.
Does anyone know of a cheap Android or programmable device that has wifi?
I need it for a project for a company that needs a Wi-Fi handheld device for the shop floor.
I'm not too fussed about the language the device uses though I'm not really interested in the iTouch as there's no intention to release the app in the app store and I don`t really want to jail break everybody's iTouch.
Ideally it would be small, iTouch size for example and relatively cheap $100 or less. Nothing fancy, just ability to write a simple UI and have Wi-Fi. Voice is not needed.
Not too fussed about touch or qwerty keyboard either.
How cheap is cheap? On the weekend I searched eBay for "android slate" and found a bunch at US $99. I bought one immediately. It may not have the world's fastest CPU or a heap o' RAM, but at that price, how can I complain?
Like you, I want to develop apps for use in an industrial situation. I'll list voice as a feature if I use handphones, but don't really need it.
Would you please publish your final purchase decision here and I will likewise if I find a "better" option.
Bear in mind that it's not all about the cheapness of the device and consider the development effort.
Android has at least 2 good things going for it.
1) Generally programmed in Java (although you can use C & C++ if you jump through a few hoops). I may be wrong but it seems that new grads these days only know java (no offence intended to anyone reading this) and even "old hands" with C++ can quickly pick it up.
2) Android was designed from the start for developers and has an excellent development environment and good tools.
I bought a bunch of Android books and really liked Unlocking Android: A Developer's Guide, but you might want to check Amazon for readers 5 star votes.
And I have just noticed Android Wireless Application Development which I will have to buy; I think that you might benefit from it too.
Oh, and if you want to outsource any development at competitive rates ... ;-)
There were some cheap Android devices at http://dealextreme.com