Well, I definitely understand how chips can be different heights, but in theory, the mounting process should be uniform enough to make the variances stay within a level of tolerance that'd be filled in by design of thermal paste. Pads are extremely poor conductors compared to grease, and my Jalapeno had visibly poor cooling using its stock pads - there were discolorations on the chips from the hot spots! That's why I went with the grease.

The use of an (unlaminated) metal plate on the bottom seems like amateur design suicide... yes, it'll conduct a tiny amount of heat, but at the extreme risk of scraping off insulation of the PCB and shorting out contacts over time. There's no thermal conductive pad there (which itself would be a good idea as well), so it seems entirely unlikely the plate serves any real purpose for cooling.

I like your method of tightening the screws, lightfoot... that sounds like a good plan. Huge, huge kudos for getting 4 chips temporarily running as well. Sounds like something I might try doing myself as well, if I can get the equipment together; I've got some chip credits to burn.

I'm sorry to wake up from your dreams, but it's not like that 

God damn it... well, I had 8.5-8.6gh/s, but now after fucking with the grease again thinking I had air pockets in the last application, this "last time I can screw with it before buying more paste" attempt resulted in a nearly-800mh/s reduction in performance - now running a solid 7.9gh/s average. Thermal problems are insanely understated because hardware usually compensates for most of the stupid crap people do, and it goes unnoticed. With the Jally, I think many hardware tweakers are gonna get a crash course in thermodynamics.

And this thing has painfully tight tolerances inside. Even adding that slice of cardboard spaced out the bottom plate such that the board now would flex a little if I tightened down the four corner mounting screws. So now it sits a little loose (and back to open-air again). Sigh... but this time, sleep takes priority.

1. What about trade history for all currencies for all time?
I really need it, I can't trade without trade history for all time.
For example I'm mining and got my 1 coin from pool every 30 min.
And also I'm trading and history of my deals go down and I don't ever seen them.

2. I think it would be better to see in trade history only trade deals, only Interest Payment, only mining payments for my choose or choose of user. (maybe three buttons)

REALSOLID, what do you think about this idea? Maybe it is already planned?

Can anyone offer any advice on the best stratum-mining fork to use for a SHA256 PoW/PoS coin pool?

Because math? You said you ordered the device on Oct 19th and it shipped three weeks later. That would be November 9th, so whoops, it shipped five days ago, not four days ago. Unless your math is off?

nuff said.

Wait, so they are only four days ahead of this group buy and you're complaining? That could easily be due to different supply chains or numerous other reasons. Little soon to start calling BFL wouldn't you say?

I dont think you could just add more chips to a jally. Can the board support that extra load?

That was the timeline I remember seeing. They explained the situation very well, and since the chips didn't come till early November, this is the expected timeline. I think comparing this to BFL or Avalon at this point is pretty unfair! We all took a risk by preordering, and of course we all wish they had shipped earlier! At least we're not dealing with multimonth delays like cointerra and hashfast, for much more expensive systems. Hopefully we will mine some good coin, and I still feel these devices will be very profitable for fiat, and more profitable in BTC than buying BTC now. Hell, even my early asicminer blade is profitable in fiat now! I'm in mining for a hobby that also turns a profit, not as a get rich quick plan, so perhaps my views are different on the subject.

orly?  where are the lies, deceit, and company asshole bashing users/customers?

far from a "BFL saga" at this point

Hoping they are good to go tomorrow and arrive monday?

Oh, trust and believe, Arduino is a desperate last measure. ANY, and I mean literally ANY, programmer that labels itself as "JTAG" capable, will be able to program this thing with some tool out there, if I'm able to patch this crap-spree together to make it work. I've got a $20 JTAG programmer on its way from eBay too, and it'll be freeing my Arduino up for other projects as soon as it comes in. So I figure it's best to chronicle my adventures now before I hop, skip, and jump my way gleefully away from 3-hour programming durations

Okay, so my Jally is now happily crunching along with the BitForce_SC_1.2.5ck.elf firmware at 8.5-8.9Gh/s, 39C, and about 1% HW errors. Same setup - just converted the firmware and fed it to UrJTAG in the same way as I did last time with the botched-compile firmware. Once it got to "Verifying" (and I slept through the programming, so it was a good halfway through verifying), I canceled it and fired up the board. Took a few seconds, and it finally came-to with 2 LEDs and ready to roll.

So, in the interest of helping the interwebnets, I'm posting a thread with the info for doing it with an Arduino.

Little status post here for those curious about the fringe of hacking this thing... last night I spent a few hours compiling/assembling (hardware/software), adjusting, tweaking, and actually successfully programming my Jalapeno using only an Arduino. I think this effectively lifts all limitations on what JTAG programmer you can use

I compiled 1.2.9 with some comment adjustments in the config code. As others have noted, the code seems to be haphazardly thrown together with huge swaths of code commented out (like, in my case, the routines to test chips on startup - commented out by default). It compiled in AVR Studio, then I took the HEX file and made a BIN out of it - then for the next 2.5 hours, the Arduino and the Jalapeno had a conversation with the help of UrJTAG and Ubuntu. Finally, when it moved on to verifying (and a few pages passed by without errors), I killed the program and rebooted the Jally.

It worked! Sort of. It boots up, lights up the 2 LEDs for the two chips, and responds to ID commands (ZCX, etc), indicating the new firmware is there. Chips now running at 300MHz, which is far more than I expect it to run at (but with poor commenting in the code, I couldn't tell what I was setting it to). But that's all it will do now. The moment I fire up a miner, the Jally knocks out one of the chip LEDs and goes into a hard-lock until I power-cycle it.

Not bad for the first guy flashing a Jally using only an Arduino and about 30% custom code made up on the spot (on both UrJTAG's source code and in Arduiggler's code). When I get back to it today I'll give it another go.

Damn shame the "set frequency factor" (ZVX + 0x04 + 4-byte code) command interpreter function is broken - always saying "INVALID DATA" no matter what it's given, probably due to a broken wait/timeout loop mechanism (killing the command entry too early like it does with Z*X commands if not copied/pasted all at once). Probably could use that command to get the firmware working as it is now

you could use something like this for a slightly more permanent solution:

http://www.jaycar.com.au/productView.asp?ID=NS3033