BDLMiner 2.5.7

BDLMiner V2 2.5.7

Public statistics and optional personal monitoring now send directly to the
BDL server at https://api.bdl-pool.com:36018, replacing the Cloudflare Worker
address embedded in older firmware.

• Anonymous hashrate reports and the opt-in personal reports keep their existing
  five-minute schedule and data formats. Saved sharing preferences still apply.
• HTTPS uses the API hostname for certificate verification and the relay's
  explicit port, 36018, for the connection. Neither report path falls back to
  unverified TLS.
• The remote-dashboard link opens miner.bdl-pool.com/remote.html. The public
  website and its private viewer read the same server directly.

Updating

Use the miner's signed GitHub updater, or upload its matching
<board>-firmware.bin from this release through its local dashboard. Existing
settings are retained. A factory image is for USB installation and should not
be uploaded as an OTA update.

This update removes the statistics Worker's request allowance from firmware
reporting. Server capacity and relay availability still apply. Older firmware
continues through the compatibility Worker until updated. The public chart
history was imported; personal history on the new server starts with the
reports received there.

Validation

Host regressions cover verified HTTPS on port 443 and explicit port 36018,
report scheduling, opt-in settings and the isolation of personal readings.
Browser checks cover public statistics, remote monitoring and the updated
dashboard link. The release pipeline builds all 12 board profiles, checks image
versions and hashes, and signs the firmware centrally before publication.

What's Changed

• Prepare stable release v2.5.6 by @bdlglua in #38
• Retry transient GitHub release asset failures by @bdlglua in #39
• feat(gitignore): add optional gitignore for build artifacts and IDE s… by @bdlglua in #40

Full Changelog: v2.5.6...v2.5.7

BDLMiner 2.5.6

BDLMiner V2 2.5.6

Completes digest-word polling for hardware SHA-256 on ESP32-S2, ESP32-S3 and
ESP32-C3. Mining results and the user interface are unchanged from
2.5.5.

• Use the digest word as the completion signal. The resumable SHA mining
  loops now poll word 7 of the digest instead of waiting only on the engine's
  busy flag. Once the word is nonzero, its value is reused for the target
  comparison, avoiding a separate read.
• Handle a zero final word. A completed digest may have a zero most-
  significant word. The poll periodically checks the engine's busy state so
  this valid result is recognized without an unbounded wait.
• The change applies to the resumable SHA engine used by ESP32-S2, ESP32-S3 and
  ESP32-C3. The classic ESP32 SHA assembly path is unchanged.

Validation

The complete host test suite passes, including exact digest and target-filter
checks for the resumable SHA kernels and the ESP32-S3 overlapped kernel. The
release workflow builds and validates the firmware images for all release
environments before creating the signed draft.

Full Changelog: v2.5.5...v2.5.6

BDLMiner 2.5.5

What's Changed

• site: aligned live-fleet table, hero card below the screens, centered card arrows by @bdlglua in #33
• test(web): wait for the history request in the ten-second polling test by @bdlglua in #34
• Serve the website at miner.bdl-pool.com by @bdlglua in #35
• Publish the My miners viewer at miner.bdl-pool.com/remote/ by @bdlglua in #36
• feat(site): My miners as a page of the website (remote.html) by @bdlglua in #37

Full Changelog: v2.5.4...v2.5.5

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