I get the first one, up until there is eula agreement. I can’t click
If I try and keep going I get
E: Could not get lock /var/lib/dpkg/lock - open (11: Resource temporarily unavailable)
E: Unable to lock the administration directory (/var/lib/dpkg/), is another process using it?
That worked for me. My Mac Pro (Mid 2010) is running 18.04 LTS Minimal desktop.
That can happen if your computer is running an automatic update. You can use the gui to have a look at updates. If the computer is actively installing updates wait for it to finish. If there isn’t one running, reboot.
If apt-get install still doesn’t work try
ps aux | grep apt
and look at what comes back. If there is an apt process that isn’t doing anything try killing it.
If that doesn’t fix it you need an apt guru. I’m an apt novice.
Install bzr for Windows, Python based (I could not get the GUI standalone to work properly, repeatedly threw 502 Bad Gateway errors)
I used 2.6b1 for Python 2.7 http://wiki.bazaar.canonical.com/WindowsDownloads
When that is done, open the command prompt and simply run “bzr branch lp:flashlight-firmware c:\Firmware” and it should copy the branch correctly.
So, now I've got another problem with Anduril, but this time, I'm not really sure what causes this.
In hopes that someone else also encounters this behavior so we can find a solution.
Sometimes, on rare occasions, my lights will enter an unresponsive state where the main LED keeps flashing and the button just causes the LED to light up while it is held down.
One time when it happened, I think I was pressing the button badly so it could have bounced a bit.
Sadly, I have not been able to reproduce it consistently. But it mostly happens when playing around and not properly pressing the button.
t also think, someone else reported something similar with a BLF GT Mini.
I’m not sure, but I have a guess about what might be happening. It might be rebooting over and over, rapidly. In theory, that might be possible if the button is noisy enough to take several WDT ticks to settle. This should only happen if there is a physical problem with the light though.
To work around it, I could probably make the debouncing code time out and fail after some number of cycles. This wouldn’t really make it work though, it would just prevent reboots. Actually making it work reliably probably requires soldering.
To test this, try putting it in momentary mode. Then click a bunch, and if it exits momentary without disconnecting power, that means it’s rebooting when it shouldn’t.
I’m not really sure about that either. I suspect a single event which puts the MCU in some kind of soft lock state where only a power off cycle can recover it.
One part of that idea is, that it happens on multiple lights (at least 3) and that the button is still read as a buttonpress lights up the main LED at a low level.
I have it on 15 different lights and use it a lot, but haven’t seen any of them do anything like that. Any idea how to make the issue happen on purpose?
My guess is that it could be calling the WDT interrupt handler before the previous call is done, potentially causing a stack overflow/underflow or something. And then a reboot, or something which at least looks like a reboot. But without a reliable way to make the issue happen, it’s really difficult to confirm any theories or fix it.
I’m also a little concerned that a change might appear to fix it, without actually doing so, because soldering to access the MCU, or even just a power cycle, could chase the issue away for long enough to make it seem fixed.
Yeah, but maybe it’s got something to do with my small Anduríl changes. (Reduced moonlight, disabled stepped ramping) I’ll roll that back and keep trying to reproduce it.
And to be honest, I didn’t really expect an easy or fast fix, I primarily wanted to have it written somewhere if someone else also encounters this problem.
I saw a really strange other bug last night though… on this PL47 prototype. I don’t even know which exact build is on it, and I can’t seem to make the issue happen again on purpose, but it was acting very odd on some modes. Specifically, the blink timing was way off in battcheck mode, and inconsistent… like, it acted like it was underclocked and the pauses were way too long, but after letting it cycle through like 5 times, it went back to normal. And then I’d turn it off, go back to battcheck mode, and it’d do the same weird slowness again.
Or if I went into a mode where I could click the button a lot, like momentary or lockout, clicking many times would make it reboot and return to the regular “off” state.
And other modes worked totally fine, like candle mode. Except if I clicked a bunch of times during them, it would eventually reboot.
People have reported flickering on moon mode occasionally too, and I saw the same issue on my first FW3A prototype. But on mine I fixed it by swapping a 7135 chip. And someone else reported fixing it by cleaning the battery contacts. So I don’t think that one is a firmware issue.
On my first FW3A, the MCU clock speed was all over the map, changing speed randomly and running faster than it should have been able to. PWM was going at a variable speed from about 12 kHz to 20 kHz, as if the MCU was in external clock mode or something. If I can get the PL47 to fail again, I’ll have to check if this is happening.
And I think there’s still a long-standing bug I never fixed, relating to how the voltage and temperature values are measured. It should do a measurement every four WDT ticks, but for some reason it was measuring constantly, thousands of times per second, even though I didn’t set the option for continuous mode. So I worked around it by making it only pay attention to the value every 4 ticks, and disabling the bulk of the interrupt handler the rest of the time. It works, but it really should have that continuous mode turned off.
I’m still not incredibly happy with the button debouncing code either, since it takes at least 2ms out of every 16ms WDT tick. I’d like that to be faster and more efficient, to leave more time for user code to execute and to make moon mode use less power.
I’m kinda just rambling now though, listing unsolved mysteries to look into sometime.
Okay, I had to click until my fingers were tired, but I got it to happen once. And, looking over the code, I think I might have some ideas to improve things… will have to test a few things to see what I can do.
The mode groups must be exactly 8 values per row. One of your rows has a different number of values, so everything after that won’t line up or work correctly.
