Cooling fan upgrade comparison: Explorer 11-blade fan and HD clutch versus SPAL 19" 850-watt electric brushless fan

one of the things I enjoyed about swapping to electric was being quieter…so I was sucked in for the read. However by the end of the read, I believe i would be driving around radio off, just to listen for a fan responding to all that mental effort put into practice. 😄

The SPAL fan is inaudible in the cabin with the engine on unless it's running near max speed. Leading to me constantly hopping out to see what speed it is running...
 
The SPAL fan is inaudible in the cabin with the engine on unless it's running near max speed. Leading to me constantly hopping out to see what speed it is running...

While I don't have the same SPAL fan as what you're testing I can attest to the fact that you can't hear the fan when running at higher speed (I can't say what speed my fan is at but my ECT is 200*) inside the cabin. Even when I have JUST have the KOEO (key on engine off) you can barely hear the fan running from inside the cabin.
 
  • Like
Reactions: freedom_in_4low
Cool stuff. So long as it could grab 5v signals from the pcm for this,what about using tps,rpm,map and mph to modify the ramp curve? Predicting load would be useful

So far I was only considering things I could easily do just installing separate sensors, but reading from the PCM opens up a lot of possibilities.

What you're hitting on is called "feed forward" (as opposed to feedback) in my industry. for example, a change in load calls for a change in compressor capacity, the controls can make a proactive corresponding change in condenser fan speed or expansion valve position rather than just waiting for them to respond and take time to settle. The same could be done here with the Engine Load PID.
 
  • Like
Reactions: Wildman and Rickyd
This is very interesting and I would definitely be interested to follow this and even try it if you can come up with an even better solution.

I do have a Rugged Circuits Arduino Mega (basically a US-made Arduino designed for extreme temperatures) on hand that I originally planned to drive the fan with. But my C++ programming skills are just barely enough to be dangerous with a 3D printer...

I've never done anything with a 3d printer but that sounds more intimidating to me than this does. 🤣

And I won't claim my solution is better ..it's just more...me, lol. Based on what you say about how quiet yours is, I may just spend hours testing and coding this for no perceptible reduction in noise.

My biggest challenge will be on the hardware side, as my background is that of a mechanical engineer that accidentally learned to code and my electronics knowledge is lacking. I'll need to figure out how to get to the 5V pwm output from the Arduino to the 12V pwm signal required by the fan.

There are few ways to get an Arduino to interface with the PCM so you could poll PIDs. My simplest idea was to just enable the PWM fan option in the tuner/PCM, and then use the Arduino to just poll that and run the fan at that speed. The program in the PCM is fairly sophisticated, from what I've learned; it's biggest flaw is that the 4.0 doesn't have the A/C pressure transducer like the 2.4s and other electric fan models of it's era. Alternatively, poll various PIDs so you can monitor things like A/C status, engine RPM, road speed, ambient air temp, coolant temp sensor readings, etc. to allow the Arduino to calculate a basic PWM value.

Polling PIDs would take this to the next level, even beyond saving me from having sensor cables strung all over the engine bay. It crossed my mind and I figured it was out there but I haven't seriously looked into it.

One thing I've struggled with in the past is finding the additional PIDs outside of the standard OBD2 ones. For example I know fuel level is in there, but Torque doesn't find it and I haven't been able to find a list of those, like ambient temp and AC status.

There are definitely Arduino programs out there that do full Proportional-Integral-Derivative (PID) control of temperatures that would probably be easy to adapt to a fan as well. The derivative part of the control might also be very useful in addition to proportional and integral, given that it would allow the fan to react aggressively to fast changes in temperature.

While I couldn't even start to build one from scratch, I know the Arduino powering my 3D printer has several PID control functions, notably for the extruder heater cartridge and the heated bed. The source code for this is free and open-source (for example, Prusa MK3S+), so someone with more programming experience could certainly figure out exactly what to rip. (Temperature.cpp or temperature.h I think are the sub-files that have the PID control, but it's been a while since I've messed with it.)

Edit: temperature.cpp in the Marlin/MK3S firmware has the PID program.

Yeah, I've seen the PID libraries in there. I'm sure they work but I'll often brew my own if I can. Part of it is that everybody implements them a little differently and I get tired of wading through documentation trying to understand it. The one I use at work was deprecated and replaced 5 years ago and I won't use the newer version anymore because it was doing weird stuff with the integral where it would just stop calling the condenser fan at all after anywhere from 2-10 weeks and I'd get a call from an angry grocery store tech on a weekend. Coding it myself gives me some more control over it and any screwups are on me.

Derivative is beautiful in theory but I rarely see people have success getting it tuned right. I usually use PI only unless I'm having issues with overshooting and even then I'm pretty conservative with it.
 
Last edited:
I've never done anything with a 3d printer but that sounds more intimidating to me than this does. 🤣

And I won't claim my solution is better ..it's just more...me, lol. Based on what you say about how quiet yours is, I may just spend hours testing and coding this for no perceptible reduction in noise.

My biggest challenge will be on the hardware side, as my background is that of a mechanical engineer that accidentally learned to code and my electronics knowledge is lacking. I'll need to figure out how to get to the 5V pwm output from the Arduino to the 12V pwm signal required by the fan.



Polling PIDs would take this to the next level, even beyond saving me from having sensor cables strung all over the engine bay. It crossed my mind and I figured it was out there but I haven't seriously looked into it.

One thing I've struggled with in the past is finding the additional PIDs outside of the standard OBD2 ones. For example I know fuel level is in there, but Torque doesn't find it and I haven't been able to find a list of those, like ambient temp and AC status.



Yeah, I've seen the PID libraries in there. I'm sure they work but I'll often brew my own if I can. Part of it is that everybody implements them a little differently and I get tired of wading through documentation trying to understand it. The one I use at work was deprecated and replaced 5 years ago and I won't use the newer version anymore because it was doing weird stuff with the integral where it would just stop calling the condenser fan at all after anywhere from 2-10 weeks and I'd get a call from an angry grocery store tech on a weekend. Coding it myself gives me some more control over it and any screwups are on me.

Derivative is beautiful in theory but I rarely see people have success getting it tuned right. I usually use PI only unless I'm having issues with overshooting and even then I'm pretty conservative with it.

3D printers are actually incredibly simple. I am still impressed that one as good as the Prusa runs entirely off of an Arduino Mega. The kit I had was 100% pre-programmed, but I had to make custom firmware to override some temperature limits after a number of mods. Of course now I'm building a new one that uses a more sophisticated controller and a Raspberry Pi.

I've been wanting to learn Arduino anyways, and I may start with a more simple project for learning purposes. For example, I figured if I could replace the fan speed switch with the variable resistor used in the temperature select dial, I could make a very simple program to make the HVAC blower more like 100-speed versus 4-speed, using PWM to a SSR to control the fan speed. (That would also be more energy efficient than the blower motor resistor method, though the fuel savings would be negligible, probably around 20 gallons per 100,000 miles.)

For finding PIDs, the Autel Maxicom scanner I have pulls up a number of PIDs that even HP Tuners doesn't identify, though HP Tuners certainly has a lot more than the Torque app. Not sure if it's possible to rip those.
 
Side note for anyone else following this conversation.
The initialism PID has two distinct definitions here:
  • PID in context of communicating with the PCM/ECM stands for "Parameter ID", or essentially an identifier of a floating value stored in the ECM that monitors the status of a particular sensor, switch, etc. For example, your OBD-II reader can read PIDs for coolant temperature, road speed, fan status, locker relay status, gas tank level, oxygen sensor voltage, etc.
  • PID in terms of a control system stands for Proportional-Integral-Derivative control. PID control is a mathematically-based control scheme that is widely used in industry when you are trying to maintain a fixed state of a variable to the maximum extent practical, when you only have the measurements of that variable itself. PID control reacts to Proportional and Integral like @freedom_in_4low mentioned, as well as Derivative, which reacts in accordance with the rate of change. Most PID control schemes are self-tuning to a degree, meaning they refine their parameters over time to maintain more accurate performance.
A classic example of PID control we are all familiar with is cruise control. Cruise control, in the TJs, is fully controlled by using PID control on the vehicle speed (which is a Parameter ID in the ECM, or the other "PID" term).

Proportional is very simple. Is the speed lower than your set speed? If so, the throttle is set in proportion to the instantaneous difference between your set speed and your actual speed. Meaning it will set high throttle if you're 10 mph below, but minimal throttle if you're 10 mph above.

Integral is a bit more complex. Basically, the controller observes the difference in set speed and actual speed over time. If you're consistently 1 mph below target, integral adjusts the throttle in proportion to the sum of the differences times the time delta of the differences. So it will ramp in even if the proportional status can't change. This is important because load conditions are always changing. Have a headwind? You now need more throttle to maintain the same speed than you would with a tailwind. Integral is slow to react, but seeks to eventually resolve any differences not made up with propotional control.

Derivative is the "oh shit" part of the control scheme. It watches the rate of change of the parameter, and reacts to how fast the parameter is changing. For example, if your speed begins to slowly drop due to a slight hill, proportional and integral control will keep the speed close enough that the speed doesn't rapidly change. However, if you hit a big incline, the speed drops rapidly, and the Derivative function reacts to that by suddenly adding throttle, even where Proportional and Integral would not do so nearly as aggressively, at least not right away. This also helps prevent your speed from rapidly rising when you crest a hill, since the Integral function takes far more time to react. It also helps attenuate rapid corrections in speed that Proportional and Integral might try by themselves, so the end result is smoother rather than jerky.

The other most common control scheme is called "Bang-Bang". Literally this is "on" at a given setpoint, and "off" at a given setpoint. Your water heater thermostat is a perfect example. Is the water temperature below your set value? Turn the element on. Is the water heater above your set value by an amount equal or greater to than the built in hysteresis? Turn the element off again. (Hysteresis is the difference between the "on" and "off" values, and is intended from keeping the device from rapidly cycling on and off.) Back to TJs, an example of Bang-Bang control is your A/C clutch. Is the pressure too low/high? If so, cut the clutch. Is the pressure back within acceptable parameters? If so, engage the clutch.
 
Last edited:
Side note for anyone else following this conversation.
The initialism PID has two distinct definitions here:
  • PID in context of communicating with the PCM/ECM stands for "Parameter ID", or essentially an identifier of a floating value stored in the ECM that monitors the status of a particular sensor, switch, etc. For example, your OBD-II reader can read PIDs for coolant temperature, road speed, fan status, locker relay status, gas tank level, oxygen sensor voltage, etc.
  • PID in terms of a control system stands for Proportional-Integral-Derivative control. PID control is a mathematically-based control scheme that is widely used in industry when you are trying to maintain a fixed state of a variable to the maximum extent practical, when you only have the measurements of that variable itself. PID control reacts to Proportional and Integral like @freedom_in_4low mentioned, as well as Derivative, which reacts in accordance with the rate of change. Most PID control schemes are self-tuning to a degree, meaning they refine their parameters over time to maintain more accurate performance.
A classic example of PID control we are all familiar with is cruise control. Cruise control, in the TJs, is fully controlled by using PID control on the vehicle speed (which is a Parameter ID in the ECM, or the other "PID" term).

Proportional is very simple. Is the speed lower than your set speed? If so, the throttle is set in proportion to the instantaneous difference between your set speed and your actual speed. Meaning it will set high throttle if you're 10 mph below, but minimal throttle if you're 10 mph above.

Integral is a bit more complex. Basically, the controller observes the difference in set speed and actual speed over time. If you're consistently 1 mph below target, integral adjusts the throttle in proportion to the sum of the differences times the time delta of the differences. So it will ramp in even if the proportional status can't change. This is important because load conditions are always changing. Have a headwind? You now need more throttle to maintain the same speed than you would with a tailwind. Integral is slow to react, but seeks to eventually resolve any differences not made up with propotional control.

Derivative is the "oh shit" part of the control scheme. It watches the rate of change of the parameter, and reacts to how fast the parameter is changing. For example, if your speed begins to slowly drop due to a slight hill, proportional and integral control will keep the speed close enough that the speed doesn't rapidly change. However, if you hit a big incline, the speed drops rapidly, and the Derivative function reacts to that by suddenly adding throttle, even where Proportional and Integral would not do so nearly as aggressively, at least not right away. This also helps prevent your speed from rapidly rising when you crest a hill, since the Integral function takes far more time to react. It also helps attenuate rapid corrections in speed that Proportional and Integral might try by themselves, so the end result is smoother rather than jerky.

The other most common control scheme is called "Bang-Bang". Literally this is "on" at a given setpoint, and "off" at a given setpoint. Your water heater thermostat is a perfect example. Is the water temperature below your set value? Turn the element on. Is the water heater above your set value by an amount equal or greater to than the built in hysteresis? Turn the element off again. (Hysteresis is the difference between the "on" and "off" values, and is intended from keeping the device from rapidly cycling on and off.) Back to TJs, an example of Bang-Bang control is your A/C clutch. Is the pressure too low/high? If so, cut the clutch. Is the pressure back within acceptable parameters? If so, engage the clutch.

My favorite way to explain the P and D portions of PID is a spring and shock. The spring is the proportional response as it provides a proportional force to how far it's being compressed. The damper/shock provides a response according to how quickly the piston is moving. The faster it's moving, the more force the shock supplies to slow it down.

Unfortunately I've not thought of a simple mechanical analog to the integral function. maybe you could say it's an airbag that slowly inflates if your ride height is below what you want it to be, and deflates if you're too high. And the inflation rate would be proportional to how far off of ride height you are.
 
Side note for anyone else following this conversation.
The initialism PID has two distinct definitions here:
  • PID in context of communicating with the PCM/ECM stands for "Parameter ID", or essentially an identifier of a floating value stored in the ECM that monitors the status of a particular sensor, switch, etc. For example, your OBD-II reader can read PIDs for coolant temperature, road speed, fan status, locker relay status, gas tank level, oxygen sensor voltage, etc.
  • PID in terms of a control system stands for Proportional-Integral-Derivative control. PID control is a mathematically-based control scheme that is widely used in industry when you are trying to maintain a fixed state of a variable to the maximum extent practical, when you only have the measurements of that variable itself. PID control reacts to Proportional and Integral like @freedom_in_4low mentioned, as well as Derivative, which reacts in accordance with the rate of change. Most PID control schemes are self-tuning to a degree, meaning they refine their parameters over time to maintain more accurate performance.
A classic example of PID control we are all familiar with is cruise control. Cruise control, in the TJs, is fully controlled by using PID control on the vehicle speed (which is a Parameter ID in the ECM, or the other "PID" term).

Proportional is very simple. Is the speed lower than your set speed? If so, the throttle is set in proportion to the instantaneous difference between your set speed and your actual speed. Meaning it will set high throttle if you're 10 mph below, but minimal throttle if you're 10 mph above.

Integral is a bit more complex. Basically, the controller observes the difference in set speed and actual speed over time. If you're consistently 1 mph below target, integral adjusts the throttle in proportion to the sum of the differences times the time delta of the differences. So it will ramp in even if the proportional status can't change. This is important because load conditions are always changing. Have a headwind? You now need more throttle to maintain the same speed than you would with a tailwind. Integral is slow to react, but seeks to eventually resolve any differences not made up with propotional control.

Derivative is the "oh shit" part of the control scheme. It watches the rate of change of the parameter, and reacts to how fast the parameter is changing. For example, if your speed begins to slowly drop due to a slight hill, proportional and integral control will keep the speed close enough that the speed doesn't rapidly change. However, if you hit a big incline, the speed drops rapidly, and the Derivative function reacts to that by suddenly adding throttle, even where Proportional and Integral would not do so nearly as aggressively, at least not right away. This also helps prevent your speed from rapidly rising when you crest a hill, since the Integral function takes far more time to react. It also helps attenuate rapid corrections in speed that Proportional and Integral might try by themselves, so the end result is smoother rather than jerky.

The other most common control scheme is called "Bang-Bang". Literally this is "on" at a given setpoint, and "off" at a given setpoint. Your water heater thermostat is a perfect example. Is the water temperature below your set value? Turn the element on. Is the water heater above your set value by an amount equal or greater to than the built in hysteresis? Turn the element off again. (Hysteresis is the difference between the "on" and "off" values, and is intended from keeping the device from rapidly cycling on and off.) Back to TJs, an example of Bang-Bang control is your A/C clutch. Is the pressure too low/high? If so, cut the clutch. Is the pressure back within acceptable parameters? If so, engage the clutch.

I knew of prop-int-der before I knew about parameter ID, and was in really confused when I started dabbling in OBD2 stuff and kept coming across that acronym.
 
With as advanced as you guys are driving the fan...does the thermostat become unnecessary? If you can control the fan to control coolant temp, therefore engine temp, it seems like using a thermostat is a bit like having an extra constraint in the system.
 
With as advanced as you guys are driving the fan...does the thermostat become unnecessary? If you can control the fan to control coolant temp, therefore engine temp, it seems like using a thermostat is a bit like having an extra constraint in the system.

It's a good thought but yeah we still need it. Even with zero fan, if the jeep is moving at all there's enough air to keep it much too cool at even mild temperatures.
 
With as advanced as you guys are driving the fan...does the thermostat become unnecessary? If you can control the fan to control coolant temp, therefore engine temp, it seems like using a thermostat is a bit like having an extra constraint in the system.

The reason for a thermostat is twofold. It warms the motor up faster by letting just the water in the block heat up first.and it is supposed to keep the motor up to temp in situations where the cooling system is removing too much heat.

The only way I can think of not using a thermostat is having a pcm controlled electric water pump
 
  • Like
Reactions: srimes
@Steel City 06 is there any reason why I wouldn't be successful using the controller method from your write-up? I'll enjoy watching the smarty-pants take things further, but I just want the fan to turn on when it makes sense to turn on and then turn off when I don't need it on.
 
  • Like
Reactions: freedom_in_4low
@Steel City 06 is there any reason why I wouldn't be successful using the controller method from your write-up? I'll enjoy watching the smarty-pants take things further, but I just want the fan to turn on when it makes sense to turn on and then turn off when I don't need it on.

Nope, the controller method I used in the first post is perfectly fine, as is the non-linear one with the Zener diode. The Zener diode one is just an alternate that has the fan always on at a minimum state, and waits longer to ramp in.

The only caveat to the original control scheme is that you have to manually enable the fan at max speed if you start your car and use A/C before the engine fully warms up. The Zener diode control scheme does not have this caveat, and is almost idiot-proof once installed.

The two installs are exactly the same except for having a $0.70 Zener diode from Mouser wired in parallel with the coolant temp sensor and for different temperature settings on the controller.

The Arduino scheme discussed most recently is way overkill for what any of us actually need, but could be an interesting project.
 
As always, the devil is in the details.

I have no parts yet, but I figured I'd write the code and make sure I can at least make it work on the bench.

1. The fan takes a 12V PWM signal at 100Hz. The Arduino by default does something at a much higher frequency, but by writing the right bits within a couple of specific registers that are not very well documented, I can scale the frequency down. However, the denominators available are powers of 2. Without going into the details it looks like I can choose between 122Hz and 61Hz. I don't know how far off of 100 I can get before the fan starts to care. The output is also 5V so I'll need to do some electronics to get 12 but I think it's fairly simple. I can send my speed signal as a 0-5V to the Lingenfelter controller essentially using it as a signal converter, but if I'm gonna buy it I'll just save the $ and effort and skip the Arduino project.

2. I haven't found a well documented and trustworthy library for communicating directly to the PCM using its J1950VPW protocol, plus to do that also calls for some more messy external electronics, so I'm looking into using an ELM327 chip as an intermediary. I'd rather not have my DLC tied up so I have to unplug my fan to read data though, so I'm considering taking apart a $20 USB to OBD2 reader and wiring it directly into the OBD2 bus conductors. Sparkfun sells one on a board with a db9 plug but they're $56 and backordered.

Most of the actual control code is written for both control schemes, but I want to add some safeties... For example I revert to the lower hose temp and use the proportional strategy if comms can't be established with the PCM to read ECT, and if comms are lost AND the lower hose temp goes out of range then just go to full speed, like below -30 (indicating an open sensor) or above 190 (indicating a shorted sensor or a legitimate heat issue).

For the AC I decided to assume it's on if the liquid line temp is over 120 but the lower hose temp is under 130, and when that is true I set a minimum air volume demand of 20%. That way it'll stay off unless I turn the AC on, and then once the engine warms up enough to run the fan, it will let go of the 20% floor and just do what it needs to do.

I also am using OBD2 speed to disable the fan if I exceed 37mph, because that the velocity of the air at 4000cfm through the grill, so the fan is no longer necessary. There's certainly some losses there that I'm not accounting for but thats not a speed that really corresponds with a high load anyway. If comms are lost I'll ignore the speed shutdown and just depend on the temperature to do it's thing and ramp the fan down organically.
 
As always, the devil is in the details.

I have no parts yet, but I figured I'd write the code and make sure I can at least make it work on the bench.

1. The fan takes a 12V PWM signal at 100Hz. The Arduino by default does something at a much higher frequency, but by writing the right bits within a couple of specific registers that are not very well documented, I can scale the frequency down. However, the denominators available are powers of 2. Without going into the details it looks like I can choose between 122Hz and 61Hz. I don't know how far off of 100 I can get before the fan starts to care. The output is also 5V so I'll need to do some electronics to get 12 but I think it's fairly simple. I can send my speed signal as a 0-5V to the Lingenfelter controller essentially using it as a signal converter, but if I'm gonna buy it I'll just save the $ and effort and skip the Arduino project.

2. I haven't found a well documented and trustworthy library for communicating directly to the PCM using its J1950VPW protocol, plus to do that also calls for some more messy external electronics, so I'm looking into using an ELM327 chip as an intermediary. I'd rather not have my DLC tied up so I have to unplug my fan to read data though, so I'm considering taking apart a $20 USB to OBD2 reader and wiring it directly into the OBD2 bus conductors. Sparkfun sells one on a board with a db9 plug but they're $56 and backordered.

Most of the actual control code is written for both control schemes, but I want to add some safeties... For example I revert to the lower hose temp and use the proportional strategy if comms can't be established with the PCM to read ECT, and if comms are lost AND the lower hose temp goes out of range then just go to full speed, like below -30 (indicating an open sensor) or above 190 (indicating a shorted sensor or a legitimate heat issue).

For the AC I decided to assume it's on if the liquid line temp is over 120 but the lower hose temp is under 130, and when that is true I set a minimum air volume demand of 20%. That way it'll stay off unless I turn the AC on, and then once the engine warms up enough to run the fan, it will let go of the 20% floor and just do what it needs to do.

I also am using OBD2 speed to disable the fan if I exceed 37mph, because that the velocity of the air at 4000cfm through the grill, so the fan is no longer necessary. There's certainly some losses there that I'm not accounting for but thats not a speed that really corresponds with a high load anyway. If comms are lost I'll ignore the speed shutdown and just depend on the temperature to do it's thing and ramp the fan down organically.

Not sure if you've already covered it, but note that the OEM fans are controlled by PWM to ground. Basically, the ECM (that you are trying to mimic) is switching to ground (not 5V or 12V) at 100 cycles per second. I believe the Arduino provides 5V PWM, so if you just use it to switch a transistor to ground, that might work.

I'm definitely interested to see how this goes...
 
Not sure if you've already covered it, but note that the OEM fans are controlled by PWM to ground. Basically, the ECM (that you are trying to mimic) is switching to ground (not 5V or 12V) at 100 cycles per second. I believe the Arduino provides 5V PWM, so if you just use it to switch a transistor to ground, that might work.

I'm definitely interested to see how this goes...

Thank you for that....That is very good info and I do think it would simplify the external electronics...I think it also may clear up something I was still figuring out.

I noticed in the Lingenfelter documentation that there is a "polarity" column, and I saw before when you said the scale is flip flopped so maximum PWM = minimum fan, and min PWM = max fan, but I couldn't find that indicated in the table unless it's implied by polarity. Switching ground would mean when my Arduino is outputting 5V for a 90% duty cycle, the fan would be seeing 12V for a 10% duty.

1000002398.png


Now just to figure out how much the fan cares about getting the frequency just right. This is my first adventure into PWM as the HVACR industry mostly uses 0-10V or 0-20mA with some variations on those (like 4-20mA, 2-10V, 0-5V, etc. ). I can probably brute force it by literally counting microseconds to turn the pin high and low but I'd rather not if I don't have to, and it'll probably have some jitter, though maybe that's not that big of a deal. EDIT: I found a PWM library that I think should work to get a real 100Hz...if my browser is correctly translating the readme file from the original Russian. I also reached out to SPAL (using my work email to look more official) to ask if their fan would know the difference if I gave it 122Hz instead of exactly 100Hz. If I have that option, I'd rather use it because I can accomplish that without using libraries I don't understand.
 
Last edited:
  • Like
Reactions: ColoJeep
I thought I had lined up a fan at a local salvage yard for $110 after finding it on car-part, called and they confirmed they had it, I drove 30 miles and only then did they tell me it was warranty-tagged...meaning it was a part that they received from a dealership that had been returned under warranty. No information on what might have been wrong with it. The lobby was full of "all sales are final" signs and didn't feel like gambling $110 that a dealer warrantied it for no reason, and then waste a bunch of troubleshooting time not knowing whether it's not coming on because it's broken or because I miswired something.