BDLMiner 2.5.4

BDLMiner V2 2.5.4

Fixes for updates from GitHub and for the web pages, and remote monitoring by wallet
address; mining and screens are unchanged from 2.5.3 and the update
installs over WiFi.

• Updates from GitHub no longer stop on "HTTP 618". GitHub now serves release files
  from a host that takes a download link valid for only five minutes, and answers a
  link it refuses (expired or not yet valid) with the non-standard status 618. The
  miner then gave up for five minutes. It now asks GitHub for a fresh link at once, up
  to three times, and the log says what happened.
• Faster, guarded downloads. Since the move to Arduino-ESP32 3.x, every download
  from GitHub made a second, unguarded secure connection: the HTTP client closed the
  one the firmware had opened. It now uses the firmware's own connection, which halves
  the handshakes of an update.
• Remote monitoring by wallet address. No key to create and copy any more: in
  Settings → Network → Private remote monitoring, enable it (and name the miner); it reports
  under its payout address, the part before any .worker. On
  My miners, enter the same address. The page has
  the site's look and can remember the address on the device. As on a pool's address
  page, anyone who knows the address can see these readings; a private key created
  before 2.5.4 still works and keeps them secret. See remote monitoring.
• Web pages: the home page's live card no longer covers the first screen thumbnail; a
  board search without a match says so; the FAQ finds "wifi" in "Wi-Fi"; the site, the
  demos and the Linux hub show the logo as their icon.
• Firmware: no compiler warning left in its own sources (deprecated calls replaced).

A miner still on 2.5.2 or 2.5.3 may need several tries before it can download this
update (the issue fixed here); it retries by itself every five minutes. To update at
once, install <board>-firmware.bin from the release through its web page.

Validation

All host, tool and browser tests and every board build pass. The redirect test now
covers a refused link followed by a fresh one, and the bounded number of tries. The
618 responses were reproduced against GitHub's release file host with an expired
(618 jwt:expired) and an altered (618 jwt:signature-fail) link.

What's Changed

• fix: bugs found by a full sweep of the site, demos, hub and firmware by @bdlglua in #31
• 2.5.4: fresh GitHub link after HTTP 618, remote monitoring by payout address by @bdlglua in #32

Full Changelog: v2.5.3...v2.5.4

BDLMiner 2.5.3

BDLMiner V2 2.5.3

Bitaxe Gamma 601 overclocking and a new web interface; mining on the other boards
is unchanged from 2.5.2 and the update installs over WiFi.

• Profiles up to 800 MHz. Local Settings > Safety offers 525 to 800 MHz in 25 MHz
  steps, and ESP-Miner's 690 MHz preset (up to 2.5.2: 690 MHz at most). Above 690 MHz
  is the overclocking range AxeOS leaves to custom values.
• The voltage that goes with it. A new 1300 mV core voltage, and choosing a profile
  raises the voltage to its own: 1150 mV up to 600 MHz, 1200 mV up to 675, 1250 mV up
  to 725, 1300 mV up to 800. It is never lowered automatically and can still be chosen
  by hand.
• Temperature limits as in ESP-Miner. The ASIC stops at 75 °C (was 70 °C) and the
  regulator at 105 °C (was 90 °C), ESP-Miner's own values. The thermal limit of the
  settings goes up to 73 °C (was 68 °C) so that mining still pauses before that stop.
  The current (30 A), fan, supply and voltage-window stops are unchanged, and so is
  the fallback to 525 MHz on instability.
• ESP32-S3 boards with the chip's sensor keep their full hashrate. The thermal
  limit defaults to 75 °C (was 65 °C) on the boards that read the chip's own sensor
  (T-Display, T-Display-S3, Cheap Yellow Display, boards without a screen): the die
  runs warmer than the board, and a T-Display-S3 mining at full speed stayed on the
  50 % step from 55 °C, at 176 instead of 351 kH/s. Reduction now starts at 65 °C. A
  board still at the former 65 °C default is raised once; other saved values are
  kept. M5Stack devices, whose IMU can read the board next to the battery, and ASIC
  boards keep 65 °C.
• A new web interface. The miner's dashboard, settings and log pages, the
  Linux/Raspberry Pi hub and the website share one design in the style of
  exchange templates: flat dark surfaces, solid blue actions, green change badges. The website is now built with
  React and Next.js; its home page shows the live fleet by board, with
  family tabs and a search. It opens dark, with
  a button for a light theme. Pages, settings and controls are where they were.

Overclocking means more heat and power: watch the ASIC and regulator temperatures, with
a heatsink and the 5 V fan properly mounted. Profiles above 625 MHz have not been
validated on a physical Gamma 601.

Validation

All host and browser tests pass, with new checks of the 800 MHz profile at 1300 mV
(PLL and regulator command), of the 75 °C and 105 °C stops (and nothing below them) and
of the voltage that the settings page pairs with each profile. Not yet run on a Gamma.

What's Changed

• release: 2.5.3 (Gamma up to 800 MHz, 75 °C chip-sensor default, React/Next.js site and new web interface) by @bdlglua in #30

Full Changelog: v2.5.2...v2.5.3

BDLMiner 2.5.2

BDLMiner V2 2.5.2

Hashrate fix for the ESP32-S2, S3 and C3 boards; settings, screens and web pages are
unchanged from 2.5.1 and the update installs over WiFi.

• The S2, S3 and C3 mine with their SHA engine again. Since 2.5.0 the engine was
  left computing SHA-1: ESP-IDF 5 resets it each time it is taken and no longer selects
  the algorithm when a block starts. The boot self-test then failed and these boards
  mined in software only, about four times slower (an ESP32-S3 at 66 instead of
  288 kH/s). The engine is now set to SHA-256 every time. Classic ESP32 boards
  (M5StickC Plus2, T-Display, CYD, M5Stack ESP32) and the ASIC boards were not affected.

Validation

All host, tool and browser tests and every board build pass. The S2/S3/C3 engine model
of the host tests now resets the algorithm when the engine is taken, as ESP-IDF 5 does:
2.5.1's code fails it, 2.5.2's passes. Not yet run on an S2, S3 or C3 board. 2.5.1 was
checked on an M5StickC Plus2 (PSRAM back, updates from GitHub again, about 960 kH/s).

What's Changed

• 2.5.2: S2/S3/C3 SHA engine selects SHA-256 again (ESP-IDF 5) by @bdlglua in #29

Full Changelog: v2.5.1...v2.5.2

BDLMiner 2.5.1

BDLMiner V2 2.5.1

Fixes from the first days of 2.5.0; settings, mining, screens and web
pages are unchanged and the update installs over WiFi.

• PSRAM is back on the boards that have it. The ESP-IDF rebuilt for 2.5.0 turned
  PSRAM off unless the board file declared it: the M5StickC Plus2 lost its 2 MB and
  could no longer open a secure connection to GitHub (release unavailable: manifest HTTP 0; API HTTP 0, with SSL - Memory allocation failed in the log), so it did not
  update by itself; M5Stack Core2 and Fire, and modules with PSRAM on the headless
  builds, lost theirs too. It is found at start-up again, as up to 2.4.2.
  An M5StickC Plus2 on 2.5.0 must be updated once through its web page (Settings ›
  Firmware update, m5stickc-plus2-firmware.bin of this release); later updates come
  by themselves again.
• Built as C++23 and C23. 2.5.0 announced C++23 but was compiled as C++20 (the
  framework's flags ended with an older standard); the firmware's own code is now C++23
  and its C C23, and the build stops if another standard comes back.
• Clearer TLS failures. On boards with PSRAM, a failed secure connection also logs
  the free PSRAM and its largest block.

Validation

All host, tool and browser tests and every board build pass; the M5StickC Plus2 build
has PSRAM enabled again. The PSRAM fix comes from a Plus2 log on 2.4.2 and 2.5.0; this
release has not yet been run on a Plus2.

What's Changed

• build: C++23 and C23 for real, checked at compile time by @bdlglua in #25
• docs(2.5.0): it was compiled as C++20, not C++23 by @bdlglua in #26
• tls: log PSRAM next to the internal heap on failed handshakes by @bdlglua in #27
• 2.5.1: PSRAM back on the boards that can carry it by @bdlglua in #28

Full Changelog: v2.5.0...v2.5.1

BDLMiner 2.5.0

BDLMiner V2 2.5.0

The firmware moves to Arduino-ESP32 3.3.12 (ESP-IDF 5.5, GCC 14.2, C++23).
Settings, statistics, pool profiles, mining kernels, screens and web pages are
unchanged from 2.4.2; the partition tables are the same, so the update
installs over WiFi like any other and keeps everything.

• TLS 1.3: the miner reads public-pool's statistics itself again. public-pool.io
  serves its statistics API (port 40557) over TLS 1.3 only, which 2.4.2's TLS (1.2)
  could not use: Seen by the pool came from the dashboard's own request, while it
  was open, and the miner's screen kept an estimate. The firmware now speaks TLS 1.2
  and 1.3. The dashboard's request from the browser stays as a fallback for any pool
  whose API the miner cannot read.
• New platform, same size. ESP-IDF is rebuilt for the project and leaves out what
  the firmware does not use (Bluetooth, Ethernet, IPv6, WPA-Enterprise, C++
  exceptions, the TLS server side, unused ciphers and curves). The 4 MB boards keep
  their two 1920 KB update slots, with more room than before: T-Display 1733 KB (90 %,
  was 92 %), CYD 1733 KB (90 %), M5Stack ESP32 1847 KB (96 %, was 98 %).
• Certificates. The 40 root certificates the firmware already trusts become
  ESP-IDF's certificate bundle too, in the format ESP-IDF 5.4+ expects.
• Building from source needs PlatformIO Core 6.2.0; the first build of each board
  rebuilds ESP-IDF and takes several minutes. See
  development.md.
• WPA2/WPA3 personal networks are unchanged; WPA2-Enterprise (802.1X) networks, never
  offered by the setup portal, are no longer supported. ESP32-C6/H2 are still not
  built.

Validation

All host, tool and browser tests and every board build pass. On a Bitaxe Gamma 601,
updated from 2.4.2 through its web page: shares accepted and none rejected, about
1.09 TH/s at 525 MHz / 1150 mV as on 2.4.2; market data read over TLS 1.3 from
mempool.space (handshake about 1 s), public-pool's statistics read by the miner, and
a further update installed from the web page. Testing it found four differences of
the new platform, fixed before this release: the SHA engine's lock is no longer
re-entrant (HTTPS and update checks waited forever on the S2, S3 and C3), TLS 1.3 needs
its crypto set up first, a response body was cut at the first gap between TLS records,
and timeouts are now in milliseconds. The other boards were built and packaged but not
run on hardware.

What's Changed

• v2.5.0: Arduino-ESP32 3.3.12 (C++23, TLS 1.3) by @bdlglua in #23
• fix(release): PlatformIO 6.2.0 and ESP-IDF rebuild in the release workflow by @bdlglua in #24

Full Changelog: v2.4.2...v2.5.0

BDLMiner 2.4.2

BDLMiner V2 2.4.2

Pool statistics and Bitaxe Gamma 601 fixes; settings, pool profiles and mining kernels
are otherwise unchanged from 2.4.1.

• public-pool statistics are back on the dashboard. public-pool.io now serves its
  statistics API (port 40557) over TLS 1.3 only, which the firmware's TLS (1.2)
  cannot use, so Seen by the pool fell back to an estimate. When the miner finds no
  statistics API, the dashboard now asks https://<pool host>:40557/api/client/<address>
  itself, from your browser, at most every 10 minutes, and shows the pool's figures
  marked read by this browser. Only the address is sent, not the worker name. The
  figures appear while the dashboard is open; the miner's screen keeps the estimate.

• No more statistics searches at every share. A fruitless search for the pool's
  API ran again after each accepted share. That rule is meant for a pool that only
  publishes an address after its first share; a Gamma finds shares every minute, so
  all ten probes ran again every 30 minutes. It now follows only a search that found
  an API not knowing the address yet (HTTP 404); other failures wait 6 hours.

• The log says why. Each failed statistics probe is logged with its cause (TLS
  error, HTTP status, timeout), and a pool refusing TLS 1.2 is named as such.

• Bitaxe Gamma 601: core voltage setting and ESP-Miner frequencies. The firmware
  kept the core at 1150 mV for every profile up to 800 MHz, while ESP-Miner raises the
  voltage with the frequency and stops its presets at 690 MHz: a Gamma at 600 MHz and
  1150 mV fell back to 525 MHz. Settings › Safety now offers the core voltage among
  ESP-Miner's BM1370 values (1000, 1060, 1100, 1150 stock, 1200, 1250 mV) and
  frequencies from 525 to 675 MHz in 25 MHz steps, plus 690 MHz. A profile above 690 MHz
  saved earlier returns to 525 MHz. The core-voltage safety stop now follows the chosen
  voltage (0.15 V below to 0.10 V above; unchanged at 1150 mV). More voltage means more
  heat and power: raise it in small steps and watch the temperature.

• Bitaxe Gamma 601: the 525 MHz fallback survives restarts. A higher profile that
  failed fell back to 525 MHz until the next reboot only, so every restart, update or
  power cut went back to the failing profile. The fallback is now kept, with its
  reason, while that profile and voltage stay selected; choosing another frequency or
  voltage clears it.

• ESP32-S3 boards: faster hardware SHA loop. On the S3 every register access
  crosses a slow peripheral bus. Following NerdMiner Modded (MIT), the next header block
  is now written while the engine computes the second hash, and only the words that
  change: NerdMiner Modded measured about 324 instead of 222 kH/s on its S3 loop. At
  boot the miner checks every digest and the exact set of hits against software, then
  times it against the existing kernels and keeps it only if faster; an engine that
  does not behave falls back to them. Not yet measured on our S3 boards (M5Stack S3,
  T-Display-S3, headless S3).

Validation

Browser regressions cover the dashboard's own request to public-pool, its tile, and
its absence when the miner reads the API, and the frequency and voltage menus; host
regressions cover each core voltage written to the regulator, the safety window that
follows it, the new profile list, and the fallback kept across a restart and cleared by
another profile or voltage, with all host, browser and board builds. The voltage
setting follows ESP-Miner's values and has not been tried on a physical Gamma. The public-pool request was checked against a simulated answer, not the live
API. No physical board was used for this validation.

What's Changed

• 2.4.2: public-pool stats via the browser, Gamma core voltage and ESP-Miner frequencies by @bdlglua in #21
• 2.4.2: faster ESP32-S3 SHA loop, after NerdMiner Modded by @bdlglua in #22

Full Changelog: v2.4.1...v2.4.2

BDLMiner 2.4.1

BDLMiner V2 2.4.1

Bitaxe Gamma 601 fix; settings, statistics, pool profiles and mining kernels are
otherwise unchanged from 2.4.0.

• Bitaxe Gamma 601: a silent ASIC is restarted automatically. At 525 MHz, a
  BM1370 that stopped answering its hash-counter request for 3 s, or whose counter
  stalled, stopped mining with ASIC not responding; restart required until the
  board was restarted by hand. The chip is now reset and started again, as NerdNOS
  already does, up to 3 times an hour; a fourth failure within the hour still
  stops mining until restart. The readings at each automatic restart (input and core
  voltage, current, temperatures, fan) are kept as the last fault, in the log and on
  the dashboard's ASIC tile. Above 525 MHz the existing one-time fallback to 525 MHz
  comes first. Regulator, sensor, fan and temperature faults still latch.
• The ASIC communication states now have French texts on the dashboard.

Validation

Host regressions cover three automatic restarts in an hour, the latch on the fourth,
the hourly budget, and a failed shutdown that still latches, with all host, browser
and board builds. No physical board was used for this validation.

What's Changed

• site: credits page fits phones, stats tolerate partial summaries by @bdlglua in #18
• docs: align BDLMiner V2 guides with stable v2.4.0 by @bdlglua in #19
• 2.4.1: Gamma 601 restarts a silent ASIC instead of stopping until reboot by @bdlglua in #20

Full Changelog: v2.4.0...v2.4.1

BDLMiner 2.4.0

BDLMiner V2 2.4.0

Peercoin (PPC), proof of work joins BTC, BCH, BSV, eCash and DigiByte SHA-256d
in Settings → Pool → Cryptocurrency. Choose a Peercoin Stratum V1 pool,
its payout address or pool account, and a matching backup. The pool determines
the chain served; selecting PPC cannot change a shared pool account's coin.

Peercoin Base58Check and Bech32/Bech32m address checks use its own prefixes.
The height reader supports its timestamped transaction versions 1/2 and the
timestamp-free version 3. Coinbase hashing preserves the pool's bytes, and
the proof-of-work header is the standard 80-byte SHA-256d header. Public and
private statistics retain PPC separately. Bitcoin market, halving and
confirmation data are not shown for PPC. Staking is not provided.

See Peercoin setup and pool references.
The existing coin IDs, saved settings, remote access keys and ASIC safety
protections are preserved. Updating does not switch an existing miner to PPC.

Validation includes official Peercoin address and genesis-block vectors,
coinbase height formats, settings/persistence, candidate records, browser
behavior and the statistics collector. Physical Peercoin pool measurements
remain pending; no PPC hashrate or low-difficulty pool preset is claimed.

What's Changed

• feat: add Peercoin proof-of-work profile (2.4.0) by @bdlglua in #17

Full Changelog: v2.3.4...v2.4.0

BDLMiner 2.3.4

BDLMiner V2 2.3.4

Thermal safety fixes; settings, statistics and mining kernels are otherwise unchanged.

• Bitaxe Gamma 601: the user thermal limit now pauses before the hard stop.
  Pause mining above accepted up to 255 °C, but the ASIC's hard stop at 70 °C
  latches until a restart. A limit of 70 °C or more therefore never paused and cooled
  the board first: mining simply stopped until someone restarted it. The limit is now
  at most 68 °C (0 = off is still allowed); a higher saved value is lowered to 68 °C.
• NerdNOS: hard stop at 80 °C. The board has no fan control, and its only thermal
  protection was the user limit, which can be off (0) or set higher than the stock
  firmware's 80 °C cut. The driver now stops the ASIC at 80 °C on its NTC whatever
  the settings, and restarts it at 70 °C; a lost reading never ends the cooling.

Validation

Host regressions cover the Gamma limit (68 °C accepted, 69-75 °C refused, 0 kept)
and the NerdNOS hard stop and hysteresis, with all host, browser and board builds.
No physical board was used for this validation.

What's Changed

• 2.3.4: Gamma thermal limit below its latching stop, NerdNOS 80 °C hard stop by @bdlglua in #16

Full Changelog: v2.3.3...v2.3.4

BDLMiner 2.3.3

BDLMiner V2 2.3.3

Fixes; settings, statistics and mining kernels are unchanged.

• Works on networks that block NTP. Since 2.3.1 HTTPS certificates are checked
  against the clock, so without NTP no notification, market data or pool statistics
  could be fetched. After a minute without NTP, the clock is set from the pool's job
  time (within minutes); NTP still corrects it whenever it answers.
• Router name. The miner now registers as bdlminer-xxxx (its mDNS name) with
  the router instead of esp32-xxxxxx. Opening the dashboard through the router's
  own name for it (for example bdlminer-xxxx.fritz.box) is accepted for settings.
• MQTT no longer reports connected while WiFi is down.
• Pool refusals name the refused value. public-pool's Authorization validation
  error now shows in the log with the value it rejected, for example the payout
  address, so a mistyped address is found at once.
• Screen durations no longer read "60min" or "1d 24h": each unit is truncated.
• Bitaxe Gamma 601: the OLED is only written when its brightness changes, instead
  of every second on the I2C bus shared with the ASIC.

Validation

Host regressions run the production clock fallback, the pool refusal detail and
the screen durations, with all host, browser and board builds. No physical board
was used for this validation.

What's Changed

• fix(stratum): log the value a pool refused with its error by @bdlglua in #13
• fix(display): truncated durations, no OLED writes when brightness is unchanged by @bdlglua in #14
• 2.3.3: clock without NTP, DHCP host name, MQTT state on WiFi loss by @bdlglua in #15

Full Changelog: v2.3.2...v2.3.3