NeighborGeek

I recently ran into an issue installing the driver package for some new Interlink "Epad" signature pads we got in at work.  The instructions from the readme file for unattended installs matched the typical method for InstallShield packages: Run the installer with additional parameters to record the install and create a response file.  Example: "setup.exe /r /f1c:\temp\setup.iss" Copy the setup.exe and setup.iss files to the computer where the software needs to be installed.   On the target computer, run "setup.exe /s /f1 setup.iss /v/qn" In theory, this should silently run the installer, using the same responses provided when creating the response file in step 1.  In my case, this worked perfectly.  As long as I was manually running the command in step3 from an administrative command prompt.  When I tried deploying this as an application from system center, using the same command line and the same response file, the installation failed with a return

I recently modified our SCCM (MDT Integrated) OSD task sequence so that we could also use the refresh deployment type.  One of the requirements for our refresh was that the hard drives be re-partitioned and formatted, just as they would if it were a "New Computer" deployment type.  To accomplish this, I copied the "Format Disk" group from the "New Computer Only" section of the task sequence into the "Refresh Only" section.   When testing the refresh deployment, the process started off smoothly, but eventually the task sequence restarted the computer.  When the computer tried to boot back up, there was no OS on the drive. The only clue as to the cause was found in the bdd.log file:  FAILURE (5456): Unable to determine Destination Disk, Partition, and/or Drive. The task sequence attempts to back up the original drive to an image before re-installing the OS.  Since I had added the format steps under "Refresh Only" (which is abov

As an avid Geocacher , when I was thinking of what to do with my Raspberry Pi , I couldn't help but wonder what geocaching related devices I could make.  I considered building a geocache that had some kind of electronics, controlled by the Pi, but decided that powering the Pi long term would be an issue.  I searched for other ideas online, and came across a video of the Cacheberry Pi project, by Jeff Clement.  The perfect mix of geocaching, electronics, and programming, I had found my first project! The Cacheberry Pi is designed to be used in the car.  Place the small box on the dashboard, connect it to power, and while you're driving, the Raspberry Pi will search a pre-loaded database of geocaches for the nearest cache in the direction you're travelling.  This is different from most GPS receivers or applications because it searches only a narrow area ahead, and will not return caches that you've already passed by. I've spent the last few weeks getting it worki

I got a Raspberry Pi for Christmas, and have been playing with it ever since. For one project, I needed to display a couple of lines of text. I ordered a 16 Character x 2 Line LCD display based on an hd44780 compatible controller. From what I had read, I wanted one with an i2c i/o expander. By using i2c, the lcd can be controlled using just 4 GPIO pins from the Raspberry Pi instead of 8. I ended up ordering the SainSmart IIC LCD1602 Display  from amazon for just $12. When I received the LCD, I hooked it up to my Pi and tried using it with a tutorial I found on the raspberry pi blog. The tutorial I was following mentioned that some of the i2c expansion 'backpack' boards connected the i2c chip's pins to the lcd's pins in a different way than others, and that the code has to be modified to use it with other versions.  When I couldn't get it working, I looked through the 'documentation' sainsmart offered for download on their website and in the product de

Recently, I've found myself wanting to share the occasional information related to my work and hobbies. Thus, a new blog.