I am still working on it.  I am trying to rewrite my tool set to support both the T9+ and S9 since they both use a similar interface at the low level (the L3 and A3 use the linux i2c driver to talk to the pic, the T9+ and S9 go directly through the FPGA).  Hoping to give you another update this coming weekend.

We just updated my son's farm to 15 S9's and he also has a couple T9+s, so that will be my test bed.

I spent the last couple hours confirming I have the info I need to be able to reprogram the pic firmware.  Whether it works in the particular case / problem you have is a different issue.  It will take a little more work than I had hoped (my code needs more refactoring as the S9 and T9's talk to the pic in a different way).  I don't know that I will get it done today, but I will continue to work on it.

I am going to take a look at this today.  I wrote / modified a program to help restore the pic firmware on an L3+ ( https://github.com/darval/bitmain-tools ) and I am going to see if I can modify it to work for a T9+.  The pic is a microcontroller on each hash board.  Usually when it (bmminer) tries to get the version and it fails (-1 or 0xff), it means the pic firmware got trashed.  My program has a mode to try to restore it.  It currently doesn't work on the T9+, so don't try it yet, but if I am successful, I will update it and post about it here.  Then you can try it out.  Like anything, this stuff is all use at your own risk.

The compiled version in the release above works with both L3+ and A3.  There is a flag 'set_voltage -l' for L3+ or 'set_voltage -a' for A3 that tells it which machine you are using it on.  I could change it to autdetect but I figure you know what machine you are running on and I didn't to use the wrong protocol in case it caused unexpected side effects.

Unfortunately all I have are L3+'s, so I don't know.  If they are using the same pic, the answer is yes.  If you have one and want to try, it will tell you if it doesn't find the same pic version.  The L3 version expects a pic software version of 0x03, the A3 version expects a pic version of 0x81 and uses a slightly different protocol. 

Hey all,
I took the work that jstephanop did for the L3, cleaned it up a bit to make it easier to script with (there is a quiet mode which just outputs values).  I then added support for the A3 based on the work that FNT did.  We now have a single program that will work with both the L3 and A3 (don't have a D3 but it may work on that too).

At this point I would call it pre-release since although I have tested it on my L3's and A3's, it has not had a lot of testing.  Some of the changes I made include timing changes in theory to make it faster, so I would be interested if you are seeing any error messages at all. 

Like any of this stuff, use at your own risk.

Code and binary are here: https://github.com/darval/bitmain-tools

@jstephanop @FNT
If you guys want to merge all this into a single repo, I am good with that.  Take a look at the changes I made and see if you see any issues, or are interested in merging it back into your versions.

Nope, but you do want to enable ipv6 if you are planning to host more than one masternode on that vps.

As someone who has tried to support this project, I am getting a little concerned.  I joined the project because I had never run a masternode before and I saw it as a good chance to learn.  I now have 22 masternodes and they are generating income.  I also have a couple nodes mining and producing coins.

I have tried to also support the exchange by both selling and buying coins as I could.  I currently have around 350,000 coin and that is going up as I get paid for my masternodes and mining.

However, I do have some questions and I suspect so do a lot of other people.  At the end of the day, what is this coin for?  The network is up and running but other than curious people like me, who is going to use it?

I had mentioned in a previous message that we need a project timeline and plan to understand what the point of all of this is.  I appreciate that the main developer is passionate about the project and the coin, but that passion has to be shared if others are going to participate in this project.  And if we don't, there is no project.

@BABYCHAIN, what is your vision for this coin and project?

Can you provide a timeline with milestones that we can measure our progress against?

There are still people willing to help, but you need to tell us what you need.  Asking for bitcoin to pay for an exchange, with no goal or plan in sight will not accomplish anything.  I am a programmer and can help with the code if that is what you need.  But I am involved in several different projects and without a vision and an understanding, I will take my time and effort and move on to other projects.

Please give us a plan and a direction, or I and others will move on.  This is not a threat, but rather just a statement of fact.

Thanks for what you have done so far!

PM sent..

Jumping on the bandwagon here as well.  I have one rig still running ethos because of this issue.  Would love to see a solution that doesn't require me to get a different motherboard (ethos is working, so that won't happen - just prefer SMOS if I have a choice)

The guide on the first post of this thread isn't bad to get started.  There is also a link to a script someone wrote to automatically set up ten nodes at a time.  I was able to use that to figure out the details I needed.  I set up a vps this morning with 6 master nodes on it.  Took about an hour, but it all seems to be up and working.

Some points.

When I create the vps, I turn on IPv6 support.  I then have to modify the networking startup to assign the addresses I want to my interface.  I also add a couple gig of swap space.  Not sure I need it (I use a 1G ram vps), but better set up now before I start rather than have it run out of memory later.

I then create 5 (or 6) directories for the data dir for master node (mkdir ~/.baby1 ~/.baby2 ~/.baby3 etc...).  Then then cheat and scp a copy of the whole data dir from another working master node.  This is just for expediency as  I could just wait for it to download the blockchain.

I also bring up one master node at a time.  Basically following the guide from page 1 in terms of steps. 

Anyway take a look at that script I mentioned and ask if you have any questions.  There are people here how have created many more master nodes than me.

Install the wallet as described on the first post of this thread, then leave the daemon running (it is running when you are using the gui wallet).  You also need to set it to generate.  You can do this with the debug window in the gui and do:
Or if you are using the command line, you can do:
Assuming you are in the directory with the baby-cli binary and it is executable.

In both cases you can limit the number of cores it uses by adding a third parameter which is the number of cores.  Using 2 cores would be:

It appears to have gotten back closer to normal now.  Not sure what happened.

Whatever the issue, it is slowed the generation of blocks down.  More hash would have sped it up.  I am sure it is being investigated.

Although I am sure you guys are enjoying your conversation, can you do the rest of us a favor and not quote the whole thread back in every post you make?

Thanks!

You need to leave the daemon running (it is running when you are using the gui wallet).  You also need to set it to generate.  You can do this with the debug window in the gui and do:
Or if you are using the command line, you can do:
Assuming you are in the directory with the baby-cli binary and it is executable.

In both cases you can limit the number of cores it uses by adding a third parameter which is the number of cores.  Using 2 cores would be:

I restarted 6 of my masternodes late last week and it took 3-4 days before they started earning money.  It used to only take about 24 hours but with the greater number of nodes, it now seems to take at least 3 days to get any payout.  Just my experience so you may get luckier.

I have 1 4core/8thread and 1 8core/16 cpu mining and I get between 2-4 blocks a day between both of these CPUs.  With a single quad core, I would expect 0-1 blocks a day, certainly 3-4 a week.

I have an MSI board running Ethos right now (1 570 + 5 580's) that I can't get to boot simpleMining.  It wants an EFI boot and I can't get it to see the legacy usb to even boot at all.  Not sure if that is the only problem but I have yet to work it out.

When you run the command ./babyd, it runs in the foreground (takes over the terminal window).  If you hit ctrl+c (or ^c), it causes babyd to exit.  You are getting 'out' of the app.
When in vi, esc takes to you to the command mode.  You can quit by :q or save and quit with ZZ
Google simple vi commands to get you through editing.

Or you can use nano 'nano /root/.baby/baby.conf' which is a little more user friendly.