How to fix AMD 6900 series cards overheating in the Alienware M17x. › Continue reading
I’ve been working on an off for a while on a project to measure photosynthetically active radiation (PAR) as well as analyze electromagnetic spectrum with the same sensor, at the same time. The spectrum in question is approximately 350-750nm. I mainly envisioned this tool for use with marine aquariums, and if things were going better I probably would have built a prototype.
The sensor is a TAOS TSL3301CL. It is a 102-pixel photodiode array with a serial interface. The sensor contains analog stages for gain and offset as well as ADCs that sample the values and read the results to the serial port. It’s a nice device, but I haven’t been able to get what I want out of it. The response for me has been very non-linear. It’s also a very tiny leadless package so it’s not easy to work with.
My plan was to enclose the sensor in a housing with a series of lenses designed to introduce chromatic aberration or a prism to refract the captured ambient light, and then direct the spectral components of the light towards the sensor. The sensor’s response to wavelength is non-linear, but that can be corrected with a function in software for each pixel.
I had a uOLED 128×128 pixel display that I used to display the intensity of light for each pixel. This worked well, and I would have used an averaging function to estimate PAR from that data.
However, I haven’t been able to get the sensor to respond in what I consider a linear fashion. It is mostly on or off. Moving the light source back and forth from the sensor doesn’t result in any gradient that could be considered measurable. I’ve tried various gain and offset levels, as well as long and short integration times but with no success.
I originally tested it with an mbed, but I had trouble with the sensor’s synchronous clock. So I ported the code to the mega2560 on my STK600. About that time the display started to die and I don’t have another graphic display at the moment without messing around with an Epson S1D1335 and another graphics library… As such I’m stashing this project for now. If anyone has worked with these sensors before and knows what I’m doing wrong, I’d like to hear from you.
I recently acquired a 46 gallon ZeroEdge aquarium that was in pretty rough shape. There were a lot of scratches as well as marks from calcareous algae. Here is what I did to repair it. › Continue reading
So everyone that has done the 330W power supply mod that I posted earlier has experienced the power supply shutting down at 240 watts of power draw. That is pretty counterproductive since the M17x ships with a 240W power supply. I did some reverse engineering and some load testing and figured out what the problem is.
I built a simple dynamic load from a few resistors, two op-amps, and an IGBT that I salvaged from an old motor drive. I attached the schematic at the bottom for anyone that wants to build a similar device. I didn’t have a small enough current sense shunt resistor to handle the current, so I used feedback from the gate-emitter voltage since it is roughly proportional to collector-emitter current after about 10 volts. I also used an MC34072 op-amp since it’s what I had laying around. It’s a bit crude but it works.
The dynamic load let me test the power supply and confirm that it was shutting down at 240W. It did, with the highest power I could get at the output being 19.6V @ 12.5A, roughly 245 watts. I also noticed quite a bit of buzzing.
It is pretty unlikely that Dell would make a power supply that badly, and it successfully powers the M18x so I took a closer look at the only thing that could have any effect on the power supply: the ID wire. When I figured out how to put the 240W 1-wire ID chip in place of the 330W ID chip, I found out that the M17x couldn’t drive the 1-wire bus. Something was loading it down farther down the line. Cutting the ID trace after the 1-wire PROM fixed the issue and allowed the M17x to drive the bus high and charge the PROM so it would work (the PROM is parasitically powered). The only thing that could have an effect was whatever was behind that trace. › Continue reading
I have been wondering lately about the effectiveness of building a continuous or automatic daily water change system for my reef aquarium. I really hate batch water changes, but they seem like they would be more effective. I decided to do the math and find out if that was true. A continuous water change can be modeled as a differential equation:
where is the amount of some dissolved substance at time , is the flow rate in and out of the system, and is the volume of the tank. We can simplify the model by making some assumptions: a continuous water change will consist of a small volume over a long period of time, thus the flow rate will be low enough to assume complete mixing in the high water flows of a reef aquarium. Flow rates should be chosen to provide an equivalent reduction of dissolved material as a weekly batch water change, however the rate is not of interest here since we are purely interested in comparing the amount of dissolved material reduction with a batch water change, not how long it will take. It will be easiest to calculate volume with a flow rate of 1 liter per hour. We can also assume an input concentration of 0, since the water coming in should be from an RO/DI system. This gives:
noting that my aquarium is 75 gallons, or 284 liters. We will also set this up as an initial value problem, with being an initial concentration of 50 mg/L of nitrate. The goal is reduction to 45 mg/L which we will compare to a batch water change later. For my 284L aquarium, the total concentration of nitrate would be . This gives:
The particular solution for this IVP is:
I successfully managed to modify the M18x 330W power supply to work in the M17x, which allows for running the M17x with a fast processor and SLI / crossfire. [Update: some people are having issues with the 330W PS running a 920XM processor with 7970m CrossfireX. This combination draws more than than 330W in the M17xR2 for some reason. I have an 840QM and 6990m CrossfireX with no issues, about 200W average] The modification is easier if you already have a 240W power supply, since you will already have the DS2502 1-wire EPROM that is required for the mod. If you don’t have a 240W supply you can also order a DS2502 and program it manually with the 1-wire programmer I posted here. › Continue reading
I wrote some code for my mbed to read and program the memory contents of 1-wire EPROMs like the DS2502. It should work with any device that responds to the same commands. The code can read ROM, status registers and memory pages, and write to the status register and memory pages. I also incorporated support for cyclical redundancy checks since the devices aren’t erasable. I had to build an external circuit for the 12 volt programming pulse to protect the mbed signal pin. If you only need to read you don’t need this, but it is required if you want to program data. Download link to the project source files is below.
After I killed my original motherboard modifying stuff in my 6970m quest, the brightness of my LCD was stuck at low with both the new R1 and R2 motherboards. The function keys couldn’t adjust brightness and neither could windows. Here’s how I fixed it. This is probably only valid for a CCFL backlit display.
The inverter that drives the fluorescent lamps in my display is based on a MAX8759. This chip has an SMBus interface as well as an ambient light sensor interface and a PWM input. The motherboard uses the SMBus interface to control the inverter. You can directly write values to a brightness register, from 0×00 to 0xFF for minimum to maximum brightness. The function keys send incrementally smaller or larger values to the controller. I pulled out my logic analyzer, mbed, and realterm to watch the bus communication and communicate with the inverter controller.
The communication from the EC to the inverter controller is correct, and you can read the brightness register and see the values change based on the function keys. However the brightness continues to stay low. You can also read the fault register, but no faults were present in my case.
What I figured out was the controller by default uses a mode called “SMBus with DPST”, which takes the SMBus brightness value and multiplies it by the PWM duty cycle. This apparently allows another interface to use the PWM input and dim the display without needing to access the bus. The problem was the PWM duty cycle from the EC was 0%, so the controller kept the brightness at 0 regardless of the SMBus setting. › Continue reading
I was recently working on getting an AMD 6970m working in an R1 M17x. I didn’t get it working, but that’s probably largely due to the fact that I was testing with a bad card.
When the computer powers on, before it POSTs, it applies voltage to the three power rails for the graphics card. The graphics card is supposed to turn on its regulators and when things stabilize assert the MXM power_good signal. This happens before any signals are applied to the card’s busses. However if one of the regulators is out of spec, the power_good signal remains low and the computer will not even start POST so you won’t get any error codes, just a black screen.
I looked up the datasheets for the card’s two main regulators and measured the voltages produced. The regulator that I think probably runs the memory chips (APL5913) was spot-on but the regulator for the core (ISL6228) was off by about a tenth of a volt. Hence the failure to release power_good and continue boot. › Continue reading
I have an Alienware M17x that has the Core 2 Quad processor. This isn’t a bad setup, but an i7 in the R2 is much better. There is also the restriction that the R1 can only run the GTX 260m, 280m or AMD 5870m. This makes the M17x mostly obsolete for any modern games. I tried quite a few things to get an AMD 6970m running in the R1 (see here), including modifying the MXM structure in the BIOS. I wasn’t successful, mostly because I eventually figured out that the card I got off eBay to test with was bad. However, I did figure out that an R2 motherboard can replace the R1 motherboard. You will of course need a new processor and the CPU/southbridge is in a different location so you also need an R2 heatsink. Everything else is compatible, and the R2 will run the 6970m.
The only things I had to modify was the LVDS link width for the R1 LCD and the magnesium plate that covers the motherboard. Since the heatsink is in a different location you need to relieve a couple spots.
For the LVDS connection the BIOS for the R2 specifies a 24-bit width and the R1 is an 18-bit width. I modified the MXM system info in the BIOS to fix that and updated the checksum. Then I flashed it to the motherboard. I did this before I figured out the 6970m was dead, so I don’t know if the R1 LCD will work or not without running a modified BIOS since it never POSTed and I fixed the card after flashing the BIOS. › Continue reading
- M17x 6990m / 6970m overheating
- PAR / Spectrum analyzer
- Acrylic polishing and scratch removal
- 330W power supply for M17x update
- Continuous vs. batch water changes
- 330 Watt power supply for Alienware M17x
- mbed 1-wire EPROM driver (DS2502)
- M17x inverter brightness fix
- 6970m power issues
- Upgrade M17x R1 to R2 motherboard
- March 2014 (2)
- December 2013 (1)
- July 2013 (1)
- November 2012 (1)
- October 2012 (4)
- September 2012 (1)
- August 2012 (3)
- June 2012 (1)
- March 2012 (1)
- February 2012 (1)
- January 2012 (1)
- October 2011 (3)
- July 2011 (1)
- June 2011 (3)
- May 2011 (2)
- April 2011 (1)
- December 2010 (1)
- August 2010 (1)
- July 2010 (3)
- April 2010 (2)
- March 2010 (2)
- January 2010 (2)
- December 2009 (2)
- October 2009 (2)
- September 2009 (1)
- August 2009 (15)