Thx for the huge hint!

I can confirm it works.
150 Gh/s per module on Oct 4 VRM modules.
I have 2 Saturn doing a reliable 600 at the pool and 720 at the wall.

Along the way I managed to put to sleep and awaken individual die.
I think this is the way to address the dead die issue.
I offered to discuss my findings with a KnCMiner engineer, no reply.
My guess/observation is it is a low priority for KnC to fix the dead die issue.
Sad if true.
The fix seems simple, monitordcdc knows, try different clocks when dead die detected.
I have tested many low current working solutions at stock speeds.

One problem I ran into is that every ASIC is different and the .sh threats them all the same.
One Saturn was easy and one I had to do a lot of hunting (not recommended)

My next step will be unrolling the afore mentioned program loop and try each module seperately and possibly each die seperately for maximum yield.

Trying any of this will VOID YOUR WARRANTY.
You might kill your miner AND have no warranty!
You have been warned.

I have an educated guess on the field width of the variables.

I treat them as 4 bit fields with some success.
If the middle one is 5 or 6 bits wide more finesse is possible.

The lowest 2-4 bits seem to control the output and/or loop divider.
Larger numbers more division (behaves like divider)
Has a major impact, compensate with what I am calling input/reference divider.

Middle nibble seems like 4 bits of loop control.
There may be more lower bits to this field, unconfirmed.
Larger is faster.
This is the one to fiddle with once the others are close.

Highest nibble 3-4 bits of what I call input/reference divider.
Larger numbers less division (behaves like add or multiply)

Start with the middle one only and watch the current!!!
Be ready to bail if needed.
Just stop modified sh and start unmodified one.
(you did modify the COPY of the file right?)

I might have the fields backwards but I get predictable results.

This is a dangerous game to play with an expensive ASIC.
You will VOID YOUR WARRANTY and might kill your machine.

Please refrain from simplifying the process for the masses, yet.
The edits are easy, the possibility of meltdown is real.
Further testing is needed.

Don't even think about editing this stuff on a Nov unit with 8 VRM's
There is easily enough power available to cook your ASIC.
It is also not the same file to edit.
Think twice about it if you have an Oct. with 8 VRM.
There is easily enough power available to cook your ASIC.

I use 47 A and 37 W as the max per die for 150 Gh/s per module.
Under 45 A and 35 W max with stock 144 per module speed.

The main use I have for the tuning suite is feedback.
The SPI clock @ 200k is plenty. Higher is fun but not very effective.
I looked with a scope, there is room to spare @ 200k.
I leave everything default until i get the ASIC clock happy.
Once the clock is happy the rest makes little difference and I only tune V for lower power.
VCO current is IMneverHO more important than all else.
It is significant, an Idle die uses ~15 A, much of that is the clock.
If you see a die with 0 A suspect a stalled clock.
There are even ways to occasionally unstall a stalled clock.
Make a small edit to the SPI clock and hit the apply button.

For the 'hardware' tweakers, I speculate 2 loop caps per die on bottom of board.
Next diff increase or so and I may take the iron and find out.

I spent a lot to find and document the details and pass them on, downtime is money.
You can help fund this research if interested.
Just point your miner to one of my workers for a few minutes.

For BTCGuild worker = tolip_ZsearchFund (PPS, best for short donations)
For GHash.io  worker = tolip.anything (replace anything with your name if you like)

You can also use my reseller ID if you purchase a Neptune.

https://www.kncminer.com/?resellerid=206

Enjoy