Memoirs of Fls'Zen

Saturday, October 12, 2013

Autofill Enabler

Well, I finally got tired of websites disabling autocomplete / autofill. I've created a Safari extension, Autofill Enabler that gets these things working nicely again. It can even turn password-type fields into text-type fields so Safari will pick up on the field that we expect to be text. (My retirement plan website uses a password-type field for the user name.)

Anyway, more info and download at the above link. Use the feedback form on the page to let me know what you think, or just comment here.

Labels: , , , , , , ,

Thursday, October 10, 2013

Present

One of the tools I created for use at my church is now available in the Mac App Store. Present (App Store, Website) is a little utility that makes it easy to present images and videos on a secondary display (like a projector). It works fine on computers with only a single display as well, but when presenting on an alternate display it provides a clean feed—images and videos are scaled to fit over a black background and the video controls appear in the main window so they stay off of the output display. More info about this application is contained in the above links.

Labels: , , , , ,

Monday, January 30, 2012

Reflowing MacBook Pro Graphics Chip

Today Dawn's MacBook Pro (A1212) LCD started displaying flickering red instead of "black". Basically, instead of black, it displayed a shimmering red. The black also seemed to include dark shades of gray. Not very easy to describe. Unfortunately, I didn't take any good pictures of the bad video or the subsequent repair operations. In any case, I checked an external monitor with it, and it displayed fine there, so it was unlikely that the fault was internal to the Radeon X1600 graphics chip.

The first step I took to resolve the issue was to reseat the video signal cable. I reseated both ends, but to no avail, it was still showing red instead of black.

My next step was to reflow the X1600 chip. Dawn reported that the red show up while she was watching a video, so the failure s obviously heat related. What better way is there to resolve a heat-related signal quality issue than reflow?

I warmed the chip to 200ºC for two minutes, then ramped it up to 275º over the course of the next two minutes. I held the temperature at 275º for three minutes before cooling it back down with a one and a half minute ramp, dropping a few degrees every few seconds. I was pleased to discover upon reassembly that the LCD was receiving the expected video again. Score one for reflow! In case you were curious, I didn't have an adapter for the chip size, so I just used a regular circular nozzle compensated by increasing the air temperature and duration of a normal reflow.

When searching for the problem online, I found a few of people with the same trouble. It happened to one person when they dropped their laptop. Apparently, it knocked out the connector on the logic board enough to cause the issue. Another person had it go red as described and a few months later, it went back to normal. They mentioned that theirs went wrong when it was hot.

Hopefully someone out there finds this useful someday. Please consider reflow before buying a new logic board! You can get a $100 hot air reflow station from SparkFun, so they cost much less than a new logic board, and can be used for other things as well.


PS: The problem basically looks like this, except the red "shimmers" and isn't constant like the picture implies.


Labels:

Saturday, June 18, 2011

Doppler Effect

Have you ever wondered how fast that car is driving when it speeds by your house late at night? I have. Of course, Wikipedia's Doppler Effect article isn't very helpful with this specific question. Oh well.

If we make an audio recording of the vehicle driving by, we can perform spectrum analysis on it and determine the change in frequency as it drives by. Pick a clean doppler shift from the spectrum graph and call the higher frequency "h" and the lower "l". Let's also call the speed of sound "v". Now, we can evaluate:

s = v(h-l)/(h+l), where s is the speed of the car. Wasn't that easy!?! Of course, this is for the observer remaining still.

So, how did I arrive at that? A little algebra. Let's call the frequency the car is generating (the one we picked the high and low for) "f". If we solve the doppler equation for "f", and split it into two equations, one for the high frequency and one for the low, we end up with:

f = h(v-s)/v
f = l(v+s)/v

Now, set the right hand parts equal to each other:

h(v-s)/v = l(v+s)/v

And, solve for s:

s = v(h-l)/(h+l).
QED

Now, I just have to write spectrum analyzer software to detect good doppler shifts and automatically produce the result. Maybe an iOS app?

Labels:

Sunday, February 27, 2011

New Oscilloscope

Over the last year I regularly entered the monthly scope giveaway at Tektronix's ScopeCentral. Other than the monthly drawing it is a nice place to go to for information on oscilloscope, both in regard to reference and technique. My persistence paid off—in January my name was picked! I'm now the proud owner of a brand new MSO2024. The prize is technically a TDS2002B, but they gave me a better one, probably due to the fact that some people drawn aren't able to accept sweepstakes prizes. On the other hand, it could be because the machine was built 2 years ago. Considering the big scope scale they're having now (up to 25% off), they might have upgraded me to move stock. Whatever the case, it's an awesome oscilloscope!

It only took a couple hours to get used to the interface provided by the MSO2024. It's notably different than the HP 54111D I've been using. I know, it's almost as old as me, but I got it for a couple hundred bucks. The MSO2024 is 200MHz, but the modern features it offers outweigh the slower speed. The 16 digital channels it offers make it simple to trace program execution alongside whatever I'm trying to acquire on the scope at the time. I just have to pulse some bits in my code and have them connected to digital lines in the scope.

I could wax eloquent for pages about all the niceties available in a modern piece of equipment such as the MSO2024, but it suffices to say that I'm very impressed by it. If I didn't win this one, but had the opportunity to use one for a few days, I'd probably buy one as soon as I could. Five grand is well worth what it has to offer. (I didn't mention the USB connectivity (storage, NI) and expansion options. Go find out for yourself!)

Within a few month, I expect to sell my HP 54111D on eBay. Given that I have a set of HP probes with all their accessories for it, I can probably sell it for a pretty penny. Hopefully I can sell it for enough that I can buy one of expansion cards that enable the MSO2024 to analyze and trigger on buses. I'm not sure which one to get, though. Probably not the CAN, LIN one.

And finally, for posterity:

Labels:

Wednesday, December 08, 2010

Stargate Universe

For the record, I'll only watch Stargate Universe if they start using a steadicam—for every shot. Just like I would have enjoyed the new Star Trek movie if they had not engorged it with lens flares.

Saturday, July 31, 2010

StarCraft II on Radeon X1600

So my Core Duo iMac runs StarCraft II notably smoother when I'm in Windows XP as opposed to OS X. When the graphics are set to the minimum settings, it plays fine in Windows XP, but OS X frequently slows down and tells me to close other applications (I have no other applications open). It would seem that Blizzard didn't get a chance to finish the OS X version. I would actually say that it's unplayable with the X1600 in OS X.

Labels: , , , ,

Monday, May 31, 2010

Java 6 & Multicasting (and UPnP)

I discovered today that Java 6 prefers that the MulticastSocket sending a DatagramPacket is the same instance that is receiving packets from the multicast group. This was discovered while I was working on implementing upnplib in a project. The library would intermittently discover the UPnP device. Maybe 1 in 20 attempts were successful. Wireshark showed that each packet was indeed going through and a response was being received. After much searching, trial, and error, I finally tried using a single multicast socket to send and receive the packets with the router. Success!

Seriously, even if you make a DatagramSocket and listen to the destination port of the response from the router, it will not reliably receive the packet. Maybe this behavior is part of the UDP specification, but I don't think so.

Since upnplib appears to be no longer maintained, I'm guessing this was something that was changed in 1.6 and the library was simply never updated to work with it. If you run into this problem, contact me and I'll tell you what I changed, but it might be more beneficial for you to do it on our own-simply have Discovery.java's sendSearchMessage take a parameter of DictionaryListener and in the method use the multicast socket from the listener instead of making a new one.

Labels:

Thursday, May 13, 2010

GlassFish

GlassFish errors are the best. The purpose of this post is to help others looking for reasons why they are receiving the following error while trying to deploy a Java EE 6 WAR file to Glassfish v3.

com.sun.enterprise.container.common.spi.util.InjectionException: Error creating managed object for class org.jboss.weld.servlet.WeldListener


In my case, it was because I had forgotten to configure a JavaMail Session JNDI entry on the server. It's a good thing the error message says nothing about which injection failed.

Labels:

Saturday, March 06, 2010

MacBook Pro & WPA2

Boo MacBook Pro WPA2 support! I've recently discovered a problem with the WPA2 implementation on my MacBook Pro.

The Backstory

I switched my home wireless access point (Netgear WG302) from an open network to WPA+WPA2 network (which essentially works with either WPA or WPA2 encryption). The following devices reliably connected to the network:

iMac 20" Core Duo (1st gen)
Apple iPod Touch 16GB.
Nintendo Wii

The MacBook Pro (Core 2 Duo, 17") had issues connecting. Basically, you had a 25% chance it would successfully connect to the network. If it did not connect to the network, I would have to turn the AirPort card off, then back on to get it to go (either directly or by sleeping/waking the computer). Also, it would always connect fine the first time the computer was booted up. Booting to the operating system DVD also demonstrated the same problem. We took it in to the Apple store to see if they could "fix" it. Unfortunately, they didn't have equipment to set up a WPA2 network, and of course it connected fine to their open access network–after all, it connected fine when mine was open access too. They replaced the AirPort card in it anyway. That seemed to work at first, but then it started having the connection problems again within a few days. In hindsight, it's odd that it seemed to work for a while.

The best part about the problem is that the access point station log showed the laptop authenticating and associating correctly! There must be a problem in Apple's driver. The following log was repeated throughout the station log on the access point, for each time the laptop tried getting on the network, whether it was successful or failed.

Wed Feb 17 20:06:03 2010 WLAN0: Station 00:1B:63:XX:XX:XX authenticated.
Wed Feb 17 20:06:03 2010 WLAN0: Station 00:1B:63:XX:XX:XX associated.
Wed Feb 17 20:06:06 2010 WLAN0: Station 00:1B:63:XX:XX:XX disassociated.
Wed Feb 17 20:06:06 2010 WLAN0: Station 00:1B:63:XX:XX:XX deauthenticated.

As far as the access point is concerned, absolutely nothing is wrong! But the laptop logs tell another story. Each failed attempt to connect to the network would generate an entry like the following:

Feb 17 20:07:09 MacBookPro airportd[284]: Apple80211Associate() failed -3905 (Timeout)

or

Feb 17 20:07:14 MacBookPro airportd[284]: Apple80211Associate() failed -3924 (Invalid PMK)

The Solution

There is obviously something with the laptop and WPA+WPA2 networks. Maybe I should test it with one or the other. I thought to myself, "Self, my access point can host more than one wireless network, can it not? Oh, yes it can. Why don't I switch my WPA+WPA2 network to WPA2 only and add another that is WPA only? Oh, that sounds like a good idea." So that's what I did. I discovered that the laptop has no problem at all connecting to the WPA network, and will NOT connect to the WPA2 only network-I've tried about 10 times turning the AirPort off then back on and connecting to the WPA2 network. So I guess the reason it was sporadically connecting was that it would sometimes fall back on WPA and sometimes not (which doesn't sound like good code to start with in my book).

Hopefully this helps somebody else having the same trouble. I've tried to put in pertinent information to make it come up in searches.

Since the AP's log indicated the station was doing everything fine, I've filed a bug with Apple (bug 7725286 go vote!). We'll see if it gets anywhere.

Thursday, December 24, 2009

Unlocking the Softec USBSPYDER08 BDM Programmer

This post is essentially an update to a post I made back in 2007 about the USBSPYDER08 programmer for Freescale microcontrollers.

The original problem was that I wanted to be able to program HCS08 chips other than the four the programmer supports by default. In my post, I had suggested changing the string name of the microcontroller in the DLL from one of the four that wasn't going to be used to the name of one that was going to be used. Due to the way the driver was written, this was enough to get the BDM to connect to an unsupported MCU.

A couple years later, someone commented with the necessary opcode changes to version 2.0.72 of the driver to have it indicate that it supports all available chip types. Now that CodeWarrior 6.3 is out, the DLL has been updated to version 2.0.92. So finally, we get to the intent of this update post! The opcode offsets have changed slightly. The following adjustments will make this latest version of the driver claim to support all available chip types. USE AT YOUR OWN RISK!

./prog/gdi/SofTec_BDC08.dll (version 2.0.0.92)
Change 0x74 to 0xEB at offset 0x1D18 (NoICE)
Change 0x74 to 0xEB at offset 0x437D (CodeWarrior)

Labels:

Friday, September 11, 2009

iTunes 9 - Hidden Text

I have to say, that I'm a little ticked that the zoom button makes the iTunes window an awkward size instead of switching between the mini player. I decided it might be work a look through the strings in the iTunes binary to see if there was a bit of text relating to a .plist setting that might make me happy. I didn't find what I was looking for, but I did find some unusual text.

The first text I found was "In Memory of Tom Dowdy. We miss you Tom.". I wonder if this is somehow accessible through the UI, although I doubt it since text comes from localized resources. It's probably just a const someone put in there. It is null terminated, for what it's worth.

I found one other block of text that was interesting. I have no idea what they would be using this for:
SugarlandSugar land
(,
" - ,
Version[[emph -]] version
Track[[emph -]] Track

, featuring , [[emph -]] featuring [[xtnd mtlk tobi L- 0.0 ]] [[slnc 30]]
Love your friends [[xtnd mtlk tobi L-]]
E equals M C Squared E [[xtnd mtlk tobi L-]] [[slnc 10]] [[emph -]] equals M [[emph -]] C Squared
40 ounce 40 [[emph -]] ounce
Two-PockTwo [[emph -]] Pock
Will I Am [[emph +]] Will I [[emph +]] Am
Pussycat Dolls[[emph -]] Dolls
Goo Goo Dolls[[emph -]] Goo [[emph -]] Dolls
Rag Doll[[emph -]] Doll
Love your friends Love [[xtnd mtlk tobi L-]] your friends
Festa major
ursa major

Labels:

Solaris 10u7 IPFilter return-rst

I was recently confused by the ipf implementation in Solaris 10 5/09. The confusion was in regards to the return-rst parameter of the block rule. When I first tried to use it, it didn't appear to be working. Google led me to this website, which said something about having to have a specific out rule to allow the reset packet to be sent because of the way Solaris streams worked. Unfortunately in this release, streams are no longer used (the pfil module). So that helped to mislead me.

Also of no help was the IPFilter HOWTO, which one small section that deals with return-rst doesn't do so from the perspective of blocking all incoming, then allowing only specific ports, which is my usual method.

Finally, in the end, I discovered that all I needed was the following two lines to perform the blocking I desired. Of course, if I had stuck with it instead of trying to find the solution with Google, I would have arrived at the solution much sooner. To everyone to has posted information about return-rst not working, please update your content to state that is now working in later releases.

# Block-all policy.
block in on ce0 all
block return-rst in on ce0 proto tcp all

Labels:

Saturday, June 27, 2009

Facebook

I have a facebook account now. It will probably get more updates than Twitter, but all my Twitter updates will go to facebook too.

Monday, June 15, 2009

Connection OS X (10.5) via NFS to Solaris 10

I just discovered an important fact about mounting NFS shares on OS X. (Although, it may be more of a general case.) The NFS server needs to be able to resolve the NFS client's host name. It's not actually NFS in this case, it was actually lockd not being able to resolve the client.

In my setup, my Solaris 10 box is configured as the file, DHCP, and DNS server for my home network. My local domain is "home.local". OS X correctly gets the DNS search domain from the network as I would expect it to, however, the domain "home.local" isn't assumed by the client. This is probably due to design. I suppose if I was binding to NIS it would set the domain. Anyway, I discovered that OS X was sending the FQDN "kryon.local", with ".local" being the default OS X domain. The server could not resolve this host name, since it is not valid on the network.


The OS X domain name is evidenced in the Sharing preferences panel, however it gives no way to directly change the domain. Before 10.5 the domain could be specified in /etc/hostconfig, but that configuration file is no longer in use. So, to resolve my problem with lockd not being able to resolve the client's incorrect hostname, I simply added an entry into /etc/hosts with the incorrect name pointing to the correct address.

As a matter of somewhat related interest, my OS X box is the Internet router for the network, so it also has the server in its hosts file to ensure that it will resolve the Solaris box correctly while connected to the Internet.

Wednesday, January 28, 2009

Headlight Alarm Circuit

Have you ever left you headlights on because your car either does not have an alarm or its existing alarm doesn't work? A friend of mine recently had this problem. I easily found a few existing solutions, however, I believed I could make a simpler circuit (especially that last one).

Design
The circuit design itself has a solitary goal—to sound a buzzer when the headlights are on and the car off.

My first concern was where to get power from. The most outrageous option would be to provide power via a battery pack. A more likely source would be the car's battery. However, since the circuit's goal is to sound the buzzer when the headlights are on, we might as well take the power from the headlights.

In order to sound the buzzer when the car is off, there are two things to consider. First, a signal source needs to be determined. In the case of my circuit, I chose an accessory line. The accessory line is be grounded when the power is cut (car off) and is otherwise on, so we'll have an easy comparison. Second is the problem of determining when the accessory line is low. I first considered a comparator, but I soon realized that all I would need is a PNP transistor to switch the buzzer on and off. With this component, the headlight line is connected to the emitter, the base is connected to the accessory line, and the collector is connected the buzzer. Therefore, when the headlights are on and the accessories are off, the emitter conducts to the collector and the buzzer sounds. Also with this arrangement, if the headlights are off or the accessories and headlights are on, nothing happens. Additionally a resistor is connected between the accessory line and the transistor to limit the current flowing to ground when the buzzer is sounding.

Circuit
Here's the circuit diagram from Multisim:

As you can see in the diagram, the headlights are on and the accessories are off. There is a little less than battery voltage flowing through the buzzer and ~1mA leaking to ground through the transistor. The transistor in the design was chosen specifically since it was rated for much higher voltage than what the circuit will ever see. It should be possible to use a general purpose transistor, but I did not want to bother with it.

After proving the circuit design in Multisim, I moved on to prototyping. This circuit can be built, complete with enclosure, from the following Mouser components (1 each):
660-CF1/2CT52R103J - 10kΩ Resistor
546-1593KBK - Enclosure
854-PR1593K - Enclosure Circuit Board
254-35C5-ROX - Buzzer
511-D45H11 - Transistor (This component differs slightly from the Multisim diagram—it is rated for higher voltage, and it is cheaper.)

The buzzer could easily be substituted for something else. I chose this one since it was nice and loud. You may want one a little more . . . subtle.

Application
The prototype was constructed and tested with both 3V and 12V. Make note that if the accessory line is floating, the alarm won't sound, it needs to be tied to ground. I connected 10" lead wires to each of the headlight, accessory, and ground lines of the circuit. This length of wire seems to be appropriate for installation to a car's fuse box.

I then installed and tested the circuit in a car, a Honda. The circuit enclosure fit nicely under the dash near the fuse box. The wires fit snugly into the fuse socket, with the fuse being re-installed after the wire was inserted. In this application, I connected the headlight line to the right headlight low-beam fuse, the accessory line was connected to the turn signal fuse, and ground was connected to the chassis.

If you are installing the circuit into a car, I found that it was easiest to use my multimeter to check the voltage of the fuses before I attempted to install the wires into the fuse sockets. In the Honda, the car's circuits were switched before the fuse, so the turn signal fuse was tied to only ground when the car was off and energized otherwise, making it a good spot to connect to. Your car may differ. If need be you could always tap an existing wire.

Have fun!

Labels:

Friday, January 23, 2009

Twitter

I have a Twitter account now. I update it from time to time.
http://www.twitter.com/flszen

Labels:

h3mm.com

I've finally decided to drop h3mm.com. Its contents are now available at http://www.hoodcomputing.com/h3mm. We'll see what crops up there once it has been released back into the available names pool. (90 days, IIRC).

Labels: , ,

Friday, October 17, 2008

Oscilloscopes, AC Circuits, and GFCI (GFI) Circuit Breakers

A word to the wise—oscilloscopes generally connect your probe grounds to earth ground via the outlet they're plugged in to. That being said, if you plug your 'scope into a GFCI outlet and connect the probe to an AC circuit, the breaker will immediately trip. I get to run an extension cord to another room now.

Labels: ,

Merging Architecture Trees for Building Universal Binaries on OS X

While building a universal binary of GnuPG, I have come across the problem of merging two architectures. Due to design, GnuPG is not able to build binaries with multiple architectures. It is easy to build GnuPG for just i386 or just ppc, however, the trick is lipoing them both together without too much trouble. The following script assumes that an environment variable BUILD_PATH has been set. This path should be the root for your architectures (this should be the output specified by --prefix during configure), in this case it contains the "i386" and "ppc" directories. (Each architecture contains lib, bin, etc.)

Here's the script to merge these architectures together:

cp -R $BUILD_PATH/i386 $BUILD_PATH/universal
cd $BUILD_PATH/universal
find . -perm -0001 -type f -exec lipo -create $BUILD_PATH/i386/{} $BUILD_PATH/ppc/{} -output $BUILD_PATH/universal/{} \;

The script starts by creating the "universal" directory from a copy of "i386", so the entire tree is present. Then, find is used in conjunction with lipo to merge the architectures together into the universal directory.

Pretty spiffy, eh?

UPDATE: GnuPG indeed builds universal, I just neglected to read the readme. See the first comment.

Labels: , ,