I can't figure out how to set up tlp battery threshold, I don't understand their website instructions.
Tlp says my laptop supports battery threshold, If anyone can guide me how to set it up thanks.
Also tlp seem to function directly on terminal.
Related
I am trying to set up my Intel Nuc as the Onboard Computer for using DJI OSDK on my Matrice 100. I am looking for suggestions to find a way to power the Nuc from the Matrice.
In the beginning, I connected a DC-DC voltage regulator to one of the XT30 ports to get 19V and power the Nuc. It worked okay for a while and I was able to fly the Matrice outside using OSDK. But it has suddenly stopped working now. When the Nuc tries to boot into Ubuntu, it shuts down abruptly.
In short, use separate power source for Onboard PC and sensors.
Typically sensors and PC such as IR or LIDAR or NUC draws power heavily. If the current changes, the sensor value will change (which is bad). The PC will need a safe margin of voltage e.g 16 to 21. A sudden gust wind can cause the drone to output thrust power at a maximum which might lower the voltage for couple secs. In this case, PC might gets shut down or provide wrong calculation output ( e.g false odometry output)
So adding a stand-alone small size 5 cell battery should give you stable performance. Here I cant promote a specific commercial item. For my project, I bought the battery from Hobbyking to do the job for onboard PC and Kinects. You can search there for the battery that suits your need
PS. don't get DC to DC converter, typically it is very low efficiency and prone to power disturbance. I use typically raw battery and BEC(for 5V or 12V Sensor such as IR sensor and Hokuyo LIDAR)
I am attempting to create a kext which will allow me to lower the minimum display brightness. Which drivers would be relevant to this? Would this be an I/O Kit driver?
This pertains to the internal display on my MacBook Pro 14,1 running macOS 10.14.4 using the integrated Intel Iris Plus Graphics 640.
The driver that controls is the "AppleBacklight.kext" kernel extension.
In general: Display backlight is usually (and this is the case on the MacBook Pro) controlled by a PWM (pulse-width modulation) signal from 0% to 100%. A controller - which could be the GPU or a dedicated IC - sends out the PWM signal according to the brightness level chosen by the user. In some cases this factors in an ambient light sensor.
The controller operates by dividing up the usuable PWM range in a number of settings (for example 20 seperate steps). The whole PWM range is usually not available, as backlights have different minimum and maximum allowable PWM ranges. If you go outside that range, you're violating the specs and may cause damage to the display.
On modern Intel computers the PWM range is stored in the SSDT (system service descriptor table) accessible through the ACPI (Advanced Configuration and Power Interface). These tables are usually dumped into .aml/.dsl files. You'll be looking at for example the LMIN and LMAX parameters (LMIN/LMAX = Backlight PWM Min/Max).
You could also consider replacing the default backlight kernel extension with for example this:
https://github.com/RehabMan/OS-X-Intel-Backlight
It is only meant to be used with Hackintoshes, but it controls the same Intel integrated GPU as you have.
Here's a different kernel extension that uses the ACPI method described above to control the backlight:
https://github.com/RehabMan/OS-X-ACPI-Backlight
Again, it is intended for Hackintoshes.
If you want to try dumping and patching your SSDT manually, you can take a look at this guide:
https://www.tonymacx86.com/threads/guide-patching-laptop-dsdt-ssdts.152573/
Again note that it is intended to be used with Hackintoshes.
In general I wouldn't recommend trying to change the minimum display brightness on original Apple hardware. You run the risk of damaging circuits - but most likely you'll just experience a black screen when you lower the brightness below the minimum.
We are working on a project right now, where we're using coin cell batteries (3 x CR2032). The device is connected to the application via bluetooth and we're showing battery percentage on the app (Reading by turning ADC on during reading and turning ADC off after reading is taken. This saves battery life).
My question is how do we display the percentage on the application throughout the life of the battery.
Eg. 3.2 V - 100%
3.0 V - 80%
2.8 V - 60%
These values are exaggerated just to show why i'm trying to guess here.
coin cell batteries discharge quickly from 3.2 to 2.9V and then they discharge very slowly. We want to show the readings, considering the nature of a coin cell battery. Eg. From 3.2V - 2.9V, we can show a reduction of 4-5% only and then do the rest of the calculations according to a slow rate.
Please suggest calculations which we can implement in our code.
We are currently following this but it doesn't make sense to me.
https://devzone.nordicsemi.com/question/37130/battery-level-discharge-curve-how-can-i-read/
#2.9 V if we show less than half of the battery on the app, then the user would be confused as to why the battery drained quickly even when the user hardly used it.
If the device consumes the same current all the time, you could build self discharge diagram (in your link the discharge diagram is build for a specific load - resistor 15k).
After that, you could use polynoms to get function which provides the dependence of battery capacity from time. Use the inverse funсtion to predict how much time is left to work.
Commonly, you could collect some information about battery life, If your device has remote server, you could send statistics on it and analyze received data in future.
I'm working on a project that involves building a big 'light wall' (h*w = 3,5 * 7 m). The wall is covered in semi-transparent fabric, and behind this is gonna be mounted strips of addressable RGB-LED's. The strips are gonna be mounted vertically and function as a big display for showing primitive graphics and visuals. I plan to control the diodes using an arduino. The reason for the choice of the arduino as controller is that is must be easily programmable, (relatively) cheap, and should work as a part of different interaction design setups.
Current version of the light wall (without addressable LED's)
My ultimate concern is now this:
How many individual diodes can I control before the arduino becomes inadequate?
As I see it this comes down to two points:
When does the update rate of the diodes become too slow? I want to update the picture at a rate of minimum 10 Hz.
When will the arduino run out of memory? The state of all the diodes on the light wall should be stored for the next frame. At some point then the memory (256 KB for the arduino MEGA 2560) will run out. How many diodes can I control before this happens?
I realize that both questions are related to how the arduino is programmed. I am very open to any tips regarding speed optimization and memory conservation.
Thanks in advance!
Apple's I/O kit (via IODisplaySetFloatParameter) allows you to set the display brightness within a given range. However, I remember my prior laptops being significantly dimmer at the lowest setting.
Various screen dimming utilities alter the Gamma settings, and this brings the display down even further. However, the qualitative difference in the change and how such these utilities use RGB tables leads me to suspect that the Gamma setting ONLY alters the color tables, not the LED backlight.
Does anyone know of private API's (or how I would find them) that let me set the display to something lower than what IODisplaySetFloatParameter allows?
The hardware for this kind of thing tends to use PWM (Pulse Width Modulation), since LEDs are not inherently dimmable; that is, the hardware will switch the LEDs off and on very quickly, ensuring that when it is set to maximum brightness the LEDs are on 100% of the time, while at minimum brightness the LED will actually be switched off for most of each cycle.
That leads to the following observation: there is no particular reason you can't implement your own PWM in software, toggling the backlight on and off and controlling the proportion of the time it spends in each state. The downside is that you want to do this toggling fast to avoid it looking like flickering, and that will burn some CPU. You might want to investigate whether it's best to let the hardware PWM run as well as yours (since then yours can run somewhat slower), by setting the display brightness at a value other than 100% for the “on” part of the cycle.
Anyway, just an idea.