[Daniel] was recently featured here for his work in improving the default charging mode for the Nissan Leaf electric vehicle when using the emergency/trickle charger included with the car. His work made it possible to reduce the amount of incoming power from the car, if the charging plug looked like it might not be able to handle the full 1.2 kW -3 kW that these cars draw when charging. Thanks to that work, he was able to create another upgrade for these entry-level EVs, this time addressing a major Leaf design flaw that is known as Rapidgate.
The problem that these cars have is that they still have passive thermal management for their batteries, unlike most of their competitors now. This was fine in the early ’10s when this car was one of the first all-electric cars to market, but now its design age is catching up with it. On long trips at highway speed with many rapid charges in a row the batteries can overheat easily. When this happens, the car’s charging controller will not allow the car to rapid charge any more and severely limits the charge rate even at the rapid charging stations. [Daniel] was able to tweak the charging software in order to limit the rapid charging by default, reducing it from 45 kW to 35 kW and saving a significant amount of heat during charging than is otherwise possible.
While we’d like to see Nissan actually address the design issues with their car designs while making these straighforward software changes (or at least giving Leaf owners the options that improve charging experiences) we are at least happy that there are now other electric vehicles in the market that have at least addressed the battery thermal management issues that are common with all EVs. If you do own a Leaf though, be sure to check out [Daniel]’s original project related to charging these cars.
Continue reading “Improving More Leaf Design Flaws”
It has now been a few months since the launch of the Raspberry Pi 4, and it would only be fair to describe the launch as “rocky”. While significantly faster than the Pi 3 on paper, its propensity for overheating would end up throttling down the CPU clock even with the plethora of aftermarket heatsinks and fans. The Raspberry Pi folks have been working on solutions to these teething troubles, and they have now released a bunch of updates in the form of a new bootloader, that lets the Pi 4 live up to its promise. (UPDATE: Here’s the download page and release notes)
The real meat of the update comes in an implementation of a low power mode for the USB hub. It turns out that the main source of heat on the SoC wasn’t the CPU, but the USB. Fixing the USB power consumption means that you can run the processor cool at stock speeds, and it can even be overclocked now.
There is also a new tool for updating the Pi bootloader, rpi-eeprom, that allows automatic updates for Pi 4 owners. The big change is that booting the Pi 4 over the network or an attached USB device is now a possibility, which is a must if you’re installing the Pi permanently. There are some fixes that caused problems with certain HATs, in which the Pi 4’s 3.3 V line was cycled during a reboot.
With a device as complex as a Raspberry Pi it comes as no surprise that it might ship with a few teething troubles. We’ve already covered some surrounding the USB-C power, for example. And the overheating. Where the Pi people consistently deliver though is in terms of support, both official and from the community, and we’re very pleased to see them come through in this case too.
When news broke on Meltdown and Spectre ahead of the original disclosure plan, word spread like wildfire and it was hard to separate fact from speculation. One commonly repeated claim was that the fix would slow down computers by up to 30% for some workloads. A report released by Microsoft today says that “average users” with post-2015 hardware won’t notice the difference. Without getting into specific numbers, they mention that they expect folks running pre-2015 hardware to experience noticeable slowdowns with the patches applied.
The impact from Meltdown updates are easier to categorize: they slow down the transition from an user’s application level code to system level kernel code. The good news: such transitions were already a performance killjoy before Meltdown came along. There exists an extensive collection of tools (design patterns, libraries, and APIs) to help software developers reduce the number of user-kernel transitions.
Performance sensitive code that were already written to minimize kernel transitions will suffer very little from Meltdown updates. This includes most games and mainstream applications. The updates will have a greater impact on the minority of applications that frequently jump between kernel and user worlds. Antivirus software (with their own problems) have reasons to do so, and probably will end up causing most of the slowdowns seen by normal users.
Servers, with their extensive disk and networking IO — and thus kernel usage — are going to have a much worse time, even as seen through Microsoft’s rosy spectacles. So much so that Microsoft is recommending that admins “balance the security versus performance tradeoff for your environment”.
The impact from Spectre updates are harder to pin down. Speculative execution and caching are too important in modern CPUs to “just” turn off. The fixes will be more complex and we’ll have to wait for them to roll out (bumps and all) before we have a better picture.
The effects might end up being negligible as some tech titans are currently saying, and that probably will fit your experience, unless you’re running a server farm. But even if they’re wrong, you’ll still be comfortably faster than an Intel 486 or a Raspberry Pi.
Do any of you have numbers yet?
[via The Verge]
Circuit bending is the art of creatively short circuiting low voltage hardware to create interesting and unexpected results. It’s generally applied to things like Furbys, old Casio keyboards, or early consoles to create audio and video glitches for artistic effect. It’s often practiced with a random approach, but by bringing in a little knowledge, you can get astounding results. [r20029] decided to apply her knowledge of CD players and RAM to create this glitched out Sony Discman.
Continue reading “Circuit Bent CD Player Is Glitch Heaven”
[Max] was happy to see that the PlayStation 3 Eye has support in the newer Linux kernels. Having sat in his closet for quite some time, this would give the camera another chance at usefulness. Unfortunately, the driver doesn’t include framerate selection and color correction so he set about writing a patch to control the color settings. As you can see above, his success greatly improves the image quality you get from the device.
We get the feeling that the camera peripherals for Sony’s gaming devices seem like a good idea but don’t have much staying power as a realistic gaming interface. With contributions like [Max’s], they can be re-purposed. The PS2 had its own, the EyeToy, which has long enjoyed driver support for Linux. The NUI Group does a lot of work with multi-touch and recommends the PS3 Eye for use with their projects because they’re inexpensive with high frame rates and decent picture quality.
Great work [Max]. It looks like he’s sent this patch upstream to be considered for incorporation into the kernel’s webcam module.
With all the noise about Conficker turning your computer into liquid hot magma on April 1st, there’s actually some positive news. Researchers from the HoneyNet Project have been following the worm since infections started in late 2008. They recently discovered an easy way to identify infected systems remotely. Conficker attempts to patch the MS08-067 vulnerability during infection. A flaw in the patch causes the machine to respond differently than both an unpatched system and an officially patched system. Using this knowledge, the team developed a proof of concept network scanner in python to find infected machines. You can find it in [Rich Mogull]’s initial post. [Dan Kaminisky] has packaged it as an EXE and has instructions for how to build the SVN version of Nmap, which includes the new signature. Other network scanner vendors are adding the code as well.
In conjunction with this detection code, the team has also released the whitepaper Know Your Enemy: Containing Conficker. It discusses ways to detect, contain, and remove Conficker. They’ve combined this with a tool release that covers Conficker’s dynamic domain generation among other things.
Now that the iphone-dev team has unlocked the iPhone 3G they’re moving onto jailbreaking the iPod Touch 2G. While they have a fully working jailbreak, it’s not yet in a user friendly format. [MuscleNerd] did a live video demo this afternoon to show what progress they had made. It starts with him showing the iPod on but not booting. He’s already patched the kernel, but it’s failing the signature check in iboot. He then uses the team’s recoverytool to exploit a hole in iboot and patch out the signature check. The ipod then boots normally and he shows non-App Store software like Mobile Terminal, Cydia, and an NES Emulator (which makes use of the iPod’s internal speaker).
The redsn0w jailbreak works, but it has to be applied via tether every time the iPod boots. The team won’t release anything until they’ve found a way around this problem. For more insight into the boot process, check out our coverage of their Hacking the iPhone talk at 25C3.