Swedish ASIC miner company kncminer.com

[qberty]

Hey GenTarkin any ETA on version F

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.

Have you decided if you're going to keep KnCMinion bundled or not? I was thinking of making a more user-friendly web interface from scratch to deal with the backend (I hate switching between minion and advanced just to check if configs work in real time). If you're willing to let me work on a web interface, think you could PM me your firmwares web files?

[1715148116]

1715148116

[GenTarkin]

Hey GenTarkin any ETA on version F

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.

Have you decided if you're going to keep KnCMinion bundled or not? I was thinking of making a more user-friendly web interface from scratch to deal with the backend (I hate switching between minion and advanced just to check if configs work in real time). If you're willing to let me work on a web interface, think you could PM me your firmwares web files?

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 =)

[qberty]

Hey GenTarkin any ETA on version F

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.

Have you decided if you're going to keep KnCMinion bundled or not? I was thinking of making a more user-friendly web interface from scratch to deal with the backend (I hate switching between minion and advanced just to check if configs work in real time). If you're willing to let me work on a web interface, think you could PM me your firmwares web files?

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 =)

I actually don't have any functioning titans anymore (my bridges burnt out, and fried one of my PIs that had your firmware on it.) so I can't really pull any files

[GenTarkin]

Hey GenTarkin any ETA on version F

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.

Have you decided if you're going to keep KnCMinion bundled or not? I was thinking of making a more user-friendly web interface from scratch to deal with the backend (I hate switching between minion and advanced just to check if configs work in real time). If you're willing to let me work on a web interface, think you could PM me your firmwares web files?

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 =)

I actually don't have any functioning titans anymore (my bridges burnt out, and fried one of my PIs that had your firmware on it.) so I can't really pull any files

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

[Searing]

Hey GenTarkin any ETA on version F

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.

Have you decided if you're going to keep KnCMinion bundled or not? I was thinking of making a more user-friendly web interface from scratch to deal with the backend (I hate switching between minion and advanced just to check if configs work in real time). If you're willing to let me work on a web interface, think you could PM me your firmwares web files?

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 =)

I actually don't have any functioning titans anymore (my bridges burnt out, and fried one of my PIs that had your firmware on it.) so I can't really pull any files

This is probably a dumb question but I have not seen it addressed anyplace..

I don't suppose the bridge connector used on a mercury/saturn/jupiter/neptune board could be used as a bridge or at least modified as such?

again unlikely but just for clarity I figured I'd toss it out here..probably not one being a BBB to port board and other being PI to port board

and a 2nd newbie question...

I have read that the boards are the same between the say the previous BTC KNC boards *jupiter/neptune* etc ....but if that is true is it only
for the NOV such boards? and by the same I mean PHYSICALLY  the same. I realize the FPGA chip I think it is has not be reverse engineered
thus no clone Titan Controllers

anyway just catching up on the stuff here beyond my expertise (which is much)

[tech180]

Well, I'm getting answers all over the place.  This is bonus, so no LCD.  Yes, get GUI and can ssh.  With or without cubes, same response.  I hope its not the controller board.  That may prove hard to replace.

The difference is I advocate correctly isolating the problem before throwing money at it if possible.

Based on your response I'd put the BBB last on the list of suspects.

It sounds like you already did all this but lets review.
Unplug everything and start with the simplest possible, just the controller.
Add one cube retest, try a different cube same ribbon cable.
Only change one thing at a time and see if anything works.

Test with the last known locally working version of firmware.
I'd completely unplug the whole controller from everything and let it sit unpowered for a many minutes. I had one I thought I killed. I replaced it with a spare Hoopiter controller. After few reflashes the original came back to life.
This may have been because I had everything unplugged in between flashes and whatever caused the 'lock up' cleared.
(some residual capacitance somewhere in the PCB design that affects the FPGA or the power chip on controller)
The reflashing I did may not have been necessary, the process may just have provided the long enough power down for it to clear.
My priority was getting it back in service so I never properly isolated root cause.

Another thing you can test for.
Take a single cube, unplug the cube power but connect the ribbon.
Turn on the controller and see if the temp on the ASIC shows up on the web page.
The temp chip on the cube is powered by the controller over the ribbon.
If this works the controller is prolly OK, as it tests controller power chip and FPGA operation.
This might/could point to a wierd 12VDC issue on a cube interfering with controller communication.

If/when you think throwing money at it is a good idea...
You might find a used Merc, Sat, or Jup controller with a BBB for what a new BBB would cost.
Those old knc specific BBB lack some connectors and might not be valued as highly seperately FWIW.

YMMV

Hello,
I need a bit of help for my Titan
Can someone make a diagnosis and tell me if my cubes are burned or my controller is burned ?
When i am running only the controller, the screen works and everything seems ok but
When i am connecting one cube the screen is not working any more, no green flash light , and less green lights on the controller
check the two pictures , without cube and with cube connected

http://s21.postimg.org/m0k1rt877/without.jpg

http://s21.postimg.org/yggrlk1j7/with_cube_on.jpg
Any idea ?  
thank you in advance

Did you ever figure out what the issue was? Having the same problem. Do you have any pictures of your cubes chip set/motherboard? I wonder if you have the bad chipset and ours are the same. I found a solution if it is.

[qberty]

This is probably a dumb question but I have not seen it addressed anyplace..

I don't suppose the bridge connector used on a mercury/saturn/jupiter/neptune board could be used as a bridge or at least modified as such?

again unlikely but just for clarity I figured I'd toss it out here..probably not one being a BBB to port board and other being PI to port board

and a 2nd newbie question...

I have read that the boards are the same between the say the previous BTC KNC boards *jupiter/neptune* etc ....but if that is true is it only
for the NOV such boards? and by the same I mean PHYSICALLY  the same. I realize the FPGA chip I think it is has not be reverse engineered
thus no clone Titan Controllers

anyway just catching up on the stuff here beyond my expertise (which is much)

Yeah the beagle bone uses different IO pins so the bridge would be significantly different and wouldn't work. Yeah I seen a couple posts about the jup and nep having similar physical boards but the titan is a whole other ball game. It has a cyclone microcontroller on it, which i'm in the process of reverse engineering but it's a new one and it's not as simple as the cyclone III. I can see why KnC decided to go with it for the controller board. If I can pull out some compilable binaries from from the chip than I should be able to duplicate the whole controller like I did with the bridge.

[Mattzees]

...I seen a couple posts about the jup and nep having similar physical boards but the titan is a whole other ball game. It has a cyclone microcontroller on it, which i'm in the process of reverse engineering but it's a new one and it's not as simple as the cyclone III. I can see why KnC decided to go with it for the controller board. If I can pull out some compilable binaries from from the chip than I should be able to duplicate the whole controller like I did with the bridge.

Why does the controller need to be duplicated physically at all?  It should be doable in software.  At that point, it's just a matter of hardware bridging to serial cables, which can be bought off-the-shelf.  

I'd love to be able to control my cubes via ethernet or USB, and eliminate the controller entirely.

Edit:  Let me also say I seriously doubt that KNC runs their cubes on same little turd controllers they gave us to use.  I would imagine that KNC uses some other form of cube control in their data center.  We should be able to replicate that somehow.

[qberty]

...I seen a couple posts about the jup and nep having similar physical boards but the titan is a whole other ball game. It has a cyclone microcontroller on it, which i'm in the process of reverse engineering but it's a new one and it's not as simple as the cyclone III. I can see why KnC decided to go with it for the controller board. If I can pull out some compilable binaries from from the chip than I should be able to duplicate the whole controller like I did with the bridge.

Why does the controller need to be duplicated physically at all?  It should be doable in software.  At that point, it's just a matter of hardware bridging to serial cables, which can be bought off-the-shelf.  

I'd love to be able to control my cubes via ethernet or USB, and eliminate the controller entirely.

Edit:  Let me also say I seriously doubt that KNC runs their cubes on same little turd controllers they gave us to use.  I would imagine that KNC uses some other form of cube control in their data center.  We should be able to replicate that somehow.

The problem is, they put the software that knows how to communicate with the cubes, on an encrypted chip sitting on the controller board. Most ASICs (not just miners) have controllers that communicate with the hardware much faster than a computer's available bus will allow.

Having the controller not be part of the host allows the titans to be independent and their efficiently won't be reliant on the host computer (raspberry pi in this case). The controller is definitely needed when dealing with these kinds of things.

If you compare and contrast with the BFL monarchs, they directly connect to your host PC, but rely on modified BFGminer binaries.

[Mattzees]

The problem is, they put the software that knows how to communicate with the cubes, on an encrypted chip sitting on the controller board. Most ASICs (not just miners) have controllers that communicate with the hardware much faster than a computer's available bus will allow.

Having the controller not be part of the host allows the titans to be independent and their efficiently won't be reliant on the host computer (raspberry pi in this case). The controller is definitely needed when dealing with these kinds of things.

If you compare and contrast with the BFL monarchs, they directly connect to your host PC, but rely on modified BFGminer binaries.

Each cube needs more bandwidth to the controller than USB 2.0 could provide to a PC?  I'm surprised.

So, I'm ignorant about this but... Is there no way to attack the FPGA to figure out how to communicate with the cubes?  I had a EE friend of mine explain to me how hard it would be to sniff the signals off the ribbon cable and reverse engineer it.  He said it would be much better to try and reverse engineer the software. 

[Prelude]

The problem is, they put the software that knows how to communicate with the cubes, on an encrypted chip sitting on the controller board. Most ASICs (not just miners) have controllers that communicate with the hardware much faster than a computer's available bus will allow.

Having the controller not be part of the host allows the titans to be independent and their efficiently won't be reliant on the host computer (raspberry pi in this case). The controller is definitely needed when dealing with these kinds of things.

If you compare and contrast with the BFL monarchs, they directly connect to your host PC, but rely on modified BFGminer binaries.

Each cube needs more bandwidth to the controller than USB 2.0 could provide to a PC?  I'm surprised.

So, I'm ignorant about this but... Is there no way to attack the FPGA to figure out how to communicate with the cubes?  I had a EE friend of mine explain to me how hard it would be to sniff the signals off the ribbon cable and reverse engineer it.  He said it would be much better to try and reverse engineer the software. 

I really, really, seriously, doubt that a cube would be too much even for USB 1.0.

[GenTarkin]

The problem is, they put the software that knows how to communicate with the cubes, on an encrypted chip sitting on the controller board. Most ASICs (not just miners) have controllers that communicate with the hardware much faster than a computer's available bus will allow.

Having the controller not be part of the host allows the titans to be independent and their efficiently won't be reliant on the host computer (raspberry pi in this case). The controller is definitely needed when dealing with these kinds of things.

If you compare and contrast with the BFL monarchs, they directly connect to your host PC, but rely on modified BFGminer binaries.

Each cube needs more bandwidth to the controller than USB 2.0 could provide to a PC?  I'm surprised.

So, I'm ignorant about this but... Is there no way to attack the FPGA to figure out how to communicate with the cubes?  I had a EE friend of mine explain to me how hard it would be to sniff the signals off the ribbon cable and reverse engineer it.  He said it would be much better to try and reverse engineer the software. 

I really, really, seriously, doubt that a cube would be too much even for USB 1.0.

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.

[qberty]

It's not about bandwidth (I mentioned bus to refer to protocols and speed). Speed IS a factor here when dealing with an ASIC that has it's performance rely on speed. You don't think your miner would hash faster if the program that was feeding it work was on the controller board rather than your PC? I mean, it's a micro improvement but that's all it takes sometimes. It's about the microcontroller on the controller board. This is how companies keep hardware closed down so that they control the flow. Any ASIC, any FPGA. It's how we do things.

I suppose you could leak all the cables and just get obscure information, but that's slow and may not result to anything if everything is encrypted (knowing KnC, they would encrypt it). It would be much easier to reverse engineer a chip that we know the schematics on. I've been working on exploiting the cyclone on the board with some overflows and some old techniques, but i'll need some more time. Like I said, it's nothing like the old Cyclone chips.

**EDIT** I stand corrected. Tried sniffing the cables. Looks like building a software solution will be possible, unfortunately, speed would be the problem.

[jelin1984]

Knc is closed at factory
Or not?


No answer at email
No

News firmware for titan


Nothing

[GenTarkin]

Knc is closed at factory
Or not?


No answer at email
No

News firmware for titan


Nothing

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.

[Mattzees]

**EDIT** I stand corrected. Tried sniffing the cables. Looks like building a software solution will be possible, unfortunately, speed would be the problem.

Okay, I'm very interested now.  Tell us more.  I smell some crowdfunding coming your way. 

(My uneducated guess was always that this wouldn't be as hard to do as everyone thought it would.)

[GenTarkin]

**EDIT** I stand corrected. Tried sniffing the cables. Looks like building a software solution will be possible, unfortunately, speed would be the problem.

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.

[Mattzees]

**EDIT** I stand corrected. Tried sniffing the cables. Looks like building a software solution will be possible, unfortunately, speed would be the problem.

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.

It does this faster than a Pi could, but what about a netbook or a regular PC?  Even if those were not as fast as the FPGA, would they be sufficiently fast to eliminate the controller?  Currently, if your controller goes down, your Titan is dead.  There are no replacement controllers available.

Someone on Ebay is trying to sell a controller for $900.  For less than half of that, I could buy a netbook or SBC for each cube and be done with it.

[GenTarkin]

**EDIT** I stand corrected. Tried sniffing the cables. Looks like building a software solution will be possible, unfortunately, speed would be the problem.

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.

It does this faster than a Pi could, but what about a netbook or a regular PC?  Even if those were not as fast as the FPGA, would they be sufficiently fast to eliminate the controller?  Currently, if your controller goes down, your Titan is dead.  There are no replacement controllers available.

Someone on Ebay is trying to sell a controller for $900.  For less than half of that, I could buy a netbook or SBC for each cube and be done with it.

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.

[Mattzees]

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.

I would use one netbook/SBC for each cube, and then be able to place the cubes wherever I wanted, without worrying about heating/cooling/power, etc.

FYI- what you're saying about the FPGA doing some algo prep work makes sense.  I have cubes that will not function properly when connected to the controller with other cubes, but if they are the only cube connected to the controller, they work really well.