[Likely Solved/TBC][Support] Lancelot Board Failure

[DBG]

Recently returned from chemo treatment, with strict rules to rest and avoid any stress for the next two days.  Of course anyone that deals with Bitcoin on a regular basis knows that Finagle's law (a take off on Murphy's Law) is always constantly at play.  I have already contacted CardReaderFactory.com (aka the group that builds the boards on behalf of Blackarrow), however I'm dreading having to ship back a board (Washington D.C. to Hong Kong).  This is basically a copy/paste of the message I sent, however I am hoping to take advantage of experience from fellow BCT users (I'm sure there are many users here who have used an Icarus-based board before).  Thank you in advance for any suggestions and I apologize ahead of time if my replies are delayed (feel like bleh atm =).

I recently bought a Lancelot (as well as some accessories, order #****) from CRF.  The unit worked great, however I wanted to try the upgraded firmware listed on your site.  I was able to flash both FPGA chips very easily and had the board back up and running (with more than adequate cool using 2x 80mm fans in addiction to leaving the cooling that arrived with the unit in place).  The hashing speed didn't improve that much (stock ran at 400MH/s with the v42 firmware running ~450MH/s) however there was no noticeable increase in temperature (or anything else to indicate there was a problem) so I took what I could get.

At 9:15pm today however, the board seemingly completely died (I was alerted by phone 10mins later).  cgminer shows it working just fine up until the point of failure.  Now I am unable to even power on the board.  The power brick used was connected to my UPS unit (and there is no report of a drop or spike in power).  The board was actually running about 10 feet away from me, however I'm so used to blinking lights, that I didn't notice it stop working until I was alerted by phone.  There was no "pop", smoke or anything to indicate that any component blew.

I have no idea what to do at this point (I could test the board at different points to see if any power is flowing at all, but that is not a solution).  It looks like I will need to send the board back for repair, although I would be glad to follow any suggestions regarding diagnostics.  I've only had the unit for 8 days and made sure it was located in an ESD-free zone.

[fpgaminer]

Have you checked the power brick?

[DBG]

Have you checked the power brick?

Yep, I hooked it up to my Siglent SDS1000 Oscilloscope  (I don't know the exact model because a lot of information was scraped off when I bought it from my college - heh it also annoyingly defaults to Chinese whenever it's turned off, however I have memorized all the menu items/display elements) and I suspect that it was the cause.  It ran level for ~10 minutes and then started to produce small oscillations before it spiked high and returned back back to normal.  There was no noticeable sound or any other artifact from the power brick when this happened, so I don't know how long this has been going on and if it's been getting progressively worse or is random.

I guess now is a good time to contact Chinese companies (since it's early late morning there at the moment) as I received a very quick reply from their engineer.  He suspects that it's a matter of a blown fuse (there is a small white chip on the bottom that makes up the fuse).  Since I was also unable to power the board using the alternate molex connection, this seems very likely.  I asked for the part number and will replace it after I finish moving (thankfully the oscilloscope was one of the few things I had not packed yet as I'm just moving a few miles across town).  On an unrelated note (aside from the fact that it deals with the same board), I still need to figure out why the hashing rate is reaching nowhere near it's peak of 840MH/s using the v42 firmware.  I requested -3 quality chips be used, however procurement at reasonable prices, even in bulk, is becoming an issue.  I was told ahead of time that -3 and -3N chips were unavailable, so -2 chips would be used.  I would think I should still be able to reach ~600MH/s, even with the lower quality.

Also thanks for the reply fpgaminer, I don't think we've ever communicated directly, but I've always have the utmost amount of respect for you (I'm all about open software/open hardware, and as far as Bitcoin you are pretty much the George Washington regarding leading the FPGA open-source movement - heh the analogy might be crummy as I'm falling asleep as I type this, but hopefully gist is clear).  Another *unrelated* but do you think bitfury's FPGA source (another person I highly respect if for no other reason than he is well-read; sometimes my brain refuses to input whitepapers, even if I completely understand the concepts being talked about) could be incorporated into the Lancelot design?  I have not had a chance to examine the file(s), however I read that it includes source for Spartan-based chips, so it sounds promising.  I'm about to faceplant into my keyboard though so I will end this here though.  Cross your fingers for me that I don't slip up and trash the Lancelot somehow when replacing the fuse; I always make sure I am well rested or full of caffeine before I let myself near a soldering iron  .

[fpgaminer]

Thank you for the kind words!

Another *unrelated* but do you think bitfury's FPGA source could be incorporated into the Lancelot design?

Most certainly.  The code is, as you surmised, designed for Spartan-6 LX150 chips like the ones used in the Lancelot design.  In fact, I believe all existing commercial FPGA mining boards could run the bitfury design.

To get the bitfury design working, someone would need to learn up the compilation procedure for the bitfury design, and then modify the communication code to suit the Lancelot.  Quite do-able.