I'm developing an Android application to control my quadcopter from the smartphone: I have a periodic process that sends the data acquired from the touchscreen.
The data in then received from a microcontroller, that generates a PWM command to 4 DC motors, obtaining the duty cycle values with a control loop that exploits the received commands.
Can someone suggest a precise criterion to choose the period of the process on the smartphone? Or it is possibile only a "trial and error" approach, checking the reactivity of the system?
EDIT: I have successfully implemented it just setting the frequency of the smartphone task as 2*control_loop_frequency
If you knew or could measure the impulse response of the system it would be possible to determine an appropriate control loop rate; however you do not have that data and it will be confounded in any case by external factors such as wind speed and direction. Determining the rate empirically will be faster than determining the precise characteristics.
If the control is open-loop, then probably you have to ask yourself how far off the desired course can you allow the vehicle to get before a correction is applied. That will depend on the vehicles maximum speed (in any direction).
In the end however Android is not a real-time operating system, so there are no guarantees that any particular periodic update will be performed precisely; its always going to be somewhat non deterministic. At a guess I would imagine that such a system might manage 10Hz update reasonably reliably and that would probably be sufficient for adequate control and responsiveness - if the only feedback is via the human controller's hand-eye coordination, that is perhaps the limiting factor in the system response.
Related
I made a battery bypass to a LG G4 mobile phone, to measure the direct energy consumption with a power monitor. However, 70-80 seconds into the OS boot-up, the system shuts-down with a message 'Invalid battery'.
I've tried several solutions, such as: setting a precise output voltage as measured on the battery; cleaning the 4 battery pins; tighter pin connection, but no luck.
The only hope I could find is within the android docs - Power/Component Power section:
Fake batteries can provide signals on thermistor or fuel gauge pins that mimic temperature and state of charge readings for a normal system, and may also provide convenient leads for connecting to external power supplies. Alternatively, you can modify the system to ignore the invalid data from the missing battery.
And here is my question: How do I modify the system to ignore the invalid data from the missing battery?
There isn't a reference to any article or clear explanation on how to do this. Could anyone point me in the right direction, please? Am I missing something really straightforward?
I've seen a lot of discussions on battery for altbeacon, specially if beacons are inside a region for a long time. This post was actually very clarifying.
I am currently working in a solution that requires a good sensibility (which I define as being a small detection time for a new beacon in a region).
As some beacons may be anonymous (which I define as presenting unexpected MAC addresses but share a same matching byte sequence) to the scanner in this particular solution, I would like to achieve good sensibility to new beacons but also a balanced battery impact to the user.
What concerns me is if a first beacon is found and the region triggers based on the matching sequence, how could I get a notification once another beacon approaches (or leaves) ?
A guess I was going to try was to keep monitoring for a generic matching sequence and once a beacon is found for that general sequence, range it to get its address and them create a particular region for the mac I've taken. The only problem with this approach was how could I prevent the first beacon to keep triggering the generic region?
And just out of curiosity. Is the ScanFilter class related to those hardware filters introduced on android 5?
Thank you,
If you need to quickly find new beacons with the same byte patterns as ones that already exist in the vicinity, you really have no choice but to keep ranging.
In such a situation, there is no distinction between ranging and monitoring in terms of battery consumption. Both will require constant Bluetooth scans and decoding of all beacons in the vicinity. Scan filters (yes, the hardware filters introduced in Android 5,) will not help because you expect the byte patterns to be the same. There is no such thing as a packet "does not match" scan filter that could be used to find only new MAC addresses.
You may need to accept the battery drain of constant scans and just try to limit how long they last, if your use case allows. Short scans of 30 minutes or less might be acceptable.
You could possibly save some battery by writing your own BLE scanning parsing code tailored to this use case. You could first look for unique MAC addresses, and only do further processing and parsing if the MAC address has never been seen before. This will not reduce battery usage from the constant scan, but it would cut down on battery usage from CPU expended on parsing packets. This might save 10-30% depending on the number of beacons in the vicinity.
Bottom line: you are right to be concerned about battery usage with this use case.
I'm a beginner in this field. I have developed an android app through which I can control the LED's connected to the GPIO pins of ESP Wi-Fi module. That app is connected to Firebase to save the status of the buttons. Everything works fine.
Now I want to implement the followings:
I want, if I manually switch off the LED by removing the GPIO pin of respective LED, that status "LED OFF" should be updated on my app.
I want to add Fan speed controller
For first bullet point, should I use firebase too?
Please suggest the tutorial and ways I can achieve both.
Number 1:
Reading digital output states on an ESP8266
You cannot read and write the same pin without blinking the light as you alter pinMode on the fly. The easiest way is to connect another GPIO as the cathode of the LED, and set that pin's pinMode to INPUT. you can then digitalRead that input to determine if the LED is present and on (1) or not (0).
That only works well on red low-power LEDs though, since the GPIOs only handle 12ma officially. You'll likely want to use something like NPN transistors to deliver VCC to them, in which case you can connect the input pin to the LED anode via a 5-10k resistor, and the LED cathode to GND.
In terms of pushing that status to the update, you can poll every few hundred ms, checking that each read value one is the same as the last, and sending the change off to sparkfun when found. Store the state in a global and compare to the read.
You can also use an interrupt instead of polling. These are more performant and complicated, so for very low-frequency events like LED status, polling suffices and is arguably easier to code from scratch. Do look into interrupts eventually though, they are powerful on single-threaded devices.
Number 2:
Controlling fan speed with an ESP8266
You need a PWM circuit to control a DC motor's fan speed. There's many relatively simple circuits using mosfets to connect and disconnect the ground of the fan very quickly, thus averaging its used power as a ratio of maximum power. The ratio is set using analogWrite with a pin # and a int from 0 to 1024.
Note that your fan probably won't spin if the written value is less than 350; there's not enough voltage at those low values. Also, i'd recommended boosting the PWM frequency to super-sonic levels using analogWriteFreq(16000); in setup() to avoid fan noise. If you can get a 12v DC 4-wire PC cooling fan, you can actually hook the pwm input line to the control GPIO and not have to wire any circuits.
If your fan runs on AC, it's a lot more complicated and dangerous. The simplest circuits use an IGBT transistor to achieve "PWM" on an AC signal, but triacs+diacs, and random-cross solid state relays work well if you manage your own cross timing. Make sure you handle motor impedance as well. Complicated? you bet.
I have found that it's easer and cheaper to modify an existing and cheap fan controller like this one, de-soldering the large potentiometer and replacing with an LDR. The pot's used as a variable resistor, not a voltage divider, so it's easy to mimic. You can then tape an LED to the LDR, hook the LED to a GPIO output, and then use analogWrite() to control the AC output. Experiment with LED resistor values to maximize precision and linearity, though for a fan, even just three usable levels would be an improvement. The opto-isolation from the ESP to main is a nice feature of this cheap method.
If you have an existing commercial multi-speed fan with a few levels, like a ceiling fan or a box fan, you can replace the fan's switch/knob with relays to mimic a human selecting a switch position. You have to reverse-engineer which wires are "hot or not" under the different selections. It's mains AC, so do be careful doing that...
People! I thought to include it in original question but didn't.
WHILE VOTING, YOU ARE ALLOWED TO COMMENT WHY DID YOU VOTE?
Please use it to enable learners get theirs things done and convey their thoughts/issues to others better way. Not everyone knows what you think. Thanks
In Short:
I need to synchronize clocks of two Android Phones (placed close to each other OR not; both cases) with each other AND with up to an accuracy of a few milliseconds (10, 20 ms max).
Either sync the clocks
Or get an offset of one from the other
What I am Doing:
I have a developed app that I am using to measure different GSM network statistics. I am using telephony manager to get three states (OFF-HOOK, IDLE, RINGING). Phone A calls phone B. Both phones are running an app that is saving the time-stamps with regards to the states mentioned above. After making many calls I export the time-stamps in a data file and analyze them to get different network stats.
What is my Issue:
I have to cross-match the time-stamps to get stats. Now the problem is that if the phones' clocks are not synced then I will not be able to get exact stats (e.g. how much time it takes to get phone B in ringing state after phone A initiates a call?).
What I have Tried: So far I have tried to sync clocks with NTP, GPS or atomic clock. I have used ClockSync (Android app) to get offset of both phone clocks from atomic clock. The issue is that this offset depends on RTT of network packets from my phone to server. I gives my difference of up to 100 ms when I check offset two times (tap refresh two times consecutively). The offsets at both phones can lead to error of up to 200 ms which is unacceptable for me.
All other syncing apps/methods have same issue.
Possible way forward: (What I think). I may develop an app that
takes the time-stamp at phone A
transfers that to phone B via Bluetooth or WiFi (connected to same router),
B then compares that time-stamp with its own clock, calculates offset,
And I run my original app, run experiments and,
Use the offset to correct time-stamps before processing data
Your Comments/Suggestions: How to do it? And comments on the method described in last part..
I am writing my Master thesis atm and analyzed about 400 different GPS-Trajectories (paths consisting of a list of longitude/latitude points and an according timestamp) recorded with the MediaQ-App (probably not important) for Android (about 310 trajectories) and iOS (about 90).
When analyzing the time intervals between the timestamps, I was expecting the inaccuracies around the 1 second frequency, in which the timestamps were supposed to be recorded, since neither Android or iOs are real-Time-OS from apps point of view. Still, why are there, what appears to be local peaks in about 200ms steps? Be nice, I do not know a lot about mobile operating systems :-)
(x-axis: seconds, y-axis: the relative probability that a timestamp will be recorded at this point in time. Ignore the exact values of the y-axis...)
The usual behavior is that an App takes the timestamp direct from the location delivered by the system. Most probably this is the case in that App, otheriwse this would be a heavy programming bug. (The delay between nominal GPS time and receiving system time of about 200ms is plausible, I saw that in my app, and in ios Map app, which makes a correction in their map api to extrapolate the location into the future, to try to compensate that delay)
Under android (and ios) it is import to know whether the location are determined exclusively by GPS. On both plattforms (ios, android) an App can set whether GPS only or combined GPS + WLAN + Cell Locationing is used.
For high quality recording is is highly recomended to use GPS only.
A GPS chip once having a location usually outputs a location with a timestamp exactly at 000. Exception can happen before the location is valid.
Under ios if the location was obtained by GPS the millisecond are always 0.
I have no experience with android, but usually the GPS chip itself sets the value to millis = 0. (However, some android phones are known to use a crippled cheap GPS chips, that are not able to get an intial position without the help of an internet conection)
It is possible to determine whether the location was obtained by GPS by looking at the course (or called heading) and speed value, which are invalid for non GPS locations (cell Tower locationing)
To know whether this time variations come from the Application (not using the GPS only mode) or if it is caused by Android, you can test that with another application on the same phone. (E.g Motion-X GPS) (Or by comparing both apps on another android phone)