News about high failure rates doesn't surprise me much. I've been doing some learning on S17/T17 hardware a bit lately.

They have substantially improved airflow and heatsinking in ways which should have been obvious to them in 2015. However, depending on the model of miner, they're pulling anywhere from 14 to 21 watts PER ASIC, from the same 8x8mm package size and footprint they've been using since the S9. The package is improved with a huge exposed die for better top-cooling junction/sink connection but that's still roughly double the power per chip compared to previous miners.

No, 12 would be the 12th chip (indexed as chip 11) at the other end of the string. It would have been replaced before re-testing. I may be remembering a different unit but I believe that chip was having trouble breaking 400MHz.

If there's a number on the heatsink it's the bench serial number used to identify them during assembly and testing. Once they're done testing the final step is re-flashing with the unique serial number and another quick test before packaging.

If something fails test I'll make a note of the problem so I can fix it. The "12 slow" means the last chip in the string was dropping speed during burn-in, so I took it apart and replaced that chip then ran it again.

Also make sure there's not a config file overriding your command line settings.

gt - chip 0 is on the end closest to the fan. The string pulls a U-turn, so it's 0-5 from right to left along the front, then 6-11 from left to right along the back, with 0 and 11 closest to the fan.

Wilco - I long ago gave up complaining about extra fans. I'm generally confident that the one is sufficient, but then I generally encourage tweaking and also don't know everyone's operating conditions so as long as nothing gets torn up I shouldn't say anything.

Also read through the first post of this thread. VH made some gekko-specific options that target individual miners by serial number.

gt - I'm guessing it has a lot to do with that the miner's only detecting six chips.

Factory burn-in is done on a Debian machine.

The company that makes the above light also makes a similar one with zoom. I've got samples on order, should arrive in a week and some so I'll be able to play around with 'em. Prices are pretty reasonable.

Thinking about picking up some of these for the basic non-zoom version. It looks to fit my liking better than the 501b body I already have to play with; this one takes the same kind of drop-in but doesn't have any of those annoying sharp edges.



One issue with that drop-in module is heat dissipation. The flashlight body is aluminum so should be good for heat conduction, but because of how things are mounted internally there isn't a lot of contact for conduction. In the old incandescent-bulb flashlights, this was a feature, but for LEDs it becomes a problem. With that in mind, it'd be difficult slash potentially unsafe to operate at the top end of the power range without making some modifications to increase heat transfer into the flashlight body. Something like a 500lm/1.3A setting I imagine should be fine, but the 2.5A top-end won't be practical for more than a minute or so.

The microcontroller has an internal temperature sensor so I might code in a thermal limiter that ramps down current or turns it off completely above certain temperature thresholds.

Also, prototype PCBs have finally shipped and should be here on Monday so I can start proper testing.

Six sticks at 600MHz or so, if you can give it enough 12V power.

Might have to do some work with a buck-boost driver instead of just a straight buck driver, at some point. Since the LED and current resistor are expected to drop around 3.2V at full current, but the battery can run down to around 2.7V, a buck-boost driver would be able to keep the LED voltage high (maintaining brightness) even when the battery voltage slid low. I'm reading up on a part from Texas Instruments that might do the trick and would still allow 2.5A of LED current at the top end, though it might have to be reduced to 2A at the bottom of the battery charge since input currents to the driver are limited and Pin=Pout. But since the micro is capable of monitoring battery voltage, that could be implemented in software, and then we could set a minimum cell voltage where the LED is disabled. In that way it'd behave like modern lithium-battery power tools, where they work and work and then just turn off instead of winding down. Total system efficiency would be a few percent worse than a straight buck driver, but it'd allow better utilization of the bottom end of the discharge cycle and maintain brightness longer.

Course, going that route would mean completely redesigning and prototyping everything. Software would require minimal changes, but hardware would be completely different. The pin pitch on the chip is too small for me to readily prototype with the tools I have available right now but it's within the realm of what we've done here before, I just have to find the rest of the equipment.

If it's not the computer, it's either the hub or the sticks. Increasing the stick's voltage slightly will probably help. Knob's in the bottom corner; clockwise goes higher. You'll need a tiny screwdriver or equivalent tool.

I'd rather send you something to play with first and test it out, see if it's any good. The first proper prototype PCBs won't be here until next week and I have only one of each housing so it could be a couple months before there's a purchasable product. This thread is describing what I've already done and what I intend to do, and a request for comments to try and make it better.

Electric cars do it because the average trip distance is only 30 miles so reduced capacity is usually acceptable but the sooner you have to replace the cell, the worse because they're very expensive. Additionally, the last 15-20% of charge takes about as much time as the first 80% so squeezing in the last drops will double your wait time.

I considered a partial charger versus full charger and figured that, for something like a single-cell flashlight, people would tend to prioritize battery life over battery life-cycle. Replacement cells are not expensive, but everyone hates a dead battery in a flashlight.

I had already considered putting, say, a jumper or switch on the charger to change modes from full charge to 85% charge for people who would rather extend battery cycle life. Since current and voltage are software-controlled it'd be pretty easy to implement and add almost zero hardware cost.

Thanks for the input. I was just about to say, I tried to make the writeup as thorough as possible but nothing is set in stone. I came here to talk about it specifically to get that kind of feedback, and see if there was anything I could do better.

Usually if you can't change the speed there's an issue with either the command line or config file overriding your setting. Sometimes you're changing it in a script file that isn't what gets run.

Building a Better Flashlight

Here's a link to that flashlight design discussion. Now we can stop talking about it here and aggravating mods and people who actually want their R606 needs serviced.

Hey guys. I'm sidehack. Haven't ventured over here before; I have lived in the Hardware section for the last seven years or so.

My small electronics company is probably known for being one of the first to make server supply breakout boards, and one of the last to still make non-industrial miners. All my products are designed and built in-house in USA, including parts population, metalwork and machining.

I spent some time end of last year thinking about LED lighting and cooked up some custom fixtures for the new shop I spent last summer and fall building. That got me thinking about an old and largely unsatisfied desire for a durable non-stupid LED flashlight. Around 2012 or 2013 I spent a fair amount of time trying to find a single-cell 18650 flashlight, pocket-sized (which means no big goofy head), with about 200lm nominal output, simple modeless on/off, in a durable aluminum housing, with adjustable optics and no jagged edges. Found exactly one product that met all my specs so I bought two of them. One burned out and the other was stolen. I have found a few places somewhere in the world listing it for sale but I'm not convinced new ones have been manufactured since about 2013.



I had, before finding that one, settled on a different light that met most of my specs. Single-cell 18650, pocket-sized, about 200lm nominal output, simple modeless on/off, in a durable aluminum housing, but a fixed reflector and jagged edges on the head. Still, that's pretty good.



My biggest beefs with the mass of already-available "tactical" form-factor LED flashlights center around all the annoying strobe multi-modes and that they've always got those sharp-cornered protrusions around the lens which are just asking to scratch every available surface and wear holes in your pocket fabric. I really REALLY don't want either of these features and yet they appear to be essential.

So fast-forward 8 years. None of the electronics still work entirely but I have the complete housings. I also have a lot more design experience and some electronics assembly equipment. Maybe instead of spending time trying to find a flashlight that someone else built which meets my apparently very unique requirements, I should build it myself. And then perfect it and make it available to anyone else who also wants one.

Regarding housings

The first (and better) housing, the C84, the "pill" is aluminum and threads into the main housing, meaning lots of solid contact for heat dispersal. The head is lensed and slides to adjust the beam width. It's pretty nice. Unfortunately I have yet to locate anything even comfortably equivalent on the market so acquiring something equivalent might have to be a custom job.

The second light, the 501b, has a fixed orange-peel parabolic reflector for a fixed-spread beam. The "pill" is brass and mounts on beefy spring contacts which are great for grounding but not as great for shunting heat into the case. I already know I can get those housings and the mechanical innards in bulk from a Chinese manufacturer for not a bad price. They're kind of a "generic" design apparently because I've seen a lot of different brandings of the same thing. Chinese sourcing is less than ideal since I prefer to do as much American business as I can, but this project is just getting started.

If possible I would like to request custom machining of the 501b lens end to make it a smooth ring and get rid of the half-dozen fingers. Something like that might be negotiated for batch orders of sufficient size. I already know they'll do custom logos.

Regarding electroncs

The standard driver board for LED flashlights is a 17mm circle that fits inside a milled billet, aluminum for the C84 and brass in the 501b. Bottom side of the board will have a spring contact for the hot terminal of the battery; bare contacts or castellated holes around the circumference conduct ground to the billet, which grounds through the button to the battery's negative terminal. The LED is mounted on a separate board adhered to the other side of the billet, which serves as a heatsink. Wires run from the LED disc through a hole drilled in the billet and are soldered onto contacts on the driver board.

I currently have two LED options to play with: CREE XM-L2 U2 5mm lensed LEDs which can handle a practical maximum of 3A and put out in the neighborhood of 400lm per amp (300lm/700mA, 500lm/1250mA, 840lm/2500mA) and some baby CREE JB3030 3mm unlensed with a practical max of 240mA and peak around 120lm.

I have a functional prototype DC buck driver which can work from the 3-4.2V output of a single lithium-ion 18650 cell. The driver will be built to handle 2.5A through the LED, and internally uses a PFET for the high-side switch which means 100% duty cycle low-dropout mode when the battery is at the bottom end of discharge - that is, the light will get dimmer rather than turning off when the battery starts to die.

The driver is designed with a microcontroller to continuously monitor LED current draw and adjust the buck driver's output voltage to reach and maintain target current (which means target brightness) as conditions like battery voltage and LED temperature change. The software is coded to do a soft-start rampup which brings the light from "off" to full brightness in no more than about 50 milliseconds. What this means is the brightness can be set in software, by giving the calibration routine a particular current setpoint to target for. The flashlight, then, can be configured for different brightness from around 50lm (brightness can be unstable/jittery at low currents due to circuit optimization for high currents) to 800lm without modifying hardware.

The microcontroller is wired such that it can monitor battery voltage and turn the light off completely if the battery reaches a certain state of depletion, preventing harmful deep discharges. I have not done this; just noting that it's possible.

Regarding modes

Now I've stated pretty clearly that I hate multi-mode. I don't want all the BS of accidentally cycling into some dumbass strobe when I'm trying to look at something. Just want on and off.

However, multi-mode wouldn't be found in almost literally 100% of existing products if it wasn't, for some reason, a popular feature.

The driver I'm building is designed, therefore, to allow multi-mode capability in software.

Mode switching happens by pressing the power button quickly. What this does is actually power-cycle the LED driver circuit. There is no extra contact for half-presses or anything, it's just a quick power-cycle because the switch doesn't latch off. The driver circuit is designed to notice a short-duration cycle and, upon returning to power, advance to the next mode. My driver will be capable of doing this, and I'll probably write a basic program to implement cycling through brightness modes (2-mode low/high) and one with a strobe routine to test out setting up timers and the best means of rapidly cycling the LED.

I will probably put the mode-switch timeout as pretty low, down around 500 milliseconds. This should reduce the chances of accidentally jumping into another mode by turning the flashlight fully off and then turning it back on very quickly. There will be no long-term memory; once the timeout has expired, it'll default to initial mode. And since it's a software thing, this timeout will be adjustable.

Regarding software

You'll notice a common theme here: the hardware is built to be robust, with a lot of the flexibility and feature set implemented in software. This is deliberate. It would allow me to easily customize batches of flashlights for particular orders, and allow me to "stock" generic option sets as different sub-models by simply flashing the driver board with the right hex file before testing and packing. But it also, quite deliberately, puts a lot of power in the hands of the end user. Makes the product quite hackable without having to do any "pencil-modding" or desoldering.

In fact, I'm even putting test points on the underside of the driver board which can be wired to a PICKit for updating the firmware in-system.

I have only implemented software on a test board using a similar microcontroller so I can't guarantee anything at this time, but the driver board is currently designed to use a PIC12F1571 microcontroller. Current is monitored using an ADC measuring the output of a low-side current sense amplifier and adjusted by changing a PWM output's duty cycle. Right now current is measured and calibrated every 2 milliseconds.

Options

A bit of discussion on this subject happened in another thread elsewhere, so since it was way off topic we all decided it'd be better to start a specific thread just for flashlight development discussion. Over there the idea came up to make one specifically with a low brightness for use indoors at night. With that in mind, I figured out a fairly simple way to modify my driver board, by replacing only 2 or 3 parts, to operate at 0-250mA instead of 0-2500mA, adjust the current sense amplifier's gain, and operate using the smaller LED for a peak-120lm flashlight without any changes to software.

So probably what I'd do is stock both versions of the driver board, and LED discs for both diodes, and then both the 501b and eventually C84-equivalent housing. With a few different stock softwares to flash, I can offer a large variety of stock "models".

501b housing, XML2:
ZeroBS High (300lm, on/off)
SomeBS High (150lm, 300lm, 2-mode)
AllBS High (150lm, 300lm, strobe, 3-mode)

501b housing, JB3030:
ZeroBS Low (50lm, on/off)
SomeBS Low (50lm, 100lm, 2-mode)
AllBS Low (50lm, 100lm, strobe, 3-mode)

C84 housing, XML2:
ZeroBS Zoom High (300lm, on/off)
SomeBS Zoom High (150lm, 300lm, 2-mode)
AllBS Zoom High (150lm, 300lm, strobe 3-mode)

C84 housing, JB3030:
ZeroBS Zoom Low (50lm, on/off)
SomeBS Zoom Low (50lm, 100lm, 2-mode)
AllBS Zoom Low (50lm, 100lm, strobe, 3-mode)


The names indicate the level of BS you'll have to put up with in stock configuration. I'll always prefer the ZeroBS, though SomeBS high/low modeswitching is not unattractive. Might consider, if demand is high enough, doing a MaxBS version comparable to readily available 5-mode lights, which implement three brightness modes, strobe and SOS.

Charging

It's also been mentioned that I should build a battery charger. That'll be something to look into for sure, but I make no guarantees. Very likely what I would do is a USB-powered charger. A lot of USB ports now are good for 2A output, and everyone and their mothers have those little plug-in USB power adapters that probably also run 2A. I build a pretty solid USB hub that can put up 3A per port without trouble. 1A is a good charge rate for a single 18650 cell, which means a 2A-capable USB port could source a 2-cell charger. The charge curve for a lithium cell is pretty easy; constant current until peak voltage (4.2V) is reached, and then constant voltage until current flow is 3% of initial charge rate, then stop. No floating charge required, since that can actually damage the cells. Overvoltage can't be tolerated, so that 4.2V peak has to be measured within 1%, ideally even tighter. And add in a temperature sensor to make sure the cell doesn't overheat, which can indicate damage.

The same kind of current-measurement and dynamic voltage adjustment system used in the flashlight driver could also be used in the battery charger. Start low and ramp up the voltage to reach 1A continuous, then maintain 1A continuous until it reaches 4.2V, at which point the calibration switches to keying off voltage with current monitoring continuing in the background. Turn off the power entirely once current drops to 30mA. Poll a temp sensor on the I2C bus frequently to check for overheat conditions and lock it down when safety thresholds are hit.

The electronics and the program aren't really a problem. The fun will be designing the housing to put it in and making sure it's something I have the tools to efficiently manufacture in bulk.

end of presentation


So, that's most of what I've got and a couple tidbits of other people's input already bundled up and considered. Anyone else got any input?

Probably. The tune works off not just the total hashrate but the health of individual chips. If a weak chip is getting starved and stops returning nonces, the software will notice, drop the target a bit, restart the string and ramp up to the new target. VH did that specifically because something like a 90-92% target could still be met even if one chip isn't hashing at all, which would cause that chip unnecessary damage in the long run and kill the whole string.

I'll probably start that flashlight thread tomorrow, but earlier today I had an idea. Phil, that low-brightness model you wanted, it'd be a shame to turn an LED capable of 800lm down to 25lm but I already have a reel of white LEDs I built my shop lights out of that max around 120lm (test is 36lm) which would work perfectly for a low-intensity model. Just did some checking for compact lower-current regulators and the winner's one I'm already testing with so I could use an existing driver pill design, replace a couple parts and have the same control system dialing in 0-240mA (0-120lm) instead of 0-2.5A (0-800lm) for the big one. Would save multiple dollars off the parts cost and make more sense for the end product. I can play around with the specifics for that anytime this week.