one thing I noticed is that if the fan is set too low manually on the mini batch 4 the machine will cut speed back accordingly. So if the controller sets the fan to say 4500rpm and you drop it too low the speed will reduce. The batch 4 mini's need a fan simulator and other hw mod to fan to run batch 1 firmware unless you don't mind the fan running 100%
What do you mean "cut speed back accordingly"? Are you saying the frequency and hashrate drops?
Otherwise, I would not expect a "fan simulator" to not act any different than a regular fan in the condition you have described.
Another point on the "batch 4 minis" is that I believe their availability is only mainland china?
-j
If cgminer wants the fan to run at a certain rpm and you lower it below what it is expecting the hashrate will drop and eventually goto 0. The batch 4 mini I have been playing with runs in fault mode because of the coding for the temp. When I manually lower the fan to say 5000 rpm from the 5880 it sets due to the fault the hashrate will drop until I bring the fan back to the 5880 rpm. Personally fan checking should be disabled to get around any issues with a fan simulator or the fan itself. I tried bypassing the checking but failed on my first attempt cgminer wouldn't even load. I screwed my board now it wont detect the fan rpm no matter what the circuit is good so I figure playing with it killed it on the processor but I did try a v9 controller and same issue with fan runs at full on the batch 4
these fans default to full speed when first kicked up unless specifically slowed down.
I'm unsure how you are "lowering the fan speed" when "cgminer wants the fan to run at a certain rpm".
And what do you mean "runs in fault mode"? What is the exact error(s)? Where is this "fault mode" seen?
where in cgminer did you try to "bypass the checking"? This one is different than the ones in the past.
What do you mean "cgminer wouldn't even load"? Do you mean you damaged the binary trying to modify it?
How did you "screw your board"? There is not a single software related activity that should "Screw a board".
Your response just creates a ton of questions.
Jason
On the batch 4 with batch 1 firmware the temps don't report on 2 of the hash boards. So because of this the fault light comes on and the fan is set to full speed. If I use a fan simulator or reduce the fan speed thru the PWM line the rpm must be reported as at least 5880 which is what the machine set the fan at due to the fault light if the simulator or fan don't report 5880 or higher cgminer will lower the hash rate and even drop to 0 this seems to be based off the rpm the lower the rpm the lower the hash rate the higher the rpm towards the 5880 the rate picks up. So if I leave the fan run full rpm it hashes away just fine at full hash rate. This could be due only to the fault being triggered by the non-reporting of the temps correctly. I am waiting for another controller so I can play with it some more. I don't know why this one lost detecting the fan rpm and so far I haven't been able to disable this feature of cgminer. cgminer at startup wants to check the fan rpm and monitors it for any rpm below 1440.
I screwed the input on the board when I shorted it out moving a fan simulator. The error I get is no fan detected and loops on a fan check. Fault is seen in kernel log. Yes I screwed the binary modding it simple fix was reload firmware. Used pwm line to play with fan speed a 100k variable resistor between it and the gnd will vary fan speed. Unhooked pwm line from controller to assure no contact between gnd and controller side of pwm. The processor itself is not detecting any rpm signal. Checked the resistors they test ok so only other thing could be burnt the input on the processor. If I can get past the fan check it will mine just fine so basically I need the fan check and monitor to look for 0 rpm so it will continue to load and hash