We are making a SIP-related solution and I am requested to compose an app on a customized android pad(4.4.*). Unluckily, the pad is from 3rd party and accordingly we hardly do further jobs on the framework or driver......
On the Pad, a LAN port is designed over USB and we plan to access network via LAN. Besides, no power key is populated on the cover.....
Now the question is: Since the pad sleeps, the LAN connection is stopped soon. I fully understand it's a normal behavior that android conducts. I am trying to acquire known wake lock(partial or WIFI lock) to stop USB controller from sleeping ... but, currently, little progress. is there any usb-related wake lock, just like wifi lock ?
I have solved the problem from the perspective of HW .... I am not sure the solution is really meaningful to the current topic. But I think that sharing the idea with you is the major goal of the forum running.
a MOS component is added along the power line controlling Screen. Then I manipulate the connection/disconnection by sending command to MCU....
Based on my experiences , it is really hard to extend functionality on a poor quality of pad ... poor post-sales support.......
Hope you it's helpful to you.
Related
I am new for esp8266 device. Actually I'm interfacing esp8266 wifi device with Arduino for wifi and Android based home automation. But when I switch on the light that time, wifi connection automatically disconnecting.
Why it's happening? And what is the reason behind that?
I would guess switching on the AC device either causes electrical interference (the spark on the relay can be quite bad) which breaks your WIFI signal, or interrupts the power supply to the ESP8266, which can cause WIFI to fail.
But you really really really need to be more descriptive if you want a helpful answer :)
What is your exact setup, what is connected to what, and how, how are your power supplies organized, etc.
I wouldn't rule out a software error either, so can you give some details on your software setup also?
Be specific on the details on the failure, what does 'wifi connection automatically disconnecting' mean, exactly? Log files help.
I have had a lot of issues with EMI and RFI when it comes to media or commands with automation and distributed AV. In fact there is still one area of my house approx. 2sqft that simply goes not get any wifi and will kill hdmi data. i have done certain things to adapt to it while I figure out the issue but if it was an EMI or RFI issue you would be able to hear it with a tone generator used to sniff wires. If it is an EMI issue it could possibly be a bad ground connection and i am assuming that is what my issue is however it is an extremely high voltage and current wiring (not romex it carries the power to the hvac and steam room unit) and will have to wait to shut down all the power to the house and possibly get an electrician over here also to make sure I don't burn the house down or electrocute myself. Being zapped isn't that bad if the breaker trips but this particular one is a bit worrisome.
I'd like to use android's bluetooth for some kind of sensing devices. But I don't want to connect to these devices. As far as I know Devices won't react to scanning when their own bluetooth is disabled. But is there any way to get my app noticed when such a scan has been performed by a remote device, even when my app is running with bluetooth turned off?
I don't want to force toggling bluetooth on, but I need to get some kind of Action started in other devices running the same app. So I'm wondering if some there is any description/data field that can be sent with a bluetooth scan, so if scan is rejected the app has the opportunity to read that data just to know there was this specific call?
I need to leverage context-awareness within my system as to users, not knowing each other, still can interchange content (if they agree). But I need to find some ways of sensing while I also don't want to have all sensors activated all the time.
Hope you can give me a hint, or tell me that this is simply not possible, which would also help me not spending any more time on that.
Thanks.
I am writing a local communication system between Android phones that are connected to the local Wifi Access Point.
In the design of my system, the Android phones should notify the owner once they received an UDP broadcast packet from the Windows server.
The system works just fine when the screen of the phone is turned on. But it is found that, once the screen of Android phone is turned off, the phone just ignored the packet, just like no message is received.
I have tried Google for many time, but still no luck. Actually I really don't know what keyword should I use for doing the searching.
Do any one know how can I do what I want? Thank you very much
You will need:
a WakeLock
a WifiLock
a suit of armor, to better defend yourself from users who do not like it that you are keeping the device awake and WiFi radio powered on
I am writing an application for android that will use opportunistic communication. So when two devices are nearby they exchange data. For now it will happen when they are in the same wifi network (using mdns) or when they have paired bluetooth interfaces.
I was wondering from power manager point of view. Will my ongoing service be paused when phone enters sleep mode? If yes how do I prevent it?
Also any general tips how to make it consume as little power as possible? I was thinking to wake it up from time to time, but then there's a chance that it will miss a mdns query sent by other device which I want to avoid to maximize throughput.
And just to clarify - yes, I do want to use opportunistic communication and no I do not want to use any solution that involves connecting to the internet.
Any help appreciated.
Use Wakelock to indicate that your application needs to have the device stay on.
but it consumes considerable amount of power.
you can also use AlarmManager to start your app at that particular time when wifi is available
I'm currently working on an android project and I am trying to find the best way to go about setting up communication between two android phones.
One android phone will be docked on a mobile platform e.g. an R/C car. I want this phone to receive simple control signals ("forward", "backward", "left", "right", "gotoCoordinate") sent from another android phone. I also want the docked phone to be able to return status signals.
Preferably I want the communication to happen via GPRS. I'm aware of the difficulties concerning P2P-communications and I'm currently looking into "Android Cloud To Device Messaging." (http://code.google.com/android/c2dm/index.html)
I'd like to hear about your experience with Android C2DM (glad to hear about delay from transmit to receive) and your thoughts on utilizing it in my project. I'd appreciate other suggestions on how to go about this. I'm expecting to have to deal with relatively high latency using this method, but of course preferably lowest possible.
C2DM makes no guarantee about the "delivery or order" of the messages, and it is limited in the number of messages you can send (a high limit, but still a limit). It's not really for low-latency stuff like controlling an RC car. It's better for non-realtime events.
http://code.google.com/android/c2dm/
For lower latency stuff using GPRS you can setup a third party server on your own and have both phones communicate through it. I've done that for several Android apps using straight up TCP sockets and it works reasonably well (and it would be even faster/better if you went UDP). Using GPRS may still have too much latency, depending on your needs, but it's a tradeoff (it's very convenient, almost always there, other methods are not).
The ideal way to do this would be to combine whatever is available and fallback gracefully, and test the latency once connected to make sure the network is up to par, or bail out. For example, use the local WiFi network if it's available. That is to say, have both devices "register" with a third party server as they startup, then if they're both on the same WiFi just have them communicate directly (run a server on or both, and clients on one or both, get information about discovery and such from the registration). If they are not on WiFi then fall back to GPRS, but realize there will be more latency, of course. Finally, once any method has been established send some test messages to check latency.
I know this isn't really an "answer," it's more of a stream of consciousness about this, but it wouldn't fit in a comment, and I thought it might help ;).
(Full disclosure: I've worked on Android apps that connect multiple mobile devices and multiple TVs, some over GPRS, some Wifi, some directly. I work for a company (MOVL) that makes a platform for stuff like that, it's more focused on mobile-TV-mobile, but it supports mobile-mobile also. In all it's not too hard to do yourself with regular networking, the tricky part is getting the latency down and picking the correct method for each device.)