This part is totally optional -- no need to pay Winsource scalper prices ($34?!!?). If you really want to try it out, you could order some cheap, potential fakes from AliExpress and see what happens.

Rust FW for bitaxe is a big subject i am working on everyday. As I said in a previous post, it is better someone work on a standard C FW based on existing component (cgminer) instead of waiting for the Rust solution which will take longer time.

There not such "cgminer porting in Rust", cgminer is heavyly dependant on C. The best I can do, is to use cgminer driver for BM1397 based HW, to understand the low level (undocumented) protocol. Then code a (Rust) driver for BM13xx (based on Rust Embedded-Hal abstraction).

To update on my progress doing so, I received the broken T17 I brought on ebay (2 hashboard seems to be functional enough to be communicating) with stock FW, so I was able to log serial/i2c communication between ControlBoard and HashBoard using Saleae Logic2 (logic analyzer) and code a High Level Analyzer to parse the Serial Protocol (communication with BM13xx), it is available on https://github.com/GPTechinno/bm13xx-hla. Basic communication protocol is covered, I am into understanting the registers and their fields now. For this I do cross comparaison with S9k log (BM1393) with stock FW I also have on hand. I will also try different custom FW for the T17 (including BraiinsOS+) to learn how these differents flavor handle the same HW. I would be also very interested to have more log from other miner (S17...). So a lot of work need to be done in this direction...

For the ESP32-S3 selection, it is the most ESP32 capable chip, that's why I guess Skot selected it. Its exotic architecture (Xtensa) make it less compatible with existing project. Nevertheless, esp-rs, which is the Rust support for ESP32 family seems to have active community and good result. Basically, there is 2 flavors :
- one based on IDF (the framework supplied by Espressif, based on FreeRTOS, so a low level OS in C, that can handle all wifi/network layers) where Rust application can be run on top (so kind of a mixed C/Rust embedded). To my personal point of view, considering this approach, it is better to have a full IDF FW with existing cgminer C cross compiled to it, no need for Rust here, this is the "standard C FW" I was refering to earlier.
- one based on plain Rust, but no wifi/network is available yet.

IMHO wifi is not reliable enought for 24/7 mining device, copper wire (Ethernet) is much more prefered here. That's why I have close look also into W5500 SPI/Ethernet bridge from Wiznet (I used them a lot in many other project), that has a very good support in Rust Embedded enviroment (https://github.com/newAM/w5500-rs).

For the Rust embedded framework, there is mainly 2 solutions :
- RTIC : Real Time Interrupt-driven Concurrency which I am not yet fully documented. Community seems very active. Alex (from w5500-rs) has a project example with it (https://github.com/newAM/ambientsensor-rs).
- Embassy : EMBedded ASYnc, which I start to love more and more. It has great support for STM32 and RP2040 (RPi PICO chip) but no ESP32 yet. w5500-embassy is not finish eyt, but Alex gave me access to its private repo where job is ongoing there. I will try to make progress on it. I tink a great HW for this, is the W5500-EVB-PICO, basically a RP2040 with a W5500 on a stick (brought 2 of them). RP2040 is a dual core Cortex-M0+ at 133MHz. Having a dual core look promising to have one core for the Network (Ethernet/W5500/StratumV2), and the second one for the BM13xx serial handling. Embassy seems to be able to deal with these 2 differents contexts (not tried yet).

Finally, why I think Rust is way to go for a embedded miner, it is mainly because Stratum V2 Reference Implementation is done in Rust (https://github.com/stratum-mining/stratum), I recently joined their weekly dev meeting and they seems to be interesting into a first embedded implementation. It can be done on the ESP32-S3 on top of IDF without the need to have actual BM13xx I think.


And about others Bitaxe's chip driver, I have well debugged my EMC2101 rust driver, but it is not finished yet.

Actually, I think it is not offtopic here.

xraid is someone I met on SV2 Discord doing my research for Bitaxe. He has great understanding of SV1/SV2 and current development. More he is very excited by Bitaxe project, that's why I asked him to join this thread.

SV2 is quite a complexe architecture by itself, and it is a small part of Bitaxe project. I think this post is giving some context about SV2. I didn't feel any shilling personnaly (if I am allowed to express my opinion about that).

Actually SV2 is very important for an embedded miner, has it avoid the hassle to manipulate string for JSON parsing/formatting (used in SV1).

first off, I am honored, impressed and excited that you are putting so much time into this! Thank you! I am slowly working on the C (esp-idf/FreeRTOS) based FW. Once I get this bitaxeMax_v2 board design wrapped up and ordered, I'll dig into it some more.


yes, exactly. Even the C version of the firmware isn't really a port. cgminer relies on too many OS APIs to really be ported to embedded. Nonetheless, cgminer is a great example of the main concepts in miner software and ck, sidehack and kano have done a great job with this. Thanks guys!


this is awesome. Anything we can do to better understand the BM1397 is great. I started a GitHub repo to dump everything I am learning about the BM1397 here https://github.com/skot/BM1397. Sidehack and Kano are obviously way ahead on this. The new cgminer is a treasure trove of BM1397 learning; https://github.com/kanoi/cgminer


I was lured into the ESP32 world because of their RISC-V core in the ESP32-C3 and the fact that it's available (you can't say that for many 32bit MCUs these days). For those who don't know, RISC-V is a relatively new ISA (processor core) that is free and open -- a welcome change from the fiercely closed incumbents like ARM and x86. The RISC-V core ESP32 isn't quite ready for this project yet, so the ESP32-S3 with the Xtensa core will work nicely until it is.


I feel like WiFi itself should be reliable enough for mining. Is the ESP32 WiFi implementation the problem? Maybe the antenna isn't good enough? I'd really like to have these miners be wireless. I dream of attaching one to a solar panel and putting it out in my yard to mine whenever the sun's out.


Embassy does look cool. It's frustrating though that it's only really available for STM32 and nRF -- both MCUs that are extremely affected by the chip shortage. It looks like the RP2040 is somewhat available?


Great! I'm pretty close on the bitaxeMax v2 design, hopefully we can get you some HW soon!

That makes sense.. External WiFi antennas might be the way to go. Espressif has some very interesting ESP32 long distance WiFi and mesh examples that would be fun to look into.

I'm pretty sure it can be done! Talking stratum and rolling extranonces just isn't that complicated. Talking BM1397 is tough, but only because it's not documented, not because it's computationally hard. I think you'll be surprised what a processor can do when it's not also running a OS

I've never tried a hot plate, so I can't help you there.

I have soldered approximately 1 billion PCBs with the following method;

- Get a convection toaster oven. Nothing fancy, it just has a fan inside for more even heating. This is like a $50 Black and Decker kind of thing. Never use this oven for food.
- Get a thermocouple thermometer. These are $30ish
- Use Sn63/Pb37 no-clean, leaded, solder paste. I usually get MG Chemicals brand, in a syringe. Keep it in the refrigerator so it's nice and cold before you stencil it. (obvs don't get it near your food). Wash your hands well after.
- Take your time to get the paste stenciled right. Don't be afraid to wipe it off with IPA and try again. The paste stencils better when it's cold.
- Use tweezers to put all of the parts on the pasted board.
- Put the board(s) in the toaster oven. I usually put them right on the wire rack, which is in the metal tray.
- Put the thermocouple inside the toaster oven. Close the door on the thermocouple wire so that it holds the end right above the PCB, inside the oven.
- Turn the oven on bake, medium setting.
- Once the temp gets to 140C, turn down the oven heat and try and keep it at 140-150C for 2 minutes. Open the door a little if it's getting to hot. This is the "Soak" phase
- After two minutes, turn the heat to high
- Once the temp reaches 200C start a timer for 30 seconds. Keep the temp between 200 and 220C for this phase. Usually you don't need to do anything. This is the "Reflow" phase. You should see all of the paste melt.
- After 30 seconds, turn off the toaster oven. open the door.
- Let the boards cool for a bit in the oven with the door open.
- Once cool to touch, inspect the boards with a microscope for dry pads and/or bridges. Depending on how well you did with stenciling there may be a few, especially on QFP packages. QFNs sometimes too. Fix these up with paste flux, solder braid and your soldering iron.

Stenciling is the hardest part. reflowing in a toaster oven works surprisingly well, IMHO.

the BM1937 chips to PCB are soldered with  ≈ 183C melt-point and heat-sink to chip is using ≈ 130C in repair manuals from bitmain.

I see! I've only worked with hot plate for soldering and hot air rework station. I might give this a try, though..

That's what I also do when hot-air soldering. It should work for these boards, as well, to be honest, just need to be careful with the air setting not to blow the very smallest components around.

The technique does sound good and it's anyway exciting to try new stuff.. Thanks for the detailed instructions!

Awesome, great job! So excited about this project. I personally need to solder my PCBs and order an ESP32-S3 to be able to start working on the firmware; is there some Rust and or C++ stuff already semi-working to pick up or should I start from scratch?

By the way; here some updated renders for top & bottom with raytracing and Bitcoin color #ff9900 on top and bottom solder mask.