I was trying to update the bios of my Dell V131 laptop from A03 to A06 last weekend, and inexplicably the update window disappeared and the fan started to run very fast. For some reason I decided to shut down the laptop, which started my nightmare.
The laptop couldn't start. The power and wifi LEDs lighted up when I pressed the power button, followed by the flashing of the three accessory LEDs. Dell logo did not appear and the fan hummed momentarily. The laptop was just over one-year old and Dell's customer service wanted $59 for a one-time diagnosis fee!
I started searching online and found many helpful informations on mydigitallife.info, especially in the master thread for bios recovery procedures (http://forums.mydigitallife.info/threads/870-Bios-Recovery-Procedures). Dell's customer service told me that the bios of my laptop was made by AMI, but the methods given in the above thread did not work. So I started blindly trying all the methods listed in that thread for AWARD and Phoenix BIOS, and it was a no-go.
At that moment I started to wonder whether my motherboard was fried as well. I knew from my trials that the laptop still read from the USB key, but it didn't recognize an attached USB floppy drive. Was it able to detect the other components? I removed the rams and without them the laptop did give two short beeps. So I thought to myself that the motherboard was most likely fine.
Well, life had to go on and I did have another laptop that I could use. So I put the bricked laptop aside while thinking of other possible recovery means. I visited a Chinese website biosrepair.com which also had a lot of information. In its forum there was even an post with the extracted bios file for V131. To my surprise, the file had an BIN extension, which suggested the bios was made by AWARD from my readings, yet the methods suggested in the thread at mydigitallife.info for AWARD didn't work.
My success finally arrived after I came across a post on recovering Insyde bios (http://forums.mydigitallife.info/threads/13095-Undocumented-INSYDE-BIOS-recovery-method-Use-andy-s-tool-to-obtain-possible-names). The tool (pheonix214.exe) linked in this post showed that my bios was actually "EFI/Insyde." I couldn't help cursing the Dell customer service guy who gave me the wrong information, but later it turned out that he was actually right. Anyway, here are the procedures that worked for me:
1. Use HP USB Disk Storage Format Tool with MiniDOS files to make the USB key drive bootable.
2. Execute the Dell BIOS update application (V131A06.EXE) in a command window with /writeromfile and /writehdrfile options, respectively. Rename the generated files "V131.HDR" and "DJ5A06.ROM." These names are the ones given by pheonix214.exe when analyzing the EXE file.
3. Remove the battery and plug in the USB key drive. While holding down WINDOWS and B keys, insert the power cord. Wait for a few seconds and press the power button. Keep holding the keys until the light on the USB key drive starts to flash.
I can't remember exactly what happened after I performed these procedures, but the screen lighted up in a few seconds with the Dell logo! Then I just followed the on-screen instructions to update the bios, and my miserable four days were finally over. OK. I admit that I almost made another mistake here. After rebooting, the laptop complained about the lack of a bootable device. Did I just ruin my SSD?! I scratched my head only to realize that I didn't put it back after backing up my files!
Now to the innocent Dell guy. It turned out that the bios is indeed made by AMI, but it is a special line called Aptio, which I learned in the recovered bios.
Thursday, June 13, 2013
Wednesday, June 5, 2013
What's wrong with simulating photonic crystals with more than one unit cell?
I thought that I had a good understanding of band structures in 1D photonic crystals. Yesterday I did a simple test by comparing the band structures calculated using one unit cell with periodic boundary condition (PBC) and 3 unit cells with PBC. It turned out that the results were different! In the latter case additional bands are found, which are the images of the original ones shifted by \Delta k = 2\pi/3a and 4\pi/3a (a: the period of the lattice). So what went wrong?
I did additional tests with 2,4,5 unit cells. And the images are shifted by {\pi/a}, {\pi/2a, \pi/a, 3\pi/2a}, {2\pi/5a, 4\pi/5a, 6\pi/5a,8\pi/5a}, respectively. Considering that the distances shifted are integer times of 2\pi/(whole width of simulated structure), I gradually realized that somehow I was simulating structures with a period of the whole width, instead of the intended, smaller width of the unit cell. Why would this happen?
There are two possibilities: (1) The machine error makes each of the unit cell in the simulated structures slightly different, so the true period of the simulated structures is in fact the whole width. (2) Somehow imposing the PBC on the whole structure does not guarantee that the solutions are Bloch waves \psi(x) = exp(ikx) u_k(x), with u_k(x) = u_k(x+a).
Take the simulation with 3 unit cells for example. Indeed I found that the two shifted images of the original (correct) band structures correspond to waves with u_k(x) = u_k(x+3a) only, which confirms (2) and implies (1). Interestingly, |u_k(x)| = |u_k(x+a)| does seem to hold for these two images. Why? One can understand this observation from a physical point of view, since the system is still quasi-periodic and the probability of finding photons (electrons) at the same position in different unit cells should still be roughly the same.
A variant of what I observed is the following: Simulating the same total width but reducing the period of the structures by an integer n. One would have expected only part of the band diagrams in [-\pi/a,\pi/a], since the Brillouin zone now is [-n\pi/a,n\pi/a]. But due to the slight difference of each unit cells, one ends up with the whole folded band structures.
I did additional tests with 2,4,5 unit cells. And the images are shifted by {\pi/a}, {\pi/2a, \pi/a, 3\pi/2a}, {2\pi/5a, 4\pi/5a, 6\pi/5a,8\pi/5a}, respectively. Considering that the distances shifted are integer times of 2\pi/(whole width of simulated structure), I gradually realized that somehow I was simulating structures with a period of the whole width, instead of the intended, smaller width of the unit cell. Why would this happen?
There are two possibilities: (1) The machine error makes each of the unit cell in the simulated structures slightly different, so the true period of the simulated structures is in fact the whole width. (2) Somehow imposing the PBC on the whole structure does not guarantee that the solutions are Bloch waves \psi(x) = exp(ikx) u_k(x), with u_k(x) = u_k(x+a).
Take the simulation with 3 unit cells for example. Indeed I found that the two shifted images of the original (correct) band structures correspond to waves with u_k(x) = u_k(x+3a) only, which confirms (2) and implies (1). Interestingly, |u_k(x)| = |u_k(x+a)| does seem to hold for these two images. Why? One can understand this observation from a physical point of view, since the system is still quasi-periodic and the probability of finding photons (electrons) at the same position in different unit cells should still be roughly the same.
A variant of what I observed is the following: Simulating the same total width but reducing the period of the structures by an integer n. One would have expected only part of the band diagrams in [-\pi/a,\pi/a], since the Brillouin zone now is [-n\pi/a,n\pi/a]. But due to the slight difference of each unit cells, one ends up with the whole folded band structures.
Monday, June 3, 2013
Batch processing raw photos
A good start is to convert all the raw photos into jpeg for quick viewing:
ufraw-batch --out-type=jpeg *.*
Of course one probably want to create a new folder with the newly taken photos, so that the new jpegs do not overwrite the old ones by mistake.
ufraw-batch --out-type=jpeg *.*
Of course one probably want to create a new folder with the newly taken photos, so that the new jpegs do not overwrite the old ones by mistake.
Tuesday, May 28, 2013
"Signature field(s) detected" in Adobe reader
I found it quite annoying that a green banner showed up in Adobe reader every time I compiled a pdflatex file. To prevent this green banner from showing up, I found the instruction in this link (http://try67.blogspot.com/2013/05/acrobatreader-disable-sign-pane.html) which suggests a registry trick to set "HKLM\SOFTWARE\Policies\Adobe\(product name)\(version)\FeatureLockdown\cServices\bEnableEchoSignDetection" to 0. Unfortunately the key was not there on my laptop. I had to create the key and then the value by hand. Note that the latter should be created as a DWORD.
Thursday, May 23, 2013
Reduce size of PDF files with embedded JPEG
I found this fantastic feature of ghostscript:
gswin64c -sDEVICE=pdfwrite -dNOPAUSE -dBATCH -dPDFSETTINGS=/ebook -sOutputFile=C:newFile.pdf C:originalFile.pdf
Sources:
http://www.itechies.net/blog/archives/1764
http://www.alfredklomp.com/programming/shrinkpdf/
gswin64c -sDEVICE=pdfwrite -dNOPAUSE -dBATCH -dPDFSETTINGS=/ebook -sOutputFile=C:newFile.pdf C:originalFile.pdf
Sources:
http://www.itechies.net/blog/archives/1764
http://www.alfredklomp.com/programming/shrinkpdf/
Tuesday, April 2, 2013
Optomechanics project revisted
1. The two-time correlator of the collective polarization/inversion operator does not scale with the square of the atom numbers. It scales with N instead, since we assume there is no correlation between two different atoms.
2. When applying the Wierner-Khinckin theorem with operators, do not make the Fourier transform of an operator A^\dagger(w) =[A(-w)]^*. Keep all the operators as they are but perform the identity for their prefactors if needed.
2. When applying the Wierner-Khinckin theorem with operators, do not make the Fourier transform of an operator A^\dagger(w) =[A(-w)]^*. Keep all the operators as they are but perform the identity for their prefactors if needed.
Subscribe to:
Posts (Atom)