DEVICE: BitFORCE SC
FIRMWARE: 1.2.9
IAR Executed: NO
CHIP PARALLELIZATION: YES @ 16
QUEUE DEPTH:40
PROCESSOR 1: 14 engines @ 234 MHz -- MAP: EFF7
PROCESSOR 2: 14 engines @ 237 MHz -- MAP: 7FBF
PROCESSOR 3: 16 engines @ 247 MHz -- MAP: FFFF
PROCESSOR 4: 10 engines @ 229 MHz -- MAP: 4DF5
PROCESSOR 5: 16 engines @ 237 MHz -- MAP: FFFF
PROCESSOR 6: 15 engines @ 234 MHz -- MAP: FFDF
PROCESSOR 7: 14 engines @ 241 MHz -- MAP: AFFF
PROCESSOR 8: 10 engines @ 238 MHz -- MAP: 67E6
PROCESSOR 9: 15 engines @ 231 MHz -- MAP: FFFE
PROCESSOR 10: 13 engines @ 248 MHz -- MAP: EFF6
PROCESSOR 11: 15 engines @ 231 MHz -- MAP: FFFE
PROCESSOR 12: 15 engines @ 228 MHz -- MAP: FFFE
PROCESSOR 13: 15 engines @ 238 MHz -- MAP: FFFE
PROCESSOR 14: 14 engines @ 231 MHz -- MAP: FFF6
PROCESSOR 15: 5 engines @ 238 MHz -- MAP: 0332
THEORETICAL MAX: 47460 MH/s
ENGINES: 201
FREQUENCY: 291 MHz
CRITICAL TEMPERATURE: 0
TOTAL THERMAL CYCLES: 0
XLINK MODE: MASTER
XLINK PRESENT: NO
OK

Ok, seems the BFL products don't like power cycling. At least if it's mining you will break engines just by pulling the power.

Got some kind of official confirmation from support: "Some times, the number of engines can change after initialization. Power cycling a unit usually shows this, but it doesn't vary greatly from cycle to cycle."

This is like a car manufacturer building a serial design flaw; BFL should pull all of it's miners and deliver working products.

With the new singles with aluminium heatsinks you can't do this it seems.