I'm hoping the community can help me. Residential DOCSIS 3.1 (Hitron CODA-57), self-hosted monitoring polling the modem's status page every 5 min into a time-series DB, so I've got a week's worth of channel-level data to look at. Mid-Atlantic US, humid subtropical climate and its been HOT if that's relevant. I've had this provider about 2 years and reliability has been mediocre — a couple times a week I have to power-cycle the modem to get throughput back to normal (~1.5 Gbps down / 50 Mbps up on this tier). When I call tech support, they would just have me power cycle, which led me to this effort to determine what was actually happening. Previous provider was rock-solid over several years — don't recall ever needing to power cycle — but cost roughly double for less bandwidth.

The pattern: downstream power drops uniformly across all 32 channels (OFDM + QAM) roughly noon–2PM local every single day, then recovers by evening. Checked against 7 days of hourly temperature data from the nearest airport station — it tracks almost exactly: power bottoms out within an hour of the daily temp peak, recovers as it cools. Swing is about +0.5 dBmV (early morning, coolest part of day) down to about -3.3 dBmV (afternoon peak heat). Reads like textbook coax thermal attenuation to me, and it's uniform across every channel, not isolated to one — so my working assumption is it's an outdoor plant effect, not a bad channel/connector on its own.

Outside Temp (Degree F) vs Cable Modem Downstream Power (dBmW)

Update: Here's a graphic that shows the correlation between temp and power. The blank spots are where the management interface crashed.

What's making me second-guess "just normal thermal drift":

- SNR barely moves during the same window (~39.2dB down to ~38.5dB) — nowhere near a spec floor.

- Downstream power itself never gets remotely close to spec limits even at the daily low point.

- Upstream power rises in the same window (~45.2 to ~46.4 dBmV) — so the modem's own power-control loop is clearly reacting to something real on the whole path, not just a downstream quirk.

This isn't purely academic — some of these T3 clusters have coincided with real throughput/packet-loss degradation, and the management interface has crashed outright a few times, neither recovering without a manual power cycle.

Raw event log examples (MACs redacted):

- T3 timeout — dominant type, 71 of 81 critical entries over 10 days: No Ranging Response received - T3 time-out;CM-MAC=xx:xx:xx:xx:xx:02;CMTS-MAC=xx:xx:xx:xx:xx:22;CM-QOS=1.1;CM-VER=3.1;

- T4 timeout — only 1 occurrence in the whole 10-day window (2026-08-09 02:22:42 UTC): Received Response to Broadcast Maintenance Request, But no Unicast Maintenance opportunities received - T4 time out;CM-MAC=xx:xx:xx:xx:xx:02;CMTS-MAC=xx:xx:xx:xx:xx:22;CM-QOS=1.1;CM-VER=3.1;

- Short-form T3 (no MAC suffix) — 4 occurrences, all clustered ~05:56 local on 2026-08-07, right after that night's reboot — likely a logging artifact from the modem not yet having repopulated CM-MAC/CMTS-MAC post-reboot, not 4 independent events: No Ranging Response received - T3 time-out

So: 88% of critical events are T3 (no ranging response from the CMTS), essentially none are T4. Absolute downstream signal levels look healthy at every snapshot, but something isn't tolerating the transition well. When I pulled 10 days of critical events (72 matched against 5-min power data) and compared them against the modem's rate-of-change in power at that moment vs. a full-dataset baseline: 78% of critical events happened while power was actively changing (either direction) above the median rate-of-change, vs. 50% you'd expect if it were unrelated. That's a moderate, repeatable skew (P≈0.63 that a random event-moment has higher volatility than a random baseline moment) — real, but not absolute; roughly a fifth of events still happen during stable stretches, so I'm treating this as a contributing factor, not a proven mechanism.

My best guess is either (a) a connector/splice/amp somewhere in the drop or upstream return path with slightly degraded contact or reflection behavior that only shows up during temperature-driven mechanical movement, or (b) the modem's own ranging/equalization being sluggish specifically while conditions are actively moving, rather than at any fixed level.

Anyone seen this specific signature before — power/SNR fine in isolation, almost all T3 rather than T4, but fault rate tracking rate-of-change rather than absolute level? What would you check first in the field (F-connectors, ground block, a specific amp stage, the return path specifically given the T3-heavy pattern), and is this worth pushing on with the ISP, or does it sound more like a modem swap is the right first move to rule that variable out?

Posting this as a question rather than a bug report, since I'm not sure yet whether this is known/expected behavior, something specific to my setup, or actually new. Checked the "check this first before contacting support" pinned post and didn't see anything about API timestamp freshness, so figured I'd ask here before going to support.

What I'm seeing

I run a local monitoring stack that polls the MSP /v2/network-monitors API (quality/latency/ packet-loss data) every 30 minutes and logs the results, using the ts field from each record as the timestamp (not local poll time). While digging into a network event, I noticed the nearest firewalla_quality sample's ts didn't line up with when the measurement seemed to have actually happened, based on an independent local probe I also run for comparison.

That could've just been a one-off, so I checked it again today, independently, under ordinary calm conditions with nothing going on:

• Live API call, bypassing my own collector/cron entirely, made at 2026-08-09T14:00:42Z. The freshest record returned had "ts": 1786282200 → 2026-08-09T13:30:00Z — about 30.7 minutes stale at the moment the API served it.
• My collector's cron log confirms it fires every 30 min on the dot. The run that had just executed seconds before my live check could still only pull data through 9:30 AM EDT — same ~30min gap, matching the live call.
• For comparison, a locally-run active probe (SmokePing) checked at the same moment showed a data point only ~107 seconds old — no comparable lag, which makes sense since it's a direct local probe with nothing round-tripping through a cloud API.

So the ~30min gap looks real and reproducible, not tied to that one incident. ts is the only timestamp field in the record — there's no separate "measured at" vs "reported at" field — so I'm inferring it's meant to represent when the measurement was taken, but I could be wrong about that.

What I don't know yet

Everything above is under calm conditions. I haven't checked whether this lag stays constant or gets worse during an actual active event (box busier, MSP pipeline handling more data, etc.) -- that's still open on my end.

Questions for anyone who's dealt with this

• Has anyone else who does time-correlation work against this API (or firewalla_quality / similar endpoints) noticed something similar, or is my setup doing something unusual?
• Does anyone know whether ts is documented anywhere as measurement-time vs. ingestion-time?
• Is there a lower-latency path to similar data -- anything exposed locally on the LAN rather than through the cloud MSP API -- for anyone who's needed tighter timing than this endpoint provides?

Happy to share more detail on how I reproduced this if it's useful. Mostly just trying to figure out if this is a "known thing" before I go bother support with it.

Update: figured out the ts discrepancy — it's not an MSP bug, it's the alarm engine itself

Followed up on this myself by SSHing into the box and comparing the MSP API's ts field directly against what's stored locally in Redis for the same alarms.

Turns out each alarm actually has three separate timestamps on the box:

• timestamp — when the underlying event actually happened
• alarmTimestamp — when Firewalla's alarm engine actually decided to raise it
• applyTimestamp — a few minutes after that, looks like final processing

I compared several aids between local Redis and the MSP API directly — MSP's ts is an exact match, to the millisecond, of alarmTimestamp. Not a coincidence, not close — identical. So MSP isn't adding lag, converting timezones wrong, or reporting stale data. It's a faithful pass-through of what the box itself already recorded.

The real gap that I'm noticing is the one between timestamp and alarmTimestamp — i.e., how long Firewalla's own detection logic takes to actually fire an alarm after something happens. In my sample this ranged from ~1 hour to over 4 hours, and it's not a fixed offset. Makes sense for threshold/cumulative alarm types like ALARM_LARGE_UPLOAD — it's presumably waiting for enough data to cross a threshold before alerting, not reacting instantly.

Flows show a smaller, similar pattern too (ts vs _ts, event time vs. write time), roughly a ~12 min gap in my one sample — didn't fully chase that down but wanted to flag it in case it's relevant to anyone else.

tl;dr: if you need the true event time and not "when Firewalla noticed," don't rely on MSP's ts — you'd need the box's local timestamp field instead, which isn't exposed via the MSP API. For most dashboarding/alerting purposes though, ts/alarmTimestamp is accurate and consistent, just not instantaneous.

Happy to share more detail on the Redis key structure if anyone's trying to do something similar.

Was in the men's (crowded) bathroom after a Alison Krause concert at Wolf Trap. Someone says out loud "I wonder if that's the voice you hear if you get to heaven." At least a dozen guys all said "yep" in unison and then busted out laughing.

I bought a house in 2018 with a beautiful 40' × 20' inground pool—the first pool I'd ever owned.  I knew next to nothing about water chemistry or pool maintenance.  Fortunately, there was a great mom-and-pop pool supply store just five minutes from my house.  Every Saturday morning for the next seven years, I'd bring them a water sample for testing.  They'd hand me a shopping list that usually looked something like: "Add XX pounds of alkalinity, two bags of shock (sometimes four), and keep three trichlor tabs in the skimmers."  Honestly, I didn't question it. Other than the cost, I had no complaints because the pool was almost always crystal clear.  Then, at the end of last season, the store closed.  The next closest pool store is about 30 minutes away, so I figured it was time to finally learn how to take care of the pool myself. 

After doing some research (mostly on Reddit), I took the plunge and bought a TF-Pro test kit.  Since opening the pool on Memorial Day, I've been testing my own water, tracking everything in the PoolMath app, and occasionally sanity-checking my results with Claude.  I suppose I shouldn’t be surprised by the results.  Since switching to routine liquid chlorine maintenance, I haven't had to add alkalinity once—not once. I've consistently kept my water at roughly FC 7, CC 0, pH 7.6, TA 70, and CYA 50, with only minor fluctuations that stayed well within recommended ranges. The only exception was last week when my CC briefly climbed to 1. I added one dose of cal-hypo shock, and it dropped right back to 0.

Looking back, I realize I was probably adding a lot of chemicals simply because the pool store said I should.  Maybe my pool really needed them at the time, or maybe it didn't.  Either way, learning to test and understand my own water has definitely worth the effort.  My biggest takeaway? Maintaining a pool yourself really isn't that hard, and it's dramatically cheaper than I expected.  The money I've saved just by not routinely buying alkalinity increaser and bags of shock has already paid for the TF-Pro kit—and now I actually understand what's going on in my pool instead of just following instructions.

I bought a house in 2018 with a beautiful 40' × 20' inground pool—the first pool I'd ever owned.  I knew next to nothing about water chemistry or pool maintenance.  Fortunately, there was a great mom-and-pop pool supply store just five minutes from my house.  Every Saturday morning for the next seven years, I'd bring them a water sample for testing.  They'd hand me a shopping list that usually looked something like: "Add XX pounds of alkalinity, two bags of shock (sometimes four), and keep three trichlor tabs in the skimmers."  Honestly, I didn't question it. Other than the cost, I had no complaints because the pool was almost always crystal clear.  Then, at the end of last season, the store closed.  The next closest pool store is about 30 minutes away, so I figured it was time to finally learn how to take care of the pool myself. 

After doing some research (mostly on Reddit), I took the plunge and bought a TF-Pro test kit.  Since opening the pool on Memorial Day, I've been testing my own water, tracking everything in the PoolMath app, and occasionally sanity-checking my results with Claude.  I suppose I shouldn’t be surprised by the results.  Since switching to routine liquid chlorine maintenance, I haven't had to add alkalinity once—not once. I've consistently kept my water at roughly FC 7, CC 0, pH 7.6, TA 70, and CYA 50, with only minor fluctuations that stayed well within recommended ranges. The only exception was last week when my CC briefly climbed to 1. I added one dose of cal-hypo shock, and it dropped right back to 0.

Looking back, I realize I was probably adding a lot of chemicals simply because the pool store said I should.  Maybe my pool really needed them at the time, or maybe it didn't.  Either way, learning to test and understand my own water has definitely worth the effort.  My biggest takeaway? Maintaining a pool yourself really isn't that hard, and it's dramatically cheaper than I expected.  The money I've saved just by not routinely buying alkalinity increaser and bags of shock has already paid for the TF-Pro kit—and now I actually understand what's going on in my pool instead of just following instructions.

Recently purchased a boat with a Garmin Echomap Chirp 74sv that only has the built-in map. I would like to upgrade to one of the higher resolution maps (Bluechart G3 or G3 vision) so I can use auto routing, but there are so many options that i'm not sure which is right for this older unit. I'm in the U.S. and would appreciate a recommendation.