Got a question for yall....
I remember a few people having issues w/ their Titan webgui advanced page being blank and the miner wouldnt hash at all on firmware versions higher than v1.02

Im wondering if this just so happens to be the difference between a Pi A (the older 256MB RAM version)  or the Pi B (newer 512MB RAM version).

Can anyone confirm testing of a Pi A w/ their Titan?

best place is always a place you can directly control them.

Quick update: Cube settings history tracking for each controller... code written and in testing =)

Nice suggestion but I have no idea how to do that second part. Also, Im strongly against any sort of centralization of the miners, which is what ur proposed idea would do.

Maybe, although I leave in a couple weeks for christmas vacation so.... autotune(Energy Saver) AND this feature would have to be ready for release, and not sure if autotune is ready, although its getting really close so will see, after some more tests.

Yeah, I guess many may not use this feature. Hrm..... will see what more folks say.

Ok, time for another question to all ya guys!!!!
If there was a way to keep track of last used volts / clocks for any given cube which was previously plugged in or swapped around on the pi ... would it be useful for yall?

I believe i can code something up that would do this, using the serial number of each cube to keep track of their previously used clocks & volts on a specific pi.

IE: If I coded this up, this is what would happen: lets say you have a miner with 2 cubes and you moved those 2 cubes to different ports or even swapped them around(on the same pi), the next time you boot the miner up ... the voltages & clocks would have moved automatically w/ the cubes to their new slots.

Heads up to everyone. Im not sure if I posted this news yet in the thread.
I have come across a very serious "overlook" on KNC's part(in addition to you know... no fan fail protection, no DCDC overcurrent-overheat protection, etc... LOL!). It was wreaking havoc on my "Energy Saver" algo & confusing the crap outta Titans who had their cubes switched around / removed & added etc....
The problem was, the configuration file which holds the data for clocks & volts was never properly cleaned up when cubes were removed or added or switched spots on the controller. This lead to "ghost" entries being left in the config file.
So, as a fix and for my next release, The firmware will now update the config file w/ the current running settings of the cubes attached(each time the monitoring script is restarted) to the controller, hence removing the "ghost" entries being left in the config file.

Im also not sure if everyone is aware of this... but clocks & volts are bound to the ports on the controller, they ARE NOT bound to the cubes themselves. So, if you move a cube to a different slot, u would have to change the clocks & volts accordingly on the advanced page.

EDIT: just had an idea, if theres a way to identify each cube uniquely like a serial number or something, via code then.... a future feature may indeed be tracking per cube clock/die configurations!!!! That would be exciting.
IE, a pi would remember which cube was plugged in where and what the clocks & volts were for it, then if the pi senses that cube moved or plugged in again at some future point then it would set the clock & voltages it was last configured with. But, if theres no unique identification per cube then...this wont be doable. Time to research a bit =)

EDIT: FOUND IT! .... the eeprom has what looks like a unique serial number for each cube. This could be used to keep track of per cube volts/clocks =) so they would be bound to cubes. New SN's would default to default clocks / voltages.

Wow, ur willing to run 1 netbook per cube!? thats a significant expense LOL! Isnt there a way to multiplex the cubes for a single netbook somehow?

Another note, if you can figure out how to reverse engineer those signals, and get at least work submission working to the cubes , we would need the "ASIC metadata"(such as clocks & voltages) sniffed and figured out as well. With that, we could set the speed to anything we wanted =) ... the 350mhz overclock, for those who wanna burn their cubes and PSU's ... that will become a reality =)

Yeah, I guess a decent netbook would maybe be enough compute power to do the job, but I would only use one as a backup and leave the controller on the titan till the controller dies.

In scrypt, on work restarts I think theres some compute heavy "higher level" of the algo that gets calculated prior to dispatching the jobs to the ASIC itself. Perhaps, this is what the controller is tasked with and does it a lot faster then a pi could.

Um.... I thought u knew this whole time... LOL! KNC has effectively abandoned Titan users. Cept for the hand picked warranties they decide to honor here and there.

You're correct, no ASIC requires a bunch of bandwidth. I think its just KNC's method of "control over their hardware". I asked them if I could get source for the software that runs on the FPGA, they flatout said no, even w/ an NDA.

Well, you can open up one of my firmware .bin files (v99e) and extract the webgui from webinterface/http folder =)

Do you have a titan with my firmware installed? If so, all the web files are located in /www of the pi ... u can use scp to copy that folder out or if ur on windows use winscp and modify away =)

Im not really focusing on any more webgui enhancements at this point in time except working with whats already there.

I am going to keep KNCminion because it doesnt get in the way of any coding changes I make so its like a freebie for everyone =)

No version F, not exactly sure what the next version will be called. The reason for the long time between releases currently is because of my lengthy testing of "Energy Saver" ... to date its the most complex thing Ive coded into the firmware. Im goin on vacation in a couple weeks, if its not out by then it wont be till January sometime.

I want to get my firmware for the KNC titan listed on their site. Ive tried using their 'contact us' form several times ... a few months ago and a week or 2 ago ... never heard from them =(

Yeah, my firmware makes it so that all happens automatically, like I stated above. You dont have to manually power cycle (hard boot) it.

It may have just been a scare tactic, cuz around that time there was a GIGANTIC sell wall on btc-e and tons of people saying it was the end of LTC

This is one of the things my firmware addresses....... fixes it automatically (given the DCDC's & Die are not broken at the hardware level, its rare). My firmware simply power cycles the cube w/ the effected die and then restarts bfgminer. Brings the die back 99.9% of the time =)