Use ~#watch "screen -ls" to monitor any screen sessions starting up and closing. It has a 2 second refresh, so you still may miss it, but it's better than repeating the command. Use CTRL-C to exit the watch.

It' entirely possible that you have the wrong binary on your RPi, and it closes on startup because it doesn't detect the right device.

It's important that you change your "hardware configuration" server side at least twice. Once to something that isn't your hardware type (e.g. select gridseed, if you use zeus), wait 10 minutes, then once back to your hardware. Leave your miners disconnected during this process. Once you have selected your hardware, wait another 10 minutes to be safe, connect your hardware and powercycle the RPi.

The server definitely pushes a different binary when you switch hardware manufacturers. You need to give time for the RPi to pick the commands up from the server and time for the binaries to download. I have no concept of how long it will actually take you to download the binary, so 10 minutes is a safe period.

Are you using a compatible USB2 hub? Try connecting your miner directly to your RPi until it gets picked up and working ok. Further, you need to monitor the power consumption rather than your pool to see if it's mining if you aren't SSH'ed in and looking for screen sessions.

Received another Zen controller last week. I'd like to put it to use, but it did not come with an activation code attached. The instructions still reference using this missing code. I've emailed Eric, but have received no response. Is anyone aware of an alternative activation process?

It's against the BTC mantra to be trusting your coin in an online wallet service that is tied to traditional banking anyway. If you wanted to stay under the radar, you should have played the game. E.g. If you have $50k in cash to deposit in a traditional bank, expect to be grilled and reported if you walked to a teller with that. Instead, make ( deposits of $6,250 to different branches over a 10 day period, random amounts are better. By that same token, you should be purchasing your BTC from multiple sources, and using different addresses withdrawing it, consolidating it to your offline wallet.

The BTC legal landscape is changing daily. While the FED and IRS are slow to react (and even slower to understand) they are reacting. If Coinbase is to stay in operation, they need to be seen as actively following the regulations of their industry. If they get raided and your BTC is seized, what then? It sounds to me like you were just trying to take advantage of USD/BTC moves and got burned. Sucks for you. 

I am aware of what a default config is. This was something different as my pool information was actively being disabled and replaced after mining had commenced, even if I reentered the details directly into the client. Their cloud backed was jacking my controller remotely and making it mine for it's original owner. Being sold a new used Zenminer, in addition to being connected to a service that isn't fully developed, missing promised support for devices I had -- all of this led to what happened.


There needs to be some reasonable protection against customers or other potential bad-actors trying to hook additional unauthorized RPi's into the zen cloud, I don't think a serial number is enough. Perhaps a MD5 hash of the MAC, activation code, and serial number could be enough. However, if the SD card or OS on it get's hosed, you don't want customers to be without their controller when they can just reflash. A custom serial would make that process difficult. The customer will need to understand that use of the service is tied to that specific RPi. It's no more complicated to switch an RPi out with another RPi than it is switch an SD card from one unit to another. I personally don't see it as a burden to require that particular RPi be used to use the service, and at the same time it provides some level of protection to Zen. I will say that I don't imagine their community of users will ever be so large that the resale market becomes too much a burden for support to address.

Once Eric explained that the activation was tied to the MAC and that I was sold a new used ZenController from GAW  , it made sense. Except that it should not have been able to put my pool details in if it wasn't registered to me. It was clear at that point that some mechanism was missing and Zen had allowed the device to be registered to two accounts. I can only hypothesize that because GAW had the device first, and their registration was older that it would write my pool, then override it with theirs as the cloud backend cycled through customers devices. That is why I suggested to Eric that Zen add in a safeguard to prevent MACs being re-registered in their system.

While I'm still very frustrated with my experience purchasing equipment with GAW, I will say that GAW and Zen did work together to quickly identify and resolve the bug in their back end. Eric was reasonably forthcoming with information about how their service works and how this happened. After our chat, I confident this a beta software issue rather than anything malicious.

I'm awaiting a new build of the Zen firmware that is supposed to resolve my specific issues. When I receive it and am able to test it I will report back.

Yes, of course I'm open to solving the problem. Contact me via email with how I can help. We will take it from there. 

I've put in like $6000 worth of orders from them. They are a little slower than competitors, but good customer service. They haven't scammed me out of any money, just shipped out my latest order a week late and seems to have no idea why. 

Writing often lacks the intonation that accompanies speech. I said 'demand' in the context of 'asking for information from an entity' vs the more literal translation of 'requiring instantaneous response'. That said, I still stand by what I said.

Have any of you seen my other topic?

https://bitcointalk.org/index.php?topic=650228.0

I've discovered Zenminer replacing my pool information with theirs on the device side and deleting my pools, causing my blades to mine for Josh. Maybe I'm misreading the situation, but, it's probably for the best if you at least check it out and weigh in. 

I've been waiting to hear back from you for a week about Gridseed support, and you have been nowhere to be found, but 15 minutes after I post this you are able to investigate and reply.  

Your story is so full of holes it really stretches credibility. My device *is* connected to your service and *did* receive it's pool information from it. I never inputted anything in regards to pools on the actual device. I changed the pool on the website, and when I rebooted, my new pool was there in the mining client. The very first time I accessed my device via SSH, before I installed gridseed support, I saw my pool listed in the conf file. There is no initial configuration which has your pool already in it that I can find. It's not until after the mining client has been running for a bit and opens the API that the Josh's pool populates in there. It also doesn't just populate in as an extra pool, it specifically disables and then deletes my pools after it has been added. That is vastly different than say Hashra's RPi binary shipping with default pools already configured.

Here is the real sticking point for me. You say that you've only just now done a scan to find affected customers and contacted them about this issue. Only, you've also been working on it as your overriding priority. Regardless of your '*zero* malicious intent' -- that still means that you've knowingly let your customers mine for someone else without their knowledge or consent this entire time (12 days?). However, you come out and promised to notify customers and be transparent only after you've been busted publicly.

What does 'Full Responsibility' mean to you? Refunds? Credit for lost mining time? Payments for misappropriated mining time?


Obviously, I'm one of those affected customers. My device is registered to my primary email address. Yet, I have nothing in my inbox and no messages on my zenminer page indicating anything about this. Are you sure you've identified everyone AND contacted them? It doesn't seem like it to me.

You should have been transparent from the beginning. You should have given device access from the beginning. You should have told us the launch problems meant we were mining for someone else at our expense FROM THE BEGINNING. Get it now?

Update 6/19/14: Although I have been unable to test out a current image, what was happening appears to be isolated to only to me, and having been corrected on the Zen back end should no longer effect me. Eric has worked with me in a capacity that was unexpected to say the least. Having spoken with him on the phone concerning this matter, I am genuinely confident that any impropriety while unfortunate was also completely unintentional.

I believe the road ahead for Zen is both bright and exciting and look forward to fully transitioning my farm to their platform. To any wary souls who might still be hesitant because of past events, I say that you have nothing at all to be worried about, and that you would be doing yourself a disservice by not giving Zen the opportunity to show you how great they can be. Any who so desire may reach out to me personally about this for reassurance.


I am leaving the post below intact for posterity, but know that it no longer reflects my attitude toward Zen and Gaw, and I believe that they more than deserve the benefit of the doubt from anyone still harboring reservations. Because this issue has been resolved, and because I do not wish to see undue harm come to the nascent company, I am locking the topic and letting forum slide do the rest. All further discussion regarding the Zen service should be directed to the dedicated topic or dedicated forum:

https://bitcointalk.org/index.php?topic=628615.0

https://hashtrader.com/

Moved to new topic: https://bitcointalk.org/index.php?topic=650228.new#new

I checked it, and it's got (2) +12v terminals. It's in the shape of a 4 pin mini 12v aux connector. You see it on the bottom left on this board here just behind the power jack:





It doesn't need to be either or, using both will divide the load, but I bet it will hold on it's own. The new connector might be so they can integrate multiple blades in a larger product. It's locking, so it would be more reliable than a 2.5mm power plug.

Also, based on the sticker that was on my other blade, these were manufactured this past week.

See my email exchange below.


It's been a week, gridseed support is nowhere to be found, and zero communication coming from Zenminer about the issue. If "by the end of today" means more than a week, I wouldn't hold your breath for "API access at a later time".  

Eric, this is bad business. If you don't have it done by your own deadline (or shortly thereafter), nut up and post why. Silence pisses off paying customers. When you say nothing at all, it seems like the work just isn't important enough for you to get done, in which case, nobody should bother with your service. You are doing *something* during the day, and it's been a fucking week. Explain why it's taking so long & fix the support advertised, or start issuing refunds. This isn't some kickstarter project you can just blow off when you don't feel like working. A product was sold with implicit functionality that doesn't exist. I don't know what it is about this damn community where endless delays, missed deadlines, and zero communication have become accepted behavior in business.

http://www.coindesk.com/bitcoin-mining-manufacturer-hashfast-enters-chapter-11-bankruptcy/ <-- Is what happens to companies that behave like this.

Good business is (in order):

• Delivering working products on time
• Promptly handling returns of non-working products
• Good customer service
• Staying connected with your customers.

GAW has great customer service, and they are well connected with their customers, but it took them over 2 months to credit me for defective equipment, and when I used that credit to purchase a blade, it shipped a week late. Part of that purchase was a Zenminer that was sold to me as running the blade I ordered. Now I have the blade in hand and the Zenminer doesn't work.

Put yourself in my position.


I'm not aware of too many privately held companies that disclose all of their employees or the internal working of their company, such as what other avenues they might be pursuing. In that respect, I'm not sure it's reasonable to demand that information.

That said, I do believe they are sorely in need of more transparency and better support. It is an alpha product, which clearly wasn't ready for release, but people get dollar signs in their eyes, and throw caution and process to the wind.

They can't enable remote features and functionality through their website without access to your device. That means they will always have access to do nefarious things should they choose to. You should have recognized that from the beginning, as the remote access is the only real selling point of this product.

Also, Zenminer is a division or subsidiary of Gaw miners.

As Requested: 

I just got a new blade in today, and the board design has changed again. They added solder pads in for a 4th mosfet, but no chip, and added a 2nd red LED that seems to just come on with 12v. Maybe some headroom can be had by adding in the missing mosfet. Seems odd that they would redesign the board with that pad, but then not actually solder one in.

Do you have any CFM specs for the fan? Seems prudent to replace it with a better model before it fails. How has the choke held out on your board? On my blades, the choke is getting pretty warm alongside the mosfets.

Thank you. It was a misplaced comma that was causing it quit after launch. Stupid.   

Anyway, after fixing that, it just started hashing right away, normally, no rejects or any problems. I have no idea why that same config, minus the stray comma, was causing nothing but rejects yesterday.   

Thank you.

Unfortunately, none of that helped. Even adding the Kernel-path setting (modified to my SGMiner location of course) didn't resolve the issue. I tried it both with the 06062014 and the 09062014 builds. I tried it with my config, and it would close a few seconds after opening. I tried it with your config and it started, but still threw endless rejects. I tried the path with both single and double back-slashes, no difference. I deleted the .bin files, no effect. 

I am using driver 13.11, with other stuff (e.g. Catalyst & AMD APP SDK) installed. It's been super stable for months like that though mining Scrypt & Scrypt-N with an older release of SGMiner.

Any other thoughts or suggestions?

I've tried using the same build and the same copied 280x conf of yours, and all I'm getting is rejects, HW errors, & "Share above target" for X11 & X13.

X11 & Scrypt-N works under my conf, but Scrypt-N slow as balls at 173KH/s vs 1.83Mh/s it's supposed to be, and X13 Still produces 100% rejects & HW errors.

I'm missing something. What O/S & Driver versions are you using? Ram size & VM setting?

What voltage/resistor combo were you running when this happened? Did you have active cooling on both sides of the ferrite bead? The 470uF 25v replaced the 220uF 16v?

Using a larger size cap causes somewhat higher current draw during it's charge phase, and may exacerbate the problem. If the charge phase is the same length of time and the capacity is double, it will pull twice as much current to charge it in the same period of time. You might perhaps be better off running (2) 110uF caps in parallel. Same capacitance, half current draw per cap & twice as much surface area for heat dissipation. That should cool them down considerably.

SMH...

Did you bother to look at the PCIe pin out or did you just solder your +12v to the top 4 wires? You're lucky you didn't short out your PSU.

It didn't power up because 8 Pin PCIe has the same number of +12v lines as 6 Pin PCIe, (3). 

It has 2 extra GND wires instead of +12v & GND. 8 Pin EPS on the other hand, that has (4) +12v & (4) GND.

I don't know what wattage you are working at, but also bear in mind that 6 pin PCIe is only rated for a conservative 75w. You could likely go to 125w before exceeding the pin rating, but be sure your wires that are feeding the pins are at least 18AWG. 22AWG, which is common on some of the cheaper connectors will melt.