Yes, please use the techsupport@hashfast.com address.  I'm only working on Zendesk, I'm not sure why the FogBugz thing is still active.  I'll find out.

-Phil

Again; anyone experiencing large amounts of errors will likely be fixed by the pending firmware release.  It's normal to have say 2% or less errors, but if you see huge strings of them, this is a firmware issue.  It will be fixed.  Please be patient.  Making support tickets with these complaints will get the same response I'm here giving you now, as I'm telling them to.

I know it's hard to have patience at this point after all this, but please try.  I've only been @ Hashfast since December, and I was one of many Engineers hired to fix things and get reliable products out to everyone waiting.  I wasn't around when any business decisions were made that affected shipping dates, so I can't comment.

Keep in mind, if you do get an RMA, it's shipping with the same buggy firmware you probably have now, so you could end up with the same problems, and you'll be out the time, effort, and downtime while we ship you another.  Also, it pushes further out any upgrade kits or MPP boards, as we must divert boards for this purpose, and then it's going to take many Engineer-hours going back over every board sent back to see why it was sent back.  (Hours that could be better spent)

-Phil

11 days ago we didn't have the support team in place we do now.  I also wasn't assisting support.  I am checking the support queue (almost) every day, and next week I'm going to give a training session to the support team to improve things.  I'm going to go over all the tickets I've solved for people and show them how I did them.

Now we are using the Zendesk system, it tracks all the tickets and nobody should be closing tickets until they are resolved.  Also, I think responding to a closed ticket re-opens it again.

So, it stinks that you get treated this way, but everyone is really trying and a lot of changes are occurring to make things better.  In short: Try again.

I'll repeat this as well; please email, don't call!  You'll get better service if you email.  If you want to actually talk to someone, just email and request a callback.  Give your # and the best time to call along with a detailed description of your problems (including logs if possible), that way someone with the right skills (possibly even me) will call you back.

-Phil

The new firmware will fix this.  Known issue.

-Phil

HOW TO GENERATE A TECH SUPPORT LOG:

You can create a detailed log by putting the following line in your "Extra cgminer parameters" which is located under the "Settings" tab in your RPI web interface:
Be sure to get the single quotes (apostrophes) and spaces correct.  Incorrect data entered in this box can break your system!  Note that this will now be logging a large volume of text to your SD card, which is a bad idea, as it will rapidly wear out if it has to log all that data.  So be sure to restore the original settings (default is blank) after your logging session.

If your log is getting overwritten too much because the session keeps dying, simply add an additional ">" to the existing one, with no extra spaces.  This will cause it to append the logs instead of overwriting them.

Once you have seen the problem occur, you can access the log file at: http://ip.address.of.your.minepeon/log.txt (so for example: "http://192.168.1.101/log.txt")

If you are not sure of your IP address, you should be able to find it by visiting http://setup.hashfast.com/.

If you can then ZIP or TGZ up the log file and either email it or upload it somewhere where you can share it, such as https://mega.co.nz/, We will then be able to take a look and see what's going on.

Again, DON'T LEAVE THE LOGGING RUNNING TOO LONG!  It will burn up your SD card!

-Phil

As I've said, we hired a new term for support, and are working through the Zendesk tickets.  I'm helping as much as I can (when I have spare time).  This is why I'm not posting in here as often.

The best thing you can do is send an email.  Be sure to include as much information as possible.  A 5-10 minute log file attached generated with "--verbose" is very helpful and needed with most cases. (Tip: Zip or TGZ before attaching.)   People with clear requests having adequate information and not being rude and irate or more likely to get prompt assistance.

-Phil

My understanding is that the procedure is we send you a label for the return board FIRST.  Then you ship your board back, THEN we ship a replacement ASAP.  I am not aware of any procedure where we ship one out first.

-Phil

Thermal overload is an easy fix.  It's either a loose cooler head (tiltled or insufficient pressure) or somehow not enough thermal compound.  Get a tube of Arctic Silver, Noctua, or Xigamatek.  Unscrew the 4 phillips cooler head screws (don't lose the washers!) and then re-apply a very small amount of paste (a grain of rice sized amount) right in the center.  Reinstall the cooler head, and tighten the screws evenly on each corner until the bottom out.  They should stop, if they keep turning, you haven't tightened them fully yet.

This should fix your thermal overload.   This will also usually fix a device with one or two hot dies on a side.

-Phil

I think you are understanding correctly.  It doesn't seem to say WHEN you'll be given the extra hashing capacity.  From what I understand we aren't just sitting on boards, as soon as they get made, they get shipped.  Nothing is lingering.  I think the reason must be that the current production is going to people who paid for normal orders, then after that everyone get's their MPP stuff (Don't quote me, again not my area, I'm assuming here.)

If I were a customer waiting for my first board, I'd probably be pretty pissed if I knew people were getting their free MPP boards before I got my paid unit!

Please people, this is the last question I'm going to answer.  I CANNOT HELP ON THESE ISSUES!

If people want to persist, I'll simply go back to my paid job and quit putting in all this extra non-paid time on helping everyone.

This is officially a NO WHINING ZONE!

-Phil

It seems from reports here like this should be possible, but as I've mentioned before we do not officially support windows, so I can't offer any tips on it.

I use Linux for all my personal stuff and RPI's for mining, and they are reliable, so I don't see any reason to use a larger PC.

If you have an RPI that's not working right, it's likely due to a bad or corrupt SD card.  Get another card (decent brand preferred) from a reputable source and load a fresh image before you declare the RPI "doesn't work".

How to load the SD image: (Including windows instructions)
http://hashfast.com/how-to-update-babyjets-raspberry-pi-sd-card-software/

If re-using an SD card, Be sure to make a backup if possible!  (The best thing to do is just get a totally new card though.)

-Phil

Guys, I asked about the upgrade kits and MPP and was told there were no MPP or upgrade kits ever offered in batch one.  So apparently just because your BJ system was batch one, doesn't mean additional boards would be in the same batch.

That's all I could find out, but it made sense to me even if it's not good news.  Batch 2 orders are now being fulfilled, so if your upgrade kit is in B2, you should be able to expect it soon.

-Phil

Click the "monitor" tab.  You'll see the temps and voltages for each die listed at the top.  Note: You must be running our software on the RPI to see this.  BTW: You also will not be able to get updates if you aren't running our image.  If you don't have a "monitor" tab, you aren't running our recommended image.

-Phil

Hi Storm,

Sorry, I know we are hiring new support people, and I've been helping with training, but a I apologize if you haven't yet heard from them.  I think there's just a huge backlog, and lots and lots of people asking about orders, etc. which slow down tech support issues.

I don't know how RMA works, and it's not my area.  Sorry!   I'm not really even supposed to be doing this, let alone asking around about other departments.  All I can suggest is to be patient.  I know nobody is just sitting around.  We have crazy demand right now, I've never seen anything like it anyplace else I've ever worked.

The stickers mean different things, and it definitely doesn't mean anything is wrong just because the firmware listed version doesn't match the BOM version.  Sometimes the BOM changes without any schematic changes and this can cause a version mismatch like you are seeing.

I appreciate your offer of beta, I'm sure everyone here would take beta code, but we simply don't have the resources to support a beta program right now.

The switches at present do nothing.  They are not read.

-Phil

Hi Micky,

Sorry, the current test firmware has many problems, so if we released it it would break customer systems, and then people would be even more upset.  We have to be sure it's solid first, so I ask for your patience.  I know it's hard to come by at this point, but please give us a little more time.  I know everyone in engineering is working their asses off.

Logistics is not my area, but I think that the delay might be the cooling system.  Apparently the supplier sent cooling systems with hoses that are too short to fit the BJ chassis second radiator location, so there's no way to cool a second board until new ones arrive.  That's probably why there is a delay, but again, not my department.

I know production is working smoothly now, so it shouldn't be long.

-Phil

There are more than a few different revisions of boards out there.  Some have different bulk capacitor configurations, (Different values, more/less populated, etc) and this doesn't mean your board was assembled wrong.  We designed the boards to have lots of low value caps, and all it means if your board has some "missing" it's that we used higher value caps, just less of them.

There is a known issue where a die with a bad core can cause that whole die, and sometimes the whole system, to stop hashing.  We are working on this with the new firmware.  I will post here as soon as the firmware is released.  I do not know when, but I'm hoping for this week.

We aren't going to release anything until it's proven to fix things without reducing performance or reliability.

All boards were tested at the factory, and then tested again in the completed systems before they were shipped.  If you have one that's not working right, please email tech support.

-Phil

Seems that some of the BJ's either had their LED/button connections not properly connected, or they came off in transit.  The shipping companies seem to love beating the snot out of these!

It's not a big problem if you don't have a power LED as long as your box is running, but it's fairly easy to connect them.  There is a 8 pin connector near the rear of the BJ, which is actually 4 two-pin connectors stacked right next to each other.

Looks like this:
::::

The first one (left or rear most 2 pins) is the power LED, the next 2 are the activity LED, then the power button, and finally the reset switch.  (Note the power button is not really used except for testing, as USB can remotely turn on/off your rig)

-Phil

Con,

Already found a bug, if the pool "goes away" it will never resume mining.  Getting this:

The machine can access the pool, and DNS is fine, but cgminer gets stuck.  Any way you can put something in to exit if pool isn't active (like it used to work)?

This is precisely why we don't recommend anyone run new code until it's vetted.

-Phil

It appears that one die and maybe part of another is not hashing.  This could definitely be firmware related, so let's wait until we can get you some new firmware out and see if we can get the idle cores back in action.

If not, I'll do all I can to see you get a RMA.

-Phil

Con is doing great work, but development is hard, and bugs are inevitable, so this is why we want to thoroughly test everything before we recommend an upgrade.

Still, if you want the best uptime and hashrate, as reported at the pool, you should be running our well vetted 3.9.0h2 version:

Here's the source code: http://setup.hashfast.com/cgminer-3.9.0h2.tar.gz
(MD5: fdef15ae73b180deef74bc51df482eb0)

If you are using our recommended RPI image, this is automatically what you are running.

As of about 15 minutes ago, I'm currently testing a release candidate on my public test system at:
http://setup.hashfast.com/rpi/

Watch the hashrate reported at the pool.  If it stays good, I'll push it out everyone that wants it:
http://eligius.st/~wizkid057/newstats/userstats.php/17ao2fT7gbnnKYpMd7x29E8p4oGdE87Ahd

-Phil

The firmware is being tested and worked on.  We absolutely don't want to give to stuff that breaks your gear or LOWERS your hashrate!

Please bear with us.  It's not like we're sitting around doing nothing.   The protocol guide is open-sourced, and we are going to actually open-source everything as soon as we can.  Con's cgminer is also open-source.  Feel free to write your own code anytime you like, and make look easy!

There are KNOWN BUGS with what are are testing now that we are working though.  There are bugs in what you are running now too, but at least they keep hashing instead of dying off.  What would you rather have?

-Phil