*Fair Warning* - The following is mad sciency. In that I can't read the chip number and don't have an oscilloscope. Assumptions were made! I don't really expect anyone to mess around with this. I was not expecting to break the pin on this chip when I was lifting it. it didnt take much.

So, It ran for a week at full voltage with no apparent ill effects besides some wasted power. Finally got around to regaining control with an Arduino board. Went on a mission downtown to find some DAC chips. Made myself a lovely Dual DAC arduino setup, only to discover I didnt need them. it was a PWM signal. An arduino on its own can easily do the job.

Things seemed a bit off tho. The Blade didnt activate when I had the PWM duty cycle 175/255. Then I started high and worked my way down to 200 and was in the 0.95V range. Im leaving it there a bit. Going to add buttons/lcd or run a serial connection so I can do more testing when i have the time. I realized after that my PWM frequecy was only 750hz and was probably the source of the weirdness.

This is along the lines of what I came to post about. So heres some info from when I made a stupid mistake.
After taking pics of my boards, forgot to plug in the fans  Found out the blades will shutdown at high temperature.
I think they restarted when they cooled off and then overheated and shutdown again in a cycle. But it was a while ago.


So, I came to share, for the sake of science, my much bigger and more recent mistake. Since the current firmware restricts or is bugged to only adjust VID voltages for Blade #1/3. I was investigating a hardware solution todo this. I believe I found the VID control point. Put while trying to de-solder and raise the Pin in the chip, it broke it off 

I tried to daisy chain 1 blade to the other but both didnt work and I got really scared and backed off this idea. The other blade was fine after being disconnected. I tried for 2 week to recover the pin but it wasnt meant to be. Then I said fuck it. Tied my point right to 3.3V. Bam, blades working again! Under Debug, Vol(voltage) is at a whopping 1050 (1.05V). Its running at 65C w/ %80 fan. With Blade 1 Vid 175, Blade 2 Vid 160 (no control) and Blade 3 Vid 255 (assumed equivalent) im drawing a whopping 950W!! lol. for what seems like 1k/sol more  , but im going to run it the night and see how things even out. Ultimately I want to get them all running VID 175ish at a good frequency and see what the Unit does as a whole.

I will have to try daisy chaining again because I think I may have had a bad connection. If not I guess ill use an Arduino or something to control the VID. Hopefully it survives my reckless decision to run it at max for a bit 

think this works..
the password file is here. this is the default.

# cd /
# cd config
# cat web-users.json
[
    {
        "username": "admin",
        "password": "5349d16d5869aa18af565c4c32e4d56916d8ac9d0c5176594cf80b6e07020a3a"
    },
    {
        "username": "guest",
        "password": "b015aa9f37299ed52c30137d447f97b1b176b341145cf7fe5f9a92e89292e8db"
    }
]


editing 101
#vi web-users.json
press
i       -to enter insert mode and edit
esc   - to exit insert mode
:wq! Enter - to save/exit

hopefully this works for you

They got taken down by the sites image proxy (?). This was the best I got, werent the best shots.

Want to add. I think its completely possible that these things constantly overclock and reevaluate themselves and inno's just making little (unsuccessful) tweaks to the process. Trying to stay optimistic tho. 

Overclocking in General with my Small sample of 2 Units.
- I have good unit that has never performed better with different VID/PLL
- I have a defect unit that does about 1Ksol better at 185-195 VID. but its a poor example being defect.


No, I could never get different VIDs for the boards. T1VID2/3 never did much for me. In the Newest firmware, it would change 'CGMiner-API stats' iVID value. I dont *think T1VID2/3 worked.. but I only messed around with it for a little bit b4 leaving it, getting wierd crashes the next day, and ditching the firmware. Its states in the Files, that T1VID sets the INITIAL voltage level, before tuning. However, When I use a higher VID I get a much higher power draw that stays. It honestly seems like there working on overclock. Just doesnt work. lol.


If you can read code you can get an idea of whats going on in these files.
https://github.com/ckolivas/cgminer/blob/master/driver-SPI-dragonmint-t1.c
https://github.com/ckolivas/cgminer/blob/master/dragonmint_t1.h

This i by no means easy to follow and on top of that, A9's seem to use this CGMiner Dragonmint Driver but with different values and who knows what other customization. ex. I cant find T1Adjust in these files. But for the most part, The process will be close or they wouldn't have used this code and started from scratch. Theres mention of logging about VID/Voltage/PLL(Mhz) in there that I dont see taking place. My guess is cgminer needs to be run in a debug mode. My fear is that inno commented it. The header file has clearly defined PLL tuning Min and Max. There's also ref_clk_khz and sys_clk_khz which I havent played with. No idea what they will adjust or are set at. Ive been avoiding hail marrys with such an expensive device.
--dragonmint-t1-options <arg> Dragonmint T1 options ref_clk_khz:sys_clk_khz:spi_clk_khz:override_chip_num

About the other ports for the Hashboards. its a blur now but I think when I was running 2 boards it seemed like the ports needed to be utilized sequentially. Like I was using ports 1 and 3 and the board on 3 didnt work. Ive been using 1 and 2 when I remove a board ever since.

Im going to give those files another read when im rested, try some different cgminer debug modes and make sure I completely Probed the API. Dragonmint eventually was overclockable from what I read. So there's still figuring out how that worked and see if it applies to A9's. Squeezing this in between 14h nightshifts. This is probably all hard to read. Its time for some sleep.

Mine also had issues yeaterday. Seemed like it was crashing hard and loosing spi communication with the hashboards in the log. At which point cgminer would restart. I saw this 4 times a row in the log in about an hour or 2 and said screw the new firmware. Mine were also wierd after downgrade. I removed the new T1adjust from the config and things seemed to level out. Wasn't really sure of anything since I've been Messing with the API and load balancing on multiple pools. Shut that all down for now too.

I put on a July firmware. Which firmware to you like? I have multiple with July dates.

Sidenote: Youve really tempted me to tear apart me computer to try my bad unit on a high quality power supply. I tried swapping and no effect on eithers hashrate. Ive been so baffled by my 28ksol Unit. Slight improvements through overclocking but nothing significant. Also, beautiful boards with nice solder. No weird heat spots on FLIR. Just seems like a bad bunch of chips. Unless maybe its some wierd power issue. My gut says bad silicon tho.

Do your units all hash well?

Interesting. Im not arguing just pondering. Increasing the VID would have a definite increase in power usage. So would the fans being set higher. I wonder if there is autotuning happening under the hood, even tho cgminer doesnt report it. And on a full speed unit like yours. The autotune backs off the VID.

Or maybe a net efficiency gain by running cooler is occurring and ive missed it since if been running overridden fan speeds the whole time.

Dont think of it as Inno providing anything. They didn't. Things are just thrown together to work. Its more like, how can I exploit Linux openness to suit my need. Quick search suggests this is nginx webserver for the web gui. Its not something Im familiar with but its likely possible todo all the cammands in the gui with direct http requests. Probably poorly documented im guessing. There's cgminer api commands that seem to have decent documentation.If it provides what you need. Dont know if this helps at all.



So.. Ramp up firmwares? Ive only noticed ramp up changes in the GUI, due to Inno messing around with hash/timeframe measurement. Never noticed much pool side changes. Has anyone noticed a definite pool side ramp increase?

Andartis, how accurate is your power consumption measurement? Im pretty sure performance+ will use more as it run the chips at a slightly higher voltage. Unless that voltage gets scaled back on some units? Doesnt on mine. Even the fan running faster should draw more power.

Some power #'s for anyone interested. Probably not precise and has an HS100 Smartplug on them too.

Crap 28ksol Unit 
** Seems to run 29ksol at higher vid but also set to noauto/PLL (Mhz) 1300-1350. I don't know that Pll adjust does anything after initial startup. noauto is necessary for VID change.
220 VID 835 Watts - no auto,  fan1 Max (200%?), fan2 Max (200%?) - 29k
205 VID 790 Watts - no auto,  fan1 Max (200%?), fan2 Max (200%?) - 29k
195 VID 774 Watts - no auto,  fan1 Max (200%?), fan2 Max (200%?) - 29k
175 VID   ?   Watts - no auto,  fan1 Max (200%?), fan2 Max (200%?) - Seem to run poorly again. 28k. Probably will retest.

50k sol Unit **No significant gains ever noticed!
175VID 666 Watts - Performance+ mode,  fan1 "100%", fan2 Max (200%?)
205 VID 770 Watts- no auto,  fan1 "100%", fan2 Max (200%?)
205 VID 747 Watts - no auto,  fan1 "100%", fan2 "100%"

Setting PLL too high makes the unit stop working. But setting 1300-1375 doesnt show significant gains on my 50k unit. Maybe clock is strictly managed after a time and it only starts up on set PLL. Never seen a device not work better at higher (stable) frequency. Seems like underclocking might be more of a thing on this unit unless inno changes something. kinda seems like they're working on something tho.

Anyway, no real point to be made here accept maybe that these things light up as you pump more voltage into them.

Side note: This is my personal Capacitor temperature scale
40°C - Enjoys life, not much to complain about
50°C - works for a living
60°C - Agitated, always yells at Nancy
70°C - Eye twitchy Stress
80°C - Thinks about suicide way to oftern
90°C - Dead man walking
I was concerned that inno sent me a $5k machine that ran at close to 70°C, unnecessarily. Feel like it was for low wattage marketing. obviously im overdoing it @ "100%" and ~"200%" with extension and cut wire blue, but meh. less statistical chance of an issue.

Last, i have some FLIR images if anyone wants to see. Didnt find anything with it except a strange 1K resistor from 12V to GND. Its a hard working little guy, continuously pumping 1/8 watt to ground. Light up on the FLIR. Was initially going to change it thinking it may be bad, until I realize that a 1k resistor hooked up to 12V WOULD run hot. Having a hard time guessing what its for. 12V Stabilization? seems excessive. Kinda want to take apart a good one and make sure it has the same part. lol. but that seems so unlikely it would be wrong part.

oh, any everyone has figured out how to change pools without any ramp up right? 

i got the new performance tuning options with the new firmware.

I set to performance+ mode. But i havent been running for long and needed to pool hop.

intesting things
1. VID (Voltage seems to be default to 175 in performance+). I think I saw 166 on my first boot but im not sure the settings i had.

2. Also, new setting!

   "T1adjust": "3"

in cgminer.conf.  I REALLY want to play with this number!! But I thought I would try my units on this new "performance+" with no tweaks, get some sleep,and see if I can notice a difference.

3. Spi errors seem to be gone.

4. There's a little info that may apply to A9's in the cgminer GIT. like factory mode = noauto mode. Going to try and fish out whether this active developement on cgminer source relates to A9's when im more rested.
https://github.com/ckolivas/cgminer/blob/master/NEWS



In all likelyhood Im probably going to bump my 28ksol unit back up to VID=205!! as it seemed to be getting consistently better rates (0.5-1ksol) this way.
For anyone interested. Ive run VID 195 for a while on this unit. and now VID 205 for ~24 hours but with AC air as a safety net. 35C 
Ive run my 50ksol unit ay VID 185for a bit but didnt notice any gains. maybe even it was a bit slower, but hey, hashes be hard to measure sometimes.
time to sleep..

1 miner went down and was reset. Using curl in a Windows Batch(bat) file worked for frozen testing as I'd hoped.

No issues since the firmware update. 2days 1hours uptime on one. The other only 18hours. Rebooted it doing final testing of my windows script.

I know my on miner script works. Ive see it save a unit when its frozen. The windows script needs to see a frozen unit to be sure it works. Maybe it never will with the new firmware.

We're more discussing solutions that don't involve human interaction. Pool alerts will be my backup now. As my PC is constantly checking on my miners and will automatically power cycle withing 5 minutes. I havent frozen with the new firmware either but someone mentioned they did, so its likely only a matter of time.

Awesome miner has some really robust monitoring and response functions, but its untested with A9's and I felt like writing something tailored for me.

On a slightly related (uptime) note. I'm using a Asus RT-AC56U Router that does Dual WAN with and Android phone as failover. It was the cheapest setup to have backup internet. My ISP has occasional Maintenance and outages. Its seems like a fairly rare function on low end equipment. Even DDWRT doesnt do it easily.

they seem to draw full load when they crash for me. I havent check specifically but the bar on my UPS load meter doesnt change.

Will the hs100 report power draw? Didnt think it did. Im going to have to try that.

That sucks! My, on miner, scripts work but I ported to a windows bat file after Both went down at the same time the other day. No more worries for me finally.

Heres my Windows solution for TP-Link Plugs. Along with Task Scheduled every 5 min and set to "Run whether user is logged in or not" to run background.

MinerCheck194.bat

194OFF.txt

194ON.txt

TeamCheck script finally got tested. and failed! I updated with a fix. Tested working!

One issue though. They went down at the same or close to the same time. Im not sure one had time to save the other. I may have a decentralization issue  
Aw well. Ill leave them running. But I think I better run a check from my PC as well. I guess ill try and figure out the windows CURL command syntax issue or run from VM with a small linux, in case they do go down at the same time.


Hows it going with the new firmware guys? Fix the issue? Im gunna update after a nap. I need to redo all the script files if I do. so more than a couple of clicks and im tired.

So, your a lowlife groupy? It was a social experiment. I was betting on not getting hacked and I was wrong. I also didn't think I'd get such a juvenile response. I have a bad habit of forgetting how many bad apples are out there. I wasn't so careless and lazy that I didn't have notifications setup to tell me my miner stopped hashing to the correct pool. They got maybe $2, mostly because I was curious and poked around a bit before fixing it. I dont feel like I got ripped off for $2. I feel like I paid $2 to do an experiment. You mind laughing and berating people cluelessly elsewhere?

Ugg, The internet really is cesspool. Someone logged into my A9 this morning and changed my pools. It was my fault for leaving it port forwarded to the internet with default passwords. But it begs the question. Is this person port scanning the entire net? Or did he pull my IP from this site?

This mediocre punk hacker:

stratum+tcp://equihash.eu.nicehash.com:3357
3LqPKdLoZsNSyFarscBfMnFmpAgAfDMriW

stratum+tcp://equihash.usa.nicehash.com:3357
3LqPKdLoZsNSyFarscBfMnFmpAgAfDMriW

So yeah, remember to change your passwords if you NEED to go directly on the net with these. I knew it was dumb, was just kinda curious to find out if things were really that bad out there. Im going to report the username later, im justlate from fixing this.

Added a log file to my script with the above code. Updated the post. I learned that awesome miner has the capability to do what this script does and way more. I'll probably try it at some point but Im happy to be worry free about their uptime for now.

Still waiting to see if setting "vm.min_free_kbytes = 8192" may have made a difference. I'm at 5 days uptime. cgminer still fills memory and restarts. Just hasn't crashed yet.