Not wanting to rub anyone up the wrong way... but I have 9 X Sierra units that I'm looking to sell. These are in the UK and as such full UK duty was paid on receipt.

Not certain but believe these to be the only units in the UK.

If anyone is interested in making an offer send me a PM.

Please sell all your BTC.

The paranoid faction who continue to despair over Ghash are the very reason BTC is being held back.

BTC needs strong hands not overly obsessive, I'll informed, paranoid, get rich quick, freedom fighters.

Don't you see  that you would be sending a much stronger supportive message by holding your BTC than throwing your toys out of the pram at every opportunity?

Nothing happened, Ghash are not the enemy, they have invested far more than you and have no incentive to destroy that investment.

Fair enough mate I know it's failure on my part to understand and I do hugely appreciate your work and effort to support it.

I've tried the following:

--hfa-options "NS1:600,NS2:550"   -   No devices found
--hfa-options NS1:600,NS2:550   -   No devices found
--hfa-options clock "NS1:600,NS2:550"   -   No devices found
--hfa-options clock NS1:600,NS2:550   -   No devices found

I guess this either means I have not named the devices correctly or none of the strings I am entering are correct.

I think I have named them all individually but no matter what string I use for --hfa-options I can't get it to load. Can you write me an example?

Thanks

Thanks man... sorry for being the reading retard!

Cheers

Hi Con,

Firstly thanks for all the updates aimed at Hashfast devices, 4.2 has helped a lot.

As all Sierra's are not born equal I need to run them at different clock speeds. I successfully used the '--hfa-name Slug --usb 4:42' to rename one device to later allow me to use '--hfa-options "rabbit:650,turtle:550"'
If I add more renaming to the string it simply doesn't find any device. Can you tell me what I have wrong with the below?

--hfa-name NS1 --usb 1:7 --hfa-name NS2 --usb 2:7 --hfa-name NS3 --usb 2:4

Thanks

I actually think there is a lot of merit in the price rise being down to the amount of BTC being invested in mining gear at the time. Whilst there was a lot of good news, there was also bad news not to dissimilar to what has been newsworthy recently... hacking, theft and collapse of exchanges. Most of the good news was actually following the increase in price where people became aware of their huge gains and found lost coins. The death of SR is over played in my opinion and likely didn't have a huge positive impact on price.

Can you provide a step by step guide to isolating a board because I dont want to start taking this expensive machine apart to end up being told that it was my fault it now doesnt work.

1 machine simply throws the LIBUSB error from startup the other runs for a minute and then throws 'No valid hashes for 22 seconds, shutting down thread.

Both are running the latest frimware and CGminer

Two very expensive machines not working for a week and no response to my emails. I appreciate you have responded here but to be honest expect much more from you. These machines should be on their way back to you to be replaced.

Thanks for the response, any chance of having an email response to my tech support emails regarding my dead machines. Your auto reply claims reply within 1 business day... I count 4 with no reply... simply adding to the damages you have caused being several months late in delivering my order.

Please detail what I should disconnect to isolate a single board to try and determine which is giving me the LIBUSB error.

Nearly a week has passed and not one response to my emails to hashfast regarding my faulty units.

I work in F1 sponsorship, if you can raise a substantial amount I will be happy to facilitate such a deal.

Finally updated the firmware on all machines, looking a tiny bit more powerful than before.

The unit which wouldn't power is now fine.

The unit with the LIBUSB error is still the same after firmware upgrade so looks like that machine isnt going to play ball at all.

I took the lid off and see that the board revision is 1.0 where as the other machine is 1.2.

I've no idea what to unplug / leave plugged to test each board individually.

I opened up the case on the non powering machine and found that the yellow / black connector on the top board was not seated, in fact it's retaining clip was pushed into the top of the neighbouring cap with a dent.

I have managed to seat it correctly but a little concerned about powering it if the cap is damaged?

Well so far 6 emails across 48 hrs to HF and not one reply so RMA is looking like taking a while.

Phoning tech support just gets a 'We're not able to take your call right now'

Hey Thanks CK... I'll see about updating my Ubuntu tomorrow and see if I have any joy there.

Do you think the firmware will resolve the machine with the LIBSUB error?

Losing the will to live here. Having gone through the ballache of installing Ubuntu in order to update the firmware, in trying to update all I get back is this

('confirm is ', False)
('FIRMWARE_DIR is ', '.')
UC_HFU_FILE at './uc3.cropped.hfu'.
READSERIAL found at 'x86_64/readserial'.
HFUPDATE found at 'x86_64/hfupdate'.
ENTERLOADER found at 'x86_64/enterloader'.

HashFast Firmware Updater

Reading serial number from module.
x86_64/readserial: symbol lookup error: x86_64/readserial: undefined symbol: libusb_strerror
Entering Boot Loader...
x86_64/enterloader: symbol lookup error: x86_64/enterloader: undefined symbol: libusb_strerror
Traceback (most recent call last):
  File "./field_firmware_update.py", line 184, in
    firmware_updater()
  File "./field_firmware_update.py", line 143, in firmware_updater
    enterloader()
  File "./field_firmware_update.py", line 62, in enterloader
    subprocess.check_call([ENTERLOADER])
  File "/usr/lib/python2.7/subprocess.py", line 511, in check_call
    raise CalledProcessError(retcode, cmd)
CalledProcessError: Command '['x86_64/enterloader']' returned non-zero exit status 127
Command '['x86_64/enterloader']' returned non-zero exit status 127
Firmware Update had an error.  Please retry or report to HashFast Support.

Same response for a machine that works and the machine that has the LIBUSB error.

So now what?

So after a little over 24hrs I've learned a little and been angry a lot.

Of the 9 Sierra's 2 are useless. 1 fails to power up although did power for a short time today, on connecting it to CGminer it immediately gave an error along the lines of 'Main Board 12V error' and crashed CGminer.

The other problem Sierra was running fine but now does nothing but crash CGminer with Libusb errors.

I've had a few hours of easy running with the other 7 machines but now im having to restart every 20 mins or so.

Whilst the .4 firmware may solve some of this, there appears to be no support for windows users with the instructions only talking about Unix or babyjet users flashing their cards.

Thanks, just crashes CGminer when I do that.

Hi JD, thanks for the reply.

I downloaded CGminer 4.1 to windows 7 - inside the zip is CGminer.exe which I run from a batch file along the lines of

@echo on
cgminer.exe -o pooldetails:3333 -u myusername -p mypassword

I've tried adding in the '--hfa-hash-clock 600' on the above string and it causes CGminer to load and immediately quit.

Obviously I'm a moron for not knowing this stuff so really do appreciate the help.

Can someone treat me like an idiot and tell me exactly where I enter --hfa-hash-clock 600?

Im using CGminer 4.1

I've managed to get 4 Sierra's hashing from one PC, adding more Sierra's just causes it to crash. Is this normal?