I bought the original Nexus 7 the day it came out in 2012 and since it has had an annoying screen flicker issue which is most visible on white backgrounds like surfing the web. I have put up with this for over a year but finally got annoyed enough to see if there was a way to fix it. I searched the web but did not find a solution to this issue. I tried a bunch of stuff like tweaking Wi-Fi settings, setting the backlight to a constant brightness, and using root only backlight control program all will no luck. It seems to be an EMI issue that stems from the Wi-Fi connection, if I turn off Wi-Fi the issue resolved itself but that makes the tablet pretty useless for my needs. So I popped the back cover to see if I could shield the board from the Wi-Fi antenna. I have been able to resolve the issue and here is a basic rundown of how to fix the issue.
I consolidated with my original website with my blog into a single wordpress site. If you are redirected here from a old link please refresh your browser, I have made permanent redirects on all my project links so the old links should still work.
I have created code and an interface that allows an Atmel AVR or Nintendo DS to control a DSLR camera through a FTDI Vinculum USB host controller. The code implements a very basic subset of the Picture Transfer Protocol (PTP) / Picture Transfer Protocol (MTP) protocols which are used on DSLRs and many point and shoot cameras. This interface allows an Atmel AVR or Nintendo DS to control a modern USB camera such as a DSLR. I wanted to do this to create a standalone HDR controller without the need to haul around a laptop. For more background information on why I decided to do this and the CPLD interface I created to allow a Nintendo DS to talk to the FTDI Vinculum please read my previous blog post. I got the Nintendo DS / AVR USB controller working in June and have not changed the code since August so it is long overdue for me to post the code and schematic.
The code was written and developed on an Atmel AVR (non-Arduino) and ported over to the DS. It is much easier to develop code on an AVR then on the DS which you have to constantly swap SD cards on every recompile. I wrote the code to be as platform independent as I could so it can be moved to whichever device needed. I do not think it would be too hard to add to the Open Camera Control Project (OCC) (talked about in last blog post) code, you will need to call a few functions to init the Vinculum and to take picture, change exposure time, etc.
In May of this year (2010) I wanted to create a USB HDR camera controller allowing me to shoot more then three bracketed shots quickly and in one set (most DSLRs only allow you to bracket up to three photos in one set). There is a open source project already out there to do this, the Open Camera Controller (OCC), this project uses a Nintendo DS or Nintendo DS Lite and a simple arduino interface cartridge to fire the remote shutter release on your camera. This project has a really nice software interface, the only limitation is that most camera do not allow faster then 1/20 sec remote shutter release exposure times in bulb mode. You also have to account for the frames per second rating of the camera and memory card speed. So I wanted to switch to PTP/MTP USB control of the camera which can use the camera to the full extent of it's capabilities but is much more complicated to implement. I figured the best way to do this would be to try and add USB host capabilities to the Nintendo DS through an expansion card which would allow the possibly of adding USB control to the OCC project.
The first step was to figure out how the Nintendo DS (NDS) talks to the Slot-2 Game Boy Advanced (GBA) cartridge slot. In the OCC project the NDS talks to the arduino by toggling one data line (pin-3 WR#) on the GBA SLOT-2 that is used to fire off the rumble motor in a rumble cartridge. This allows the NDS to tell the OCC arduino to start and stop capture but will not work for the more complex data communication needed for USB control. I started by learning how to compile code to run on the DS, then figuring out the code needed to talk to the GBA slot, reversed engineered the DMA the NDS uses to talk to the GBA slot, and finally wrote logic for a CPLD to convert the GBA SLOT-2 DMA interface into FTDI PFIFO interface used on the FTDI vinculum USB host controller.
Here is my first time lapse ever, go to full screen mode for better quality.
This time lapse of the installation of a 46,000/32,000 BTU, 95% efficiency, 2-Stage Burner, 1,200 CFM Variable Speed furnace with a 15 SEER 2 Ton goodman condenser.
Installed by my brother and myself, we are not HVAC technicians just extreme DIYers. We hired a HVAC contractor to come out and handle all the refridgerant work to be legal. This included recovering the R-22 from the old system and then braze, vacuum, and charge the new line set with R-410A.
Used a Canon Powershot SX10IS with CHDK firmware, set to manual exposure (f/5.6, 1/3sec, ISO 200), custom white balance. Added an el-cheapo $8.00 0.45x wide angle fisheye screw-on lens to capture whole scene in a tight attic space.
Used Vdub to compile shots into AVI then used quicktime pro to convert the AVI to MP4.
Total frames: 7770
Frame Rate: 26fps (to make music fit)
Shoot at 1 frame ever 5-30secons depending on the level of activity. Total install took a couple of days of work.
Music: Serphonic - 5am
HDCD seems to be an abandoned format in hardware and software decoding support. I have grown frustrated with the late 90's+ to today trend to see how "loud" they can master a CD, destroying the original recording the process, check out loudness war for some great examples and pictures. The HDCD encoding process is suppose to reduce some of the "loudness" and increase the dynamic range, it does not make a huge difference but it is better then nothing.
Since I archive all my music from CD's in lossless compression I have been looking for a way to decode my HDCD collection to 24-bit 44.1K WAV --> FLAC files so I will not need any software or hardware decoders to playback the HDCD content, just a 24-bit DAC. I stumbled upon HDCD.exe and preform some tests to see if it matched Microsoft windows media players decoding of HDCD, end result, it does. Ready further if you want to see how I tested and how I got it wrong at first.
There is a lot of misinformation and conflicting reports on how HDCD data is stored, what data is stored, what the HDCD does, difference in decoders, etc. Also since Microsoft (the new owner of HDCD licensing) long since abounded there central point of information, HDCD.com, I can easily see why many people are confused about HDCD. It took a while for me to sort through the information.
After Microsoft acquired the company that designed the HDCD standard it slowly lost steam. This is why all versions of windows media player after and including version 9 include HDCD decoding support (24-bit output must be enabled and computer must have 24-bit sound card)
I decided to test HDCD.exe software decoder for myself after seeing a few posts saying that this software does not decode HDCD's fully. I am a data and visual person so I had to run some tests and see if HDCD.exe can decoded HDCD information fully compared to windows media player.
HDCD.exe vs WMP 11 TEST 1
This test is Invalid, see second test 2 below, I removed the screenshots to avoid confusion.
Test 1: Using a WMP playback with windows direct sound capture to compare to HDCD.exe 24-bit decoded WAV
There seems to be an issue with the wav the direct sound function of windows works. The original CD EAC ripped WAV vs the direct sound capture of software playback of the original CD where almost identical but the same comparison done with WMP HDCD playback and HDCD.exe decoded wav were not, it may be that direct sound capture gets messed up in 24-bit. Either way the WMP wav out plug-in wav file matches the HDCD.exe decoded WAV, shown in test below.
HDCD.exe vs WMP 11 TEST 2
Test 2: Using a WMP wav-out plug-in to compare to HDCD.exe 24-bit decoded WAV
Here is how I tested this:
- I am testing this on the HDCD Sampler 2 album, track 2.
- I am running WMP 11, with 24-bit output checked in settings (there is a bug in WMP 11 where it will only show the HDCD logo when 24-bit output is disabled.. you have to turn on 24-bit output for the HDCD decoding to work). I am using the chronotron WMP wave output plug-in to output WMP playback stream to a WAV file.
- The second waveform is using HDCD.exe to decode an original HDCD ripped wav file to a 24-bit 44.1kHz HDCD decoded wav file.
Track information from hdcd.exe
Packets Processed : 2730
Peak extend : Enabled permanently
Minimum gain : -4.0dB
Maximum gain : 0.0dB
Transient filter (Unsupported) : Enabled intermittently
I have also tried tracks on HDCDs that do not use peak extend or transient filters and they match WMP decoded output
As you can see the output matches, if I invert the first waveform and add it to the second waveform in cool edit pro v2.1 I get the silence which confirms HDCD.exe is decoding the HDCD content the same as WMP is. Hope this helps others with questions about the two decoders.
It is important to note that WMP and HDCD.exe do not apply transient filters even if the disk has this feature enabled so software decoding will not be as good as hardware. I will try to grab the PCM stream to the DAC in my HDCD hardware player and post a compairison.
Other software decoders:
dBpoweramp has a DSP plug-in to decode HDCD but after looking in the plug-in folder you can see they are simply using the free HDCD.exe utility to decode HDCD information. If you have dBpoweramp and the dsp plug-ins installed take a look in the plug-in folder located in C:\Program Files (x86)\Illustrate\dBpoweramp\DSPs\HDCD -OR- C:\Program Files\Illustrate\dBpoweramp\DSPs\HDCD (depending if you have 64 or 32-bit OS) and you will find the HDCD.exe utility