Honestly I don't know what could be causing all those problems. Thought maybe the onboard 5V was wigging out, causing the USB chip to cycle on and off which would explain the disconnects, and also cycle the microcontroller and temp sensor so it keeps starting up to invalid state and blinking. But the timings don't make sense.

It's unlikely to have a bad temp sensor causing the blink. It's at least as unlikely to have a zero-chips-detected issue. It's basically impossible to have both. Did someone play baseball with it or something?

Gosh dangit, another one? See I've run every single one of those pods at least six separate times during different testing steps, including a burn-in test for 24 hours, and have yet to see it happen once.

I'll work on a firmware fix that makes "temp sensor is no good" blinking distinct from and much less obtrusive than "temperature is too high" blinking. And figure out why the heck the temp sensors are failing in these things. Heck I may just get rid of them entirely.

Also when I say "firmware fix" I mean literally a code change for the onboard microcontroller. What makes lights blink is completely independent from cgminer.

By the way, that condition's already been talked about so looking back in the thread a bit will catch you up.

Gross. Most of my mortal enemies are left-handed.

No it wasn't deliberate. No I'm not changing it.

Windows 10 sucks forever. Unless you've messed with the stick voltages (or there's no fan on them), there's no electrical reason they'd run that poorly. Every stick is tested to 200MHz on stock before it ships, and most of 'em will do upwards of 400MHz on stock voltage if they're kept cool. That's why I put a fan header on the hubs.

Please tell me you got a fan on 'em.

Solid green means it's getting power. Blinking white means it's hashing. All of my miners work that way - solid color for general power, flash of white while mining (and blink rate generally proportional to hashing speed).

On the R606, the power light is orange and the white blinks are timed more like 2Pacs.

No firm dates, but I intend to order next-batch PCBs in the next day or so. I want to make a few internal changes to help smooth out some testing steps, nothing that'll affect the end user, but it's not a simple re-order.

The obvious solution is stop using Win10. That'll make literally everything better, not just mining.

But hey cool, good there are options. Thanks for the explanation.

mstrozier, good to see it's up and running well. ~700MHz on volt 5 is pretty good. Setting 3 is approximately the same as a NewPac's stock.

Not until the second batch. Right now since it's brand-new I'm keeping things close to home in case there are unforseen problems.

That's decent numbers. Volt 5, volt 6?

I might have to update all the testers to this one. We still have the occasional problem with a bad NewPac killing cgminer and stopping a 24-hour run on a whole hub.

VH, can you explain a bit more about 2-midstate AB? Why that option might be necessary or beneficial over regular (4-midstate) or no AB at all?

If one of the chips is not getting enough voltage to run at a set frequency, that's what causes the ASIC plateau or missing nonces, and the auto-tune does its thing. There is no "so it shuts down".

As mentioned already, nothing in the code makes it shutdown except a specific user command. What's likely happening is some noise or data on the USB bus being erroneously detected as that shutdown signal. It's not deliberate.

I have yet to see an issue similar to that with Terminus, but it happens occasionally on a NewPac testing station when there's a faulty stick dropped out and cycling. I am therefore not surprised to see a "shutdown signal received" adjacent to a "toggling to reset". I am surprised to see an R606 needing to be reset so frequently though.

Kingofhammers, I may have you send me one or both of those miners for some testing and repair or replacement. Temperature detection and blinking the LEDs was the last thing put into the firmware so error handling is less robust. I can probably fix the temp sensors to start reporting properly, and maybe use one as a testbench for removing the blink if the temp sensor reports an error condition; right now it can't tell the 0xFF of a disconnected/unresponsive sensor from a reported temperature of 255°C.

But if you don't mind the blinking, and they're still mining as expected, I'll leave that up to you.

The blinkly lights has nothing to do with power or communication. It's an issue with the temp sensor, which is connected to the onboard microcontroller, which is not affected by voltage or USB anything.
Just to be double-clear, the white light is flashing while hashing on all of them, but on two of them the red volt-setting LEDs are blinking?

Without ASICBoost, the theoretical peak speed is about 575MHz (~800GH) on a wide-open USB bus. If the bus is shared out with something else and/or the processor is slow and timings aren't perfect, it'll be less than that. See the guy above whose pod, without AB, only saw about 500MHz. This is a USB limitation completely independent of core voltage setting. You may need to get a system working with AB, or plug into a more powerful controller, to get stock speed.

As long as they're still working correctly (or at least satisfactorily), figuring out what's going on might be purely academic. If you want to test the voltage setting, measuring between ground and any of the test pads adjacent to the per-node capacitors on top (they're yellow) while pressing the up/down buttons will tell you if voltage is getting set right.

There are no direct testpads for the I2C bus, but there are a couple high-tie resistors could be probed. I've already planned a PCB revision with increased test points, including an optional pin header specifically for sniffing the bus. Hasn't really been necessary yet, because in literally every test of every prototype and production miner so far, it's all worked.

Only real problems, besides it being annoying to have lights blinking at you unnecessarily, is that if it does overheat you won't know, and that the DPOT for setting the voltage is on the same I2C bus as the temp sensor so if it's an issue with the bus the voltage might get set erroneously or not set at all when a button is pressed. The firmware sets the starting position in non-volatile memory on the pot so it'll always start up at the last setpoint.

No that was a response for the guy a few steps above that's having an issue with the temp sensor. Your question popped up while I was typing advice for the two guys before you, so your answers are at the bottom.

Could be an issue with the temp sensor. It's weird that I've tested seventy of these things and not seen any problem and you've got two of them doing the same thing. Usually when multiple anomalies coincide I start to question the user before I do the hardware.

I'm guessing you power-cycled the miners and the issue persisted, otherwise it'd be barely worth mentioning.

mstrozier - there's no such thing as "too much voltage" unless you're getting too much heat. Set the voltage and let the auto-tune do its thing. If it's not where you want it, step up the voltage and start over. Don't freak out that it's not perfect in ten minutes. Auto-tune can take a couple hours to flatten out.

The USB bus is not connected to the temp sensor at all. That's also why there's no software voltage control. Maybe on the next one.
This is a USB2.0 device but because of the timings and data throughputs required it's fairly sensitive to busy lines, especially without ASICBoost, as has been stated a couple times already.

I would expect more than 600MHz from volt 6. Must have a pretty borderline chip in the string.

I know miners like to be cool, but make sure it's not too cold. I noticed yestereve that my shop was getting a bit chilly, and every R606 on the tester had a - for chip 0 status; chip 0 is right in front of the fan.

Trust VH to catch that detail. I missed from the pictures that it wasn't running AB. Because of how work is handled internally by the chips in ASICBoost mode the USB throughput is more efficient. On my system it maxes out around 575MHz, which is why I set the "stock speed" at 550MHz - because 750GH is a nice round number than should be attainable without AB. Probably your controller has a bit less efficient USB path or something and that bottlenecked it more.

Good to know it's not the machine.

If anyone's wondering, it's issues like this that I haven't opened up international sales on the R606 yet. I want a better picture of what could go wrong and that's easier to do when shipping times are short and the customer speaks English. These have been moving for a couple weeks now and there haven't been any real concerns yet so that's great.

Widescreen it to get the chip health display and see if you have one consistently misbehaving.