Force DPI Scaling on Windows posted on 12 May 2014
Windows exposes a number of ways to disable DPI scaling, but no way to forcefully enable it. This is a problem when apps tell windows they support high DPI but then go on to render at exactly the same size - making for unreadable text and unclickable buttons.
I tried editing the application's manifest to set DpiAware to false, but that had no effect. Rather than switch my laptop's resolution every time I needed to use Cadence OrCAD, I did a little debugging with Ollydbg. Turns out, at some point, SetProcessDPIAware is called. I already had an idea on how to solve it, so I didn't stick around to find the offending library (though I suspect it was being set by gdiplus).
I probably could have patched OrCAD (less so gdiplus), but there is a far more flexible solution. All we need to do is hook the SetProcessDPIAware function as a program is starting, and we gain the ability to block the function call, leaving the target application no way to tell windows not to scale it.
I used the minhook library to build a DLL that will do just that. When it is loaded by an application, the code replaces SetProcessDPIAware with an implementation that does nothing.
The DLL must be present right as the app is initializing, else it won't be able to block the function call. Rather than inject the DLL per se, I just used CFF Explorer to add it to the misbehaving application's import table. This causes it to be loaded as the application is starting up.
To maintain Windows 8 compatibility, I didn't hook SetProcessDpiAwareness.
Using the tool
To use DPIMangler yourself, get the binaries here. Next, get CFF Explorer or a similar tool. Open the target executable in CFF Explorer, go to the Import Adder, and click Add. Select the appropriate DPIMangler binary, then choose any exported function and click Import By Name. Next, click Rebuild Import Table and save the application. That's it! Next time you run the program, calls to SetProcessDPIAware will be blocked.
If this isn't working for you, make sure the application doesn't declare DpiAware in its manifest. Additionally, it's possible the program is calling SetProcessDPIAwareness, which I haven't hooked here. If that's the case, feel free to contact me on Twitter, and I'll try to get a new release out.
Before; OrCAD on high DPI is practically unusable with no scaling
After; much more usable with forced scaling
Fixing MarkdownPad live preview on Lenovo Yoga 2 Pro (and other high DPI screens) posted on 11 May 2014
Here's a quick and dirty font size fix I applied to the Markdownpad-github.css file. I just switched all font-size items to use
px. It probably formats some things totally incorrectly, but it's good enough for me for the moment.
To use, open Tools -> Options -> Stylesheets and replace the contents of
markdownpad-github.css(or create a new stylesheet)
Can letters in the kitchen posted on 01 Apr 2014
Earlier today, my roommate texted me a picture of a sign that her work was going to throw out. When she got home, I convinced her that we should go and retrieve it!
First, we removed the letter faces.
With the faces free, we removed the screws that were holding the letters to their bulky mounting rail.
Letters free from the rail.
We were surprised to find that the letters were lit with neon. We removed the bulbs and placed them aside.
After returning home, we cleaned the letters and lined them up to prepare for lighting.
We then stuffed the letters with string lights.
Letters in place above our kitchen cabinets. We were lucky they fit!
This was a fun diversion for today, but we'll probably have to redo them with LEDs if we decide to keep them around for long.
If you like this spontaneous bit of work, you should see what my roommate does over at Electric Trees!
Hotend for Metal FDM, Part 2 posted on 09 Mar 2014
What if you could do something like SLS but with a hot tip? Take a 1200C tip and move around the work surface melting tiny metal beads. Alternatively, use a torch.
Or perhaps metal beads could be extruded with FDM and fused later with a laser or in a kiln.
Hotend for Metal FDM posted on 08 Mar 2014
Hotend & nozzle metal
- Able to withstand 700-1100C
- Not going to interact badly with molten aluminum, zinc, or copper
- Hard enough that a 0.5mm hole is still 0.5mm after extruding a bunch of molten metal through it
- Thermal expansion from worst metal shouldn't cause a jam
- worst case expansion * worst case tolerance + magic extra tolerance
- Minimum amount of metal is molten at any given moment.
- Metal should extrude with minimum turbulence
- Nozzle 10x longer than diameter of extrusion?
- Thermal transfer up filament should be minimized
Heat break design
- Heat leakage into the coldend should be minimized
- Filament must be supported enough that it won't bend under the pressure of extrusion
- Ceramic sheath? Stainless tube?
- If the heat break can't withstand the full pressure of extrusion, the hotend will need to be anchored to the coldend externally
- Filament should not be marred (eg, by a sharp gear) to minimize the risk of jamming in the cold end or damaging any components
- Filament must be pushed with enough force to extrude
- Need to find data on how soft metals are at various temps
- Find filament of multiple metals in the same diameter & tolerance (at/near extrusion temperature after thermal expansion)
In my mind, this hotend looks a lot like an E3d hotend made from steel or titanium, but with a directly mounted extruder and a lot more cooling (possibly water cooled?). It would be heated with a high temp heater cartridge (maybe?) and have a much heftier heat break, possibly supplemented by external thin steel wires.
- How will molten aluminum interact with titanium? Would it be an appropriate nozzle material? How about steel?
- Any idea how to figure out a graph of extrusion force vs temperature for aluminum (w/ a given diameter nozzle)?
- How horrible is it going to be to deal with thermal expansion across this entire design? If more than one metal is used, everything needs to be matched up for expansion, yes?
- What sort of surface will be able to handle the thermal stress of being printed onto?
- How can part adhesion to the print bed be maintained with high levels of material shrinkage?
- Ceramics are exciting and could open a lot of opportunities, but I have no idea where to start with designing and specifying ceramic parts.
- I know there are some additional issues I haven't mentioned here and certainly some I haven't even considered. Feel free to chime in an any of them!
Kinivo Bluetooth module posted on 28 Feb 2014
- Held together with four T6 screws
- Contains a KMBT007A bluetooth module
- Runs at 3.3v
Audio wire colors: Left: blue, Gnd: red/copper twist, Right: green
Power wire colors: Positive: red, Negative: copper (both are in thin plastic sheaths)
All switches are NO with 10k pullups to 3.3v
Has exposed SPI and UART ports
Been running for almost two years on the same battery! Surprisingly, the plastic is visibly worn where it's been rubbing under my radio.
- 8 buttons
- Powered by a coin cell
- uC is an rfPIC
- Receiver uses a PIC18F2520
I used a custom firmware to toggle test points on the receiver when buttons are pressed. I preserved all radio communications so I can still control the radio station or CD track (as if I'd ever want to).
Building Mono on a BeagleBone Black (Hard Float) posted on 03 Jan 2014
I performed this on Ubuntu Saucy 13.10 from ARMhf (running from an 8Gb SD card)
- Launch a terminal window/ssh into your BBB
- sudo apt-get update
- sudo apt-get install mono-complete git automake libtool
- Wait a long time (hours)
- git clone git://github.com/mono/mono.git
- cd mono
- git submodule init
- git submodule update
./autogen.sh --prefix=/usr/local --enable-nls=no --with-sgen=yes --with-xen-opt=no --with-ikvm-native=no
- Wait a long time (hours again)
- Ignore the errors and hope they don’t mean anything
- sudo make install
- Wait some more
- Ignore the errors and hope they don’t mean anything
RAZR HD Maxx Teardown posted on 10 Oct 2013
A friend accidentally ran over his RAZR HD Maxx, so I rescued the motherboard and tore it down!
I wasn't too kind when removing the RF shielding, so the copper is torn off in a few places.
View image for full resolution.
Why the PhoneBloks phone will never happen posted on 13 Sep 2013
It's a physics issue. Signals in modern devices are extremely high speed; the easiest and cheapest way to combat this is to bring components closer together. For example, the wireless radios, RAM, and processor in all modern phones exist as one chip. They essentially put the CPU and wireless magic on the same silicon die (or on a separate die in the same package) and pop a RAM chip on top ("Package on Package").
It's a communication issue. All of the ICs in a phone don't communicate over a single bus - almost every one ties directly into specific processor pins. This would restrict block size and placement.
If we aim a little lower and try for a modular design, the interconnects needed to ensure signal integrity at high speed are still very expensive. This project would require serious economies of scale to succeed. Each high speed component - CPU, RAM, storage, modem - would need an expensive socket.
Technically, the storage could be put on a socket pretty easily. It's not fast enough to warrant a very expensive socket, but would still add ~$2-5 to the final design. (Keep in mind, that means the consumer would be paying $4-20 extra, just to have the option to upgrade the storage.)
It's an interoperability issue. Going a little further, even if the device could be built in some fashion - there isn't much standardization in this area. I've spent days wrestling with a display peripheral on a processor to get it to interface with a specific display or video input IC - and that's with the benefit of thousands of pages of documentation, a field application engineer on call, and a ~$15000 oscilloscope. The amount of effort in testing and debugging that would be required to ensure the compatibility of each component would be absolutely enormous.
All of that said, I think the modular idea is excellent and could be done right - maybe not with blocks as described and - optimally - not with electrical signals. I could see it happening with optical interconnects, but we're a few years out from that. On chip optical interconnects are still in research, but there's a lot of money being put into them. Intel has demonstrated some very impressive optical tech that should come to market within the next five years. Eventually, we may be able to tie ICs together through optical traces for extreme high speed communication.
Finally, the stated motivation for this design is to reduce electrical waste. The best way to do that in the short term is to ensure devices are more repairable. An emphasis on user-serviceable batteries would make a significant difference in how long our devices remain useful without adversely impacting their cost or limiting their design.
It's worth noting that the smartphone market is starting to mature. Phones aren't improving by the massive leaps and bounds that they were. The technological differences are trivial - few people notice the difference between a 1GHz and 1.2GHz processor or 1GB and 2GB of RAM. Now, the main thing that separates generations of phones are millimeters of extra display space, grams of saved space, and milliamphours of extra battery life.
One major driver of phone sales right now is software. This is where the problem lies, not in hardware. Users need the right to unlock our phone modems and bootloaders. Unlocking the modems to allow use on different carriers would give used phones a wider market. Unlocking bootloaders would let users completely replace the original software, adding improvements and features to otherwise uninteresting devices.
We definitely have an e-waste problem - and I give this person credit for thinking outside the box - but this isn't the solution we need.
One source, because I'm lazy: IFIXIT
Abandoning the EFM32G210F128 Breakout posted on 28 Aug 2013
I'm officially abandoning my Energy Micro EFM32G210F128 breakout. The design files are all on Upverter and are released into the public domain.
Energy Micro has microprocessors with native USB, so there's no reason for me to continue working on a design that needs an expensive USB-UART converter. This is a straightforward case of subpar research and some flawed reasoning coming to bite after the design work has been completed.