Was it used? Who was the seller? If it came preset that high, it was probably a used stick because factory default is 1.25V and factory seconds weren't set higher than 1.40V

The problem with new chips is you then have to make 'em work. You know I had initial data on BM1387 in February of last year but the NewPac didn't roll out until what, August?

I mean if I had any sort of team, sure it'd be easier but I'm literally the only technical personnel at the shop. I spend most of my days doing testing that others can't, or fixing machines that others can't, or actually building the tools we need to get stuff done quickly and efficiently. Came in last weekend to cut, punch, braze and grind a sheet-metal template for use punching jack holes in hub lids. Next week I'll be setting up a better hydraulic press for it, and in the meantime I'll be building a new shear tool to make cuts on R606 housings and reworking the isopropyl filtering/distilling setup so we can keep reusing that stuff in wash cycles to save money (the good stuff is $16/gallon). The only reason the R606 project got off the ground as fast as it did is because I was laid up with a broken leg and couldn't do floorwork for over a month so design was all I had left. That, and one of the CNC machines was already set up for cutting aluminum sheet because of the hub project so all I had to do was draft the case design and program in all the toolpaths, no jig-building.

I've got newer chips. I just don't have the info to make them work yet. And I have three products to manufacture right now, which means seller communication, scheduling, testing, parts procurement etc so I don't have time to reverse-engineer existing hardware to get that info just yet.

But things are getting lined out at the shop, and my crew are already pretty hands-off with NewPacs and hubs, so once the rest of hub and pod tooling is in place that'll free me up again. Should have an improved stick and maybe a better pod later in the year.

So, I finally got my hands on one of the pods with red blinkers the other day. Looked like the temp sensor had released the magic smoke somehow.
Yesterday while doing some further testing I was able to release the magic smoke on a bench unit. Admittedly that board is cursed in more ways than just that, but I did see it happen.

My guess is the temp sensor is not as 5V-tolerant as the datasheet led me to believe.

I am currently final-testing the first set of pods to get the new firmware which can tell a difference between an error condition (such as a roasted sensor, or reporting negative temperatures) and an overtemp condition. When overtemp it still blinks every second like normal, but if the sensor is bad it blinks once every five seconds. This is to let you know the sensor is bad so it can't warn you of an overtemp condition, but without getting in the way of being able to adjust voltage and is much less annoying.

The next batch of boards had already been delivered when I did this testing so I'll have to do a bit of manual work to patch in 3.3V to the temp sensor instead of its 5V line, which should save them from roasting. I have one with that fix applied that's been running off and on all day with no issues so far. Batch 3 will have the fix integrated to the PCB.

I also noticed a small error (two parts interchanged) around the USB chip which might affect stability or device detection if your USB cable is long or bus voltage is low. Shouldn't affect most people. The new firmware also addresses a small memory overlap in EEPROM which won't affect most people but shouldn't be there regardless.

I will be making the new firmware available to resellers. It requires physical access to the hardware to install, and firmware alone won't prevent the temp sensor failure - it'll just react differently to the failure. But all Batch 2 units will have both the software upgrade and the hardware fix. I think we've pretty much found and fixed all the problems now, so assuming everything tests out okay, I'm quite comfortable with Batch 2 units being sold overseas.

Once we're into Batch 2, or Batch 1 units sufficiently modified, I'll let everyone know the starting serial number after which units can go anywhere.

If you're hitting 725MHz on volt 5, it's a freakin' fantastic unit. A "weak chip" situation would mean you'd need volt 5 just to hit 600MHz. Remember, stock freq on an S9 (with the same chips) is only 650MHz.

Also since the barrel jack is only rated for 8A, I thought it somewhat of a conflict if I sold or recommended a brick that would put up more than that. Especially with a 6-pin right there.

Regarding "lower clocks and settings", the thing's stock is 750GH and 8A should get you well in excess of 900GH. All the units I ran for statistics broke 1TH before they broke 8A; that was short runs so I can't guarantee they were stable but that doesn't sound like "lower clocks" to me.

No. Gonna have to wait a bit longer.

I have received a miner with the red-blinking issue as a customer return. This error is especially annoying to me because, though I have run these things for cumulatively many thousands of hours, I have yet to see this issue AND YET it's happened to upwards of five percent of the miners shipped out.

I don't know if it's universal since I only have the one data point, but what I see on this guy's miner is the temp sensor looks to have let some of its magic smoke escape. This is problematic since the part is rated for 5.5V and nothing over 5.1V is going into it.

Right now the firmware sees a disconnected/nonresponsive temp sensor as responding 0xFF on a temperature read. Since I'm lazy I didn't put a check for this error into the original firmware, and since I also didn't use signed integer math, 0xFF is read in as 255°C which is decidedly higher than the "max safe" setting of 74°C; anything 75°C and above causes the "your machine is too hot" blink.

So what I plan to do is update the firmware with some additional conditioning and if it sees a temperature so ludicrously far out of expected range (which will include the nonresponsive 0xFF) it'll do a single blink every five or ten seconds to let you know the temp sensor is malfunctioning, but not the annoying/obtrusive continuous "too hot" blink. That way the user can still adjust voltage in a rational manner and not be super annoyed, but also know when the internal sensor isn't working right so be careful.

I'll also make a change on the next batch's PCB to put the temp sensor behind a 3.3V regulator, reducing the likelihood that it decides to spontaneously erupt shortly after leaving my facility.

The updated firmware will be made available to resellers, to improve service to customers who have already bought these miners. It'll be applied to everything shipping from me from here on out.

Didn't you email about a purchase a while back? Was that not followed up on?

I'm skeptical that "win10 pro" actually exists. The last truly professional [non-server] OS Microsoft put out was 2k.

550 is not "training wheels", it's stock settings. I verify they work at stock, and then I sell them to you and you run them until they catch on fire but it's not my fault because I know they worked at stock.

Yeah but then you're stuck running Windows 10.

My testers are old Dell 755 machines I bought from a surplus sale for $13 apiece and loaded with Debian 7. I've run 10 pods at a time at 550MHz stable.

So S7 controller won't take S9 firmware?

The short answer is "no, the algorithm is built into the hardware. This has been the case with all ASICs since the beginning of ASIC mining."

The long answer is "yes, but..." where the "but..." involves a workaround using special pools that have you mine one currency but pay you in a different currency with payout rates depending on exchange values and the like. There's probably more about that in the Altcoin board, and also Rockmoney (who sells these guys on Amazon as MinerSupply, which may have been where you got them from to begin with) has a decent writeup somewhere for how to set that kind of thing up.

Not sure where you are, but I've got at least two, maybe three S9 controllers on a shelf. Probably got some of the fully loaded S7 controllers Phil just mentioned also.

Could be then. The 5V on the R606 is the same circuit as powers the D/1 (weaker) port pair on the metal Gekko hubs so it's good for 2-2.5A while the main ports on the hub will push 6A per pair. Not sure what the power draw is on a 7" screen but it's certainly a lot more than zero.

Weird that it wouldn't boot. The Pi I've got for testing is pretty old, but I've only ever run it powered off the pod while testing. It can't be that the miner's 5V is no good, because that also powers all the lights, the onboard controls and USB communication. Depending on the Pi model, it might be asking for too much power; some of the newer models, I'm told, can draw as much as 3A.

Try a higher voltage setting first. If it still throttles low, it's more likely the controller than the miner.

Speaking as not just a seller but also a manufacturer working 11-hour days for the last eight years or so - patience is a virtue. Rockmoney's usually up to his eyeballs dealing with all the various garbage Amazon throws at its sellers in exchange for the benefits of an unfair marketplace that embraces counterfeiting and withholds payouts for weeks at a time and can't always be relied upon to answer emails within a few minutes. But he'll take care of you if you let him.

And if he doesn't, I will.

It's possible your miner is the one he was discussing with me this morning.

Wes0310, according to the device line, cgminer is only detecting 1 chip on that stick. If it's brand-new (just received), it's probably damaged and should be replaced. If it's not new, could be the voltage is set way too low and it's not picking up properly, or the voltage is set too high and it's overheating.

Adjust the voltage up a bit, make sure you have good cooling, and try it again. Sometimes an unplug-replug will take care of that.

gt_addict, I had similar issues with temp sensors not reporting on some advanced-controls prototype sticks last summer but chalked it up to the firmware. This one's code is much more robust, and when I first got temp sensors going I let one run for a week without any hiccups. But something's for sure going on, and the "quick fix" is just disabling that part pending a redesign. I can probably get the same functionality out of the microcontroller's internal temp sensor, though it's not as close to the heatsinks so won't read out the same which is why I didn't want to rely on it. Might have that implemented before Batch 2 starts shipping.

Additionally, I have a couple pods here that, on volt setting 4, could only hit something like 535MHz but were otherwise great. So everything will be tested at Volt 4 but with a second round at Volt 5 if it's only a few percent low. We did a similar adjust-retest for the weaker 2Pacs and nobody complained.

kingofhammers - maybe I'm a little biased on account of how much work went into case design and manufacture for those guys, but please just get a not-stupid power supply. Unless you can guarantee the combined housing you make will be appropriately awesome, in which case PICTURES!

cliftonk - keep working with the reseller to diagnose what's going wrong. If you do end up getting a replacement unit, let the reseller know I'd like it shipped straight to me so I can figure out what the heck is going on. I've been thinking about it for a while now and there really are no links between a blinking-LEDs and a zero-chips (those are two almost wholly separate systems). Unless the main regulator died in such a way that it took the volt-setting pot with it, and that's screwing up the I2C bus the temp sensor's also on, which is a series of unlikely failures. There's enough anomalous about that thing that I want to look at it myself.

Also, I have reports of at least four pods with blinking LEDs. The temp sensor was the part of the system I trust the least, and it's also doing the least, so I'll probably just cut it out of the firmware effective immediately and probably not even install it on the next batch.