You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Session Handoff [rv3028-eeprom]: #3433 cut to a one-liner; Copilot triage answered on #3545 and #3421 #20
Read Copilot's round on #3433 at bbacf47a, once Pieter has re-requested it in the web UI. Done when every headline point and finding is judged against the code and answered. Read the review body, not just status: headline-only points open no thread.
Cleanup, once Pieter is done with hardware: the -hw-3545, -hw-3421, local/rv3028-probe-* and local/rtc-probe-test worktrees, and the board's final firmware. Ask Pieter about each.
Zephyr: its BSF guard (local 67fda87) waits on Pieter in that session. zephyrproject-rtos/zephyr#121252 waits on maintainer approval of its CI workflows.
Internal dependencies
Step 1 waits on Pieter's re-request. Steps 2 and 3 can run at any time.
RX8130CE weekday is upstream as liquidraver/ZephCore#101 (0e93948). It also sets the meshtracker_x1 YSN8900 one-hot. MeshCore never drives that chip, because its meshtracker_x1 uses VolatileRTCClock.
Upstream dev is still 3e3150c8, and the fork dev mirror matches it.
0 parked. The fork has no decision label and no open decision issue. Every question this round was answered in the session: post both triage replies, cut meshcore-dev#3433, hardware re-test, push.
updated the title and body, and checked that the links resolve.
What not to repeat
ENV_SKIP_GPS_DETECT does nothing on a RAK4631. RAK builds detect the GPS through rakGPSInit()/gpsIsAwake(), which need live UART data. Only initBasicGPS() reads the flag. On the bench board, three reboots and one forced build all gave zero settings. To test a one-setting path there, you need a GPS that is actually talking at boot.
"No caller can set year 2000" was too strong at first. The CLI and the companion refuse a backwards time, but GPS sets whatever the receiver reports. Check every setCurrentTime caller, GPS included, before making a claim like that.
The RAK serial-DFU bootloader enumerates as usb-RAKWireless_WisBlock_RAK4631_<serial>-if00. Flashing by by-id path, with the touch on the app by-id, worked first time on all three flashes this round. The project memory meshcore-hardware-ground-truth is updated.
Step 1 done (2026-10-05 21:20Z): Copilot's round on meshcore-dev#3433bbacf47a ran degraded during the Actions outage and raised one finding, that start < 0 is meaningless if start is unsigned. start is declared int (L321), so the finding is wrong. At Pieter's choice it was answered and resolved with no code change: meshcore-dev#3433 (comment). The status coverage warning (no file table, since the round on ccff85f was on a different file set) is the lite-effort shape, so re-requesting on the same head isn't the remedy. meshcore-dev#3433 now waits on maintainers.
Next steps, in priority order
bbacf47a, once Pieter has re-requested it in the web UI. Done when every headline point and finding is judged against the code and answered. Read the review body, not juststatus: headline-only points open no thread.updatedAtafter 2026-10-05T21:00Z is new. Watch #3434 for a maintainer verdict.cross-firmware-parity-policy). ZephCore's handoff is ptr727/liquidraver-ZephCore#46.out_path_len; details are in link Session Handoff [rv3028-eeprom]: Two RTC PRs re-pushed with cross-firmware fixes; triage Copilot headlines #19, step 4. Don't start them before then.devmoves, or a PR merges or is declined: follow link Session Handoff [rv3028-eeprom]: Three MeshCore PRs upstream; watch and respond to review #17, steps 3 and 4. Adopt an RTC only if its time registers read like that chip 🤖🤖 meshcore-dev/MeshCore#3544, Store RV3028 backup switchover and trickle charger config in EEPROM 🤖🤖 meshcore-dev/MeshCore#3545 and Read and write the RV3028 clock atomically, and reject switchover-garbled transfers 🤖🤖 meshcore-dev/MeshCore#3421 all touchAutoDiscoverRTCClock.cpp.-hw-3545,-hw-3421,local/rv3028-probe-*andlocal/rtc-probe-testworktrees, and the board's final firmware. Ask Pieter about each.External blockers
sensor liststart index 🤖🤖 meshcore-dev/MeshCore#3433 needs Pieter to re-request it in the web UI. It wasn't requested by the 2026-10-05 force-push.sensor liststart index 🤖🤖 meshcore-dev/MeshCore#3433 and PassTELEM_RAK12500_ADDRESSto the RAK12500 I2C probe 🤖🤖 meshcore-dev/MeshCore#3434.67fda87) waits on Pieter in that session. zephyrproject-rtos/zephyr#121252 waits on maintainer approval of its CI workflows.Internal dependencies
CommonCLI.cppbounds next tosensor list, so check Reject a negativesensor liststart index 🤖🤖 meshcore-dev/MeshCore#3433 first, if it has merged by then.State
fix/rtc-probe-identity@9d0d5e31(c36cb9ee)fix/rv3028-eeprom-config@23b23b24(e74c5c60)fix/rx8130ce-week-onehot@8c9c9772(4cdd5d71)fix/rv3028-atomic-read@c408f88b(65907457)sensor listfix/sensor-list-paging@bbacf47a(ec05125f, fork PR #8)sensor liststart index 🤖🤖 meshcore-dev/MeshCore#3433 was cut to one line at Pieter's go-ahead:if (start < 0 || start >= end). It matches liquidraver/ZephCore#100, which merged as d1cc647 after its owner called the larger fix over-engineered.sensor liststart index".VolatileRTCClock.devis still3e3150c8, and the forkdevmirror matches it.c3f0566b, envRAK_4631_hwtest), and its RTC was on time at 20:43Z. ZephCore's board 26B9 is attached too, so leave it alone.The parked decision queue
0 parked. The fork has no
decisionlabel and no open decision issue. Every question this round was answered in the session: post both triage replies, cut meshcore-dev#3433, hardware re-test, push.What the last round did
sensor listled to cutting Reject a negativesensor liststart index 🤖🤖 meshcore-dev/MeshCore#3433 down.sensor liststart index 🤖🤖 meshcore-dev/MeshCore#3433:devinto the work branch;ec05125f;bbacf47a;What not to repeat
ENV_SKIP_GPS_DETECTdoes nothing on a RAK4631. RAK builds detect the GPS throughrakGPSInit()/gpsIsAwake(), which need live UART data. OnlyinitBasicGPS()reads the flag. On the bench board, three reboots and one forced build all gave zero settings. To test a one-setting path there, you need a GPS that is actually talking at boot.setCurrentTimecaller, GPS included, before making a claim like that.New learnings
usb-RAKWireless_WisBlock_RAK4631_<serial>-if00. Flashing by by-id path, with the touch on the app by-id, worked first time on all three flashes this round. The project memorymeshcore-hardware-ground-truthis updated.