It has been a little too long since I posted a proper MinerLab update.

That isn’t because the project has been quiet. Quite the opposite—we’ve spent the last month adding hardware, fixing real-world reliability problems, migrating production, expanding analytics, and turning MinerLab into a much more capable experimental platform.

# What changed?

MinerLab is no longer just collecting miner telemetry.

We’re now comparing:

* Miner-reported hashrate
* Power consumption
* Firmware behavior
* Share/work counters
* Pool-observed hashrate
* Pool worker status
* Share timing
* Firmware families against each other

And we’re doing it with enough historical data to start seeing behavior that would be invisible from a normal miner dashboard.

# Production moved to Raspberry Pi

One of the bigger changes was moving MinerLab production off the original Windows logging PC and onto a dedicated Raspberry Pi environment.

The collectors, parsers, power monitoring, status generation, web dashboard, and scheduled jobs are now running as managed services.

That migration also forced us to confront something that sneaks up on any long-running telemetry project:

**the database got big.**

Our production SQLite database is now around **42 GB**.

That exposed a few scaling problems that simply didn’t matter when the database was small. We optimized status queries, added indexing where needed, and improved how we handle maintenance and backups.

A good example: we tried backing up the live database while another heavy database operation was running and absolutely buried the SSD in I/O.

Nothing was technically “hung”—we had just created our own traffic jam.

Once we stopped the competing work, quiesced the database writers, checkpointed WAL, and ran the backup properly, the entire \~42 GB database copied cleanly in about **4.5 minutes**.

Lesson learned, procedure improved.

# We fixed some real reliability problems

The FNB58 USB power-meter stack also got some attention.

We found a failure mode where an individual meter could hit repeated USB read timeouts and effectively stop contributing data while the larger power service continued running.

Rather than simply restarting the entire power-monitoring service, MinerLab now handles recovery at the individual meter level and reconnects failed devices when possible.

That is exactly the kind of behavior I want from this project: recover the smallest failed component instead of bouncing the whole system.

# The miner fleet keeps growing

MinerLab is now monitoring multiple hardware and firmware families, including:

* BitAxe
* BitsyMiner
* NerdMiner variants
* SparkMiner
* MiniMiner
* FX1

And FX1 has become one of the most interesting parts of the project.

What is FX1?

>[NerdMiner V2 FX1 RC1 is finally public — \~446 kH/s on my test unit, major fixes, Helios support and more](https://www.reddit.com/r/NerdMiner/comments/1wsvq2s/nerdminer_v2_fx1_rc1_is_finally_public_446_khs_on/)  
by [u/Main\_Injury\_4053](https://www.reddit.com/user/Main_Injury_4053/) in [NerdMiner](https://www.reddit.com/r/NerdMiner/)

We currently have **three FX1 miners** running beside **three NerdMiner units**, giving us a nice comparison group.

This opportunity to beta-test FX1 puts us in a really useful position: instead of just saying “this firmware feels faster,” we can provide actual measured data back to the developer before full release.

We’ve already added support for FX-specific work counters and local telemetry.

This weekend I plan to produce our first structured FX1 beta report.

# MinerLab can now see what the pool sees

This may be my favorite new capability.

Until recently, MinerLab primarily knew what the miners themselves reported.

That is useful, but it is only one side of the story.

We found the API behind the HMPool dashboard and added a new **pool observation subsystem**.

Every 15 minutes MinerLab now records a lightweight HMPool snapshot containing things like:

* Pool-estimated worker hashrate
* Worker active/inactive state
* Valid/invalid shares
* Last-share timestamp
* Current account hashrate
* 1-hour average
* 24-hour average
* Pool-side hashrate history

We intentionally do **not** hammer the pool constantly or create another giant telemetry stream.

Four snapshots an hour is plenty for what we are trying to learn.

# Local vs. pool comparison

Once the pool data existed, the obvious next step was to compare it directly with MinerLab’s local observations.

MinerLab now aligns each HMPool snapshot with the nearest local miner observation—usually within only a few seconds.

The comparison report includes:

* Local hashrate
* Pool hashrate
* Pool/local ratio
* Percent difference
* Timestamp alignment
* Last-share age
* Pool worker state
* Pool-data freshness
* Whether the observation is suitable for performance comparison

And this immediately exposed something interesting.

# “Offline” does not necessarily mean offline

I had noticed before that HMPool would occasionally show a miner offline even though I knew it was still running.

Now we can actually prove it.

We captured multiple snapshots where MinerLab had fresh local telemetry from the miners only seconds from the pool observation, but HMPool reported most or all of them offline.

Instead of turning that into an alarm, MinerLab now distinguishes between evidence states such as:

* **AGREE\_UP** — local telemetry and pool agree
* **LOCAL\_ONLY** — miner is clearly alive locally, but the pool says offline
* **POOL\_ONLY** — pool sees it, but MinerLab lacks current local telemetry
* **BOTH\_STALE** — neither side provides current evidence

That avoids a really important mistake:

**The pool does not get to be the sole authority on whether a miner is alive.**

# We found something even stranger

While studying those “offline” events, we found snapshots where HMPool’s worker data appeared to move backward in time.

Across much of the fleet:

* `last_share` timestamps regressed
* workers flipped to inactive
* supposedly cumulative `valid_shares` counts decreased

Then, on the next snapshot, the values jumped forward again.

We are **not drawing conclusions yet** about why that happens.

It could be caching, backend synchronization, API behavior, worker-state refresh logic, or something else.

But MinerLab now marks stale pool observations and excludes them from performance comparison rather than blindly using questionable data.

We’re deliberately collecting a deeper dataset before deciding whether there is anything worth raising with HMPool.

# FX1 vs NerdMiner is already getting interesting

Our first very small comparison sample showed the FX units tracking pool-observed hashrate more closely than the NM group overall.

But the sample is nowhere near large enough to call that a result yet.

That is exactly why we built the system this way.

Instead of cherry-picking one good or bad snapshot, we can look at:

* Mean pool/local difference
* Mean absolute deviation
* Stability over time
* Share cadence
* Device-to-device variance
* Firmware-family variance
* Long-term bias between reported and observed work

After another day or two of data, those comparisons should become much more meaningful.

# What’s next?

Immediate priorities are pretty straightforward:

* Let the HMPool comparison dataset grow
* Characterize the recurring stale/offline pool snapshots
* Produce the first FX1 beta report
* Compare FX1 and NerdMiner behavior over a larger sample
* Feed useful findings back to the FX1 developer
* Eventually surface validated comparison information on the MinerLab kiosk/dashboard

One of the things I’ve enjoyed most about MinerLab is that nearly every problem has turned into another capability.

A USB timeout became per-device recovery.

A huge database became a scaling exercise.

A misleading pool status became a multi-source evidence model.

A beta firmware became an opportunity to generate useful engineering data before release.

That’s pretty much exactly what I wanted MinerLab to become.

If anyone else is running **FX1, NerdMiner, BitAxe, BitsyMiner, SparkMiner, MiniMiner, or similar hardware**, I’d be very interested in hearing what you’re seeing—especially anything related to pool-reported versus locally reported performance.

I’ll post the first structured **FX1 beta report this weekend** once we have a little more data to work with.

MinerLab: 30-Day Update — Raspberry Pi Migration, FX1 Beta Testing, HMPool Comparison Data, and a 42 GB Database