Skip to content

HELP/WIP Create QUICKSTART.md - #3

Closed
NyanHelsing wants to merge 1 commit into
meshcore-dev:mainfrom
NyanHelsing:NyanHelsing-patch-1
Closed

HELP/WIP Create QUICKSTART.md#3
NyanHelsing wants to merge 1 commit into
meshcore-dev:mainfrom
NyanHelsing:NyanHelsing-patch-1

Conversation

@NyanHelsing

@NyanHelsing NyanHelsing commented Jan 25, 2025 •
edited
Loading

Copy link
Copy Markdown

hey any thoughts? im' getting errors when i build still;

eg

  • src/helpers/BaseChatMesh.cpp:2:10: fatal error: base64.hpp: No such file or directory
    • i did platformio pkg install -l densaugeo/base64 to resolve.
  • examples/simple_repeater/main.cpp:7:12: fatal error: SPIFFS.h: No such file or directory
    • ???

Also is there an -e tdeck i can run?

@NyanHelsing NyanHelsing changed the title WIP Create QUICKSTART.md HELP/WIP Create QUICKSTART.md Jan 25, 2025
@ripplebiz

ripplebiz commented Jan 26, 2025

Copy link
Copy Markdown
Member

Thanks for this. Looks ok.
There is no TDeck environment. The TDeck firmware is commercial.

@ripplebiz

ripplebiz commented Jan 26, 2025

Copy link
Copy Markdown
Member

The base64 should be handled by the lib_deps addition that you see.
Not sure why that one (densaugeo/base64 @ ~1.4.0) would not resolve(?)
Seems to be in the PIO registry.

@ripplebiz

ripplebiz commented Jan 26, 2025

Copy link
Copy Markdown
Member

Ah, found the problem you mentioned about base64.hpp, etc.
My bad. I've tested ALL the build target/envs now and they all build successfully now.

@NyanHelsing

NyanHelsing commented Jan 26, 2025

Copy link
Copy Markdown
Author

the tdeck firmware is closed source? seriously??

@ripplebiz ripplebiz closed this Mar 11, 2025
ripplebiz pushed a commit that referenced this pull request May 23, 2025
@adam2872
Merge pull request #3 from adam2872/revert-2-RAK4631-user-button
14ffde5 
Revert "RAK4631 analogue user button on input 31"
ripplebiz pushed a commit that referenced this pull request Aug 29, 2025
@Quency-D
Merge pull request #3 from Quency-D/dev
d93e03b 
Merge Dev
@nullrouten0 nullrouten0 mentioned this pull request Nov 5, 2025
Open
agessaman referenced this pull request in agessaman/MeshCore Nov 8, 2025
@adam2872
Merge pull request #3 from adam2872/revert-2-RAK4631-user-button
c934777 
Revert "RAK4631 analogue user button on input 31"
agessaman referenced this pull request in agessaman/MeshCore Nov 8, 2025
@Quency-D
Merge pull request #3 from Quency-D/dev
e67ffd6 
Merge Dev
arijanluiken added a commit to arijanluiken/MeshCore that referenced this pull request Dec 11, 2025
@arijanluiken
Security fixes: Replace unsafe string operations and improve packet v…
0b452af 
…alidation

- Issue meshcore-dev#3: Replace all strcpy/sprintf with strncpy/snprintf to prevent buffer overflows
  * Fixed CommonCLI.cpp: All command responses now use bounded string operations
  * Fixed RegionMap.cpp: Safe string copying for wildcard name
  * Removed password echoing (security issue)

- Issue meshcore-dev#7: Improve Packet::readFrom() validation
  * Add bounds checking before all memory operations
  * Validate minimum packet size upfront
  * Check transport codes fit in buffer before copying
  * Verify path_len and payload_len before memcpy
  * Prevent buffer overruns from malformed packets
@arijanluiken arijanluiken mentioned this pull request Dec 11, 2025
Open
@weebl2000 weebl2000 mentioned this pull request Feb 9, 2026
Closed
This was referenced Mar 2, 2026
Merged
Draft
ripplebiz pushed a commit that referenced this pull request Mar 20, 2026
@Quency-D
Merge pull request #3 from weebl2000/dev-heltec-v4.3
c6d5301 
Default LNA enabled=true and fix the sleep order
yellowcooln pushed a commit to yellowcooln/MeshCore-washtastic-e22p that referenced this pull request Apr 8, 2026
@MSmithDev
Merge pull request meshcore-dev#3 from mitchellmoss/codex/gps-time-sync
358597c 
[codex] improve photon repeater GPS behavior
@1nerdherder 1nerdherder mentioned this pull request May 11, 2026
Draft
ksanislo added a commit to ksanislo/MeshCore-LVGL that referenced this pull request May 26, 2026
@ksanislo
console + MQTT bridge UX improvements: get all, event-driven replies,…
0a373a5 
… placeholders

Three related improvements grouped because they share the same console.py
file and would require interactive hunk-staging to split:

1) `get all` virtual command (console-side intercept):
   - Same output as the --get-all CLI flag, but available inside the
     interactive shell as `get all`.
   - Added "all" to GET_PROPS so tab completion offers it.
   - Added intercept_with_serial() helper for commands that need the
     serial port (vs the existing intercept() for pure client-side
     commands like help/exit).
   - Added 3 more entries to GET_ALL_COMMANDS that were missing:
     `board` (hardware manufacturer/model), `clock` (RTC time, useful
     for sync verification), and `get bridge.type` (legacy bridge
     compilation status).

2) Event-driven send_and_collect (console-side performance):
   - Was: fixed `settle` sleep + drain loop. Each command paid ~500ms
     regardless of actual reply time. `--get-all` took ~25s.
   - Now: poll for the firmware's `  -> <reply>\\n` marker pattern;
     return as soon as the reply is complete. Typical reply: 30-80ms.
   - `settle` parameter now means "no-reply fallback timeout" (default
     0.1s) instead of fixed initial wait. Reply-producing commands
     extend the deadline by 200ms once the marker is seen, so slow
     replies don't get truncated.
   - `--get-all` now takes ~2-4s; single `get foo` ~30-80ms.
   - Function signature and default value preserved -- all existing
     callers (one-shot, batch, interactive) work without changes.

3) {client_id} / {pubkey} placeholders in mqtt.topic_prefix and
   mqtt.subscribe (firmware change):
   - New expandPlaceholders() helper in MqttBridge. Substitutes
     {client_id} (resolved client id, possibly auto-derived from
     pubkey) and {pubkey} (first 8 hex chars of this device's pubkey).
     Unknown placeholders pass through literally.
   - Applied at connect time so changes to mqtt.client_id automatically
     re-resolve the topic_prefix on next applyMqttConfig() cycle.
   - The empty default for mqtt.topic_prefix is now conceptually
     "meshcore/{client_id}" -- runs through the same expansion path
     instead of being a separate hard-coded snprintf.
   - Console help (`help mqtt`) and BLANK_DEFAULT_DESCRIPTIONS updated
     to mention placeholders, with examples.

Footprint impact for meshcore-dev#3 (firmware): +176 bytes RAM, +928 bytes flash.
Total stack at heltec_v4_repeater_mqtt: 3.6% RAM, 20.4% flash.
c03rad0r added a commit to c03rad0r/MeshCore that referenced this pull request Jun 24, 2026
@c03rad0r
fix: remove getPacketLength override (meshcore-dev#2), use LR2021 IRQ…
627909a 
… constants (meshcore-dev#3), make irqDioNum configurable (meshcore-dev#4)
dl9sau pushed a commit to dl9sau/MeshCore-fork-DL9SAU that referenced this pull request Jul 10, 2026
Thomas Osterried @claude
DL9SAU: meshcore-dev#3 path show - Politur (pubkey-Prefix, type-Name,…
e3eda8c 
… UNKNOWN)

Single-Contact 'path show'-Header lesbarer:
- A: 3-Byte-Hex-Prefix des pubkey mit anzeigen ('path <name> (aabbcc):').
- B: type-Nummer annotieren ('type=2 (REPEATER)' statt nacktem 'type=2').
  Mapping ADV_TYPE_* (0=none 1=chat 2=repeater 3=room 4=sensor).
- C: bei out_path_len == OUT_PATH_UNKNOWN (0xff) 'out_path_len=unknown' statt
  rohem '255' -- User interpretierte 255 sonst als 255-Hop-Weg. Die out=
  Zeile zeigt ohnehin schon 'UNKNOWN'.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
dl9sau pushed a commit to dl9sau/MeshCore-fork-DL9SAU that referenced this pull request Jul 21, 2026
Thomas Osterried @claude
DL9SAU: #0 'advert status' -- konsolidierte Beacon-Uebersicht
b35d727 
Bisher war das Advert-Verhalten nirgends auf einen Blick sichtbar (verstreut in
status/get + opt-in [adv]-Traces). Neuer Subbefehl 'advert status' zeigt:
Positions-Policy (none/gps-live/fixed), effektives Intervall + Grund (statisch/
bewegt/kein-Fix/keine-Position), next-Advert-ETA (HH:MM + in Ns), Scope (aktuell
zero-hop unscoped), nightly-Flood-Zeit, gps/fix_ever/moving. In 'advert ?'
gelistet. Surface fuer meshcore-dev#3 (advert type) + meshcore-dev#4 (min-interval).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
dl9sau pushed a commit to dl9sau/MeshCore-fork-DL9SAU that referenced this pull request Jul 21, 2026
Thomas Osterried @claude
DL9SAU: meshcore-dev#3 Stufe 1 -- autoadv -> advert periodic/nightly …
20021cd 
…umgezogen

'autoadv zerohop on/off' -> 'advert periodic on|off', 'autoadv nightly on/off'
-> 'advert nightly on|off' (gleiche AUTO_ADV_ZEROHOP/NIGHTLY-Bits + trigger).
Top-level 'autoadv' entfernt (105 Zeilen), ersetzt durch Signpost (kein
funktionaler Alias, User-Wunsch). help autoadv + status-Label + 'advert ?'
nachgezogen (status: 'advert: periodic=.. nightly=..'). Fundament fuer Stufe 2+
(moving-only, scope, interval).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
dl9sau pushed a commit to dl9sau/MeshCore-fork-DL9SAU that referenced this pull request Jul 21, 2026
Thomas Osterried @claude
DL9SAU: meshcore-dev#3 Stufe 2 -- advert periodic moving-only
a2c1d64 
Neuer 3-State: 'advert periodic <on|moving-only|off>'. moving-only = periodischer
Advert nur wenn _is_moving (im Stand still -> spart Airtime/Akku, kein Zumuellen).
Bit AUTO_ADV_MOVING_ONLY (0x04) ZUSAETZLICH zu ZEROHOP in der schon persistierten
auto_advert_enabled -> kein neues NodePrefs-Feld, kein Migrations-Risiko.
Sende-Skip im loop (bei Bewegungsbeginn zieht updateMotionTracking den Advert eh
vor -> feuert dann sofort). advert status zeigt off/on/moving-only; advert ? doku.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
dl9sau pushed a commit to dl9sau/MeshCore-fork-DL9SAU that referenced this pull request Jul 21, 2026
Thomas Osterried @claude
DL9SAU: meshcore-dev#3 Stufe 3 -- advert periodic/nightly scope konfi…
5d9e6bd 
…gurierbar

Zwei neue NodePrefs (append-only, Default 0 vor loadPrefs -> Alt-Datei bleibt 0;
+ Backup kv_uint + Restore clamp 0..2):
  advert_periodic_scope: 0=zero-hop (Default), 1=local, 2=region
  advert_nightly_scope:  0=follow    (Default), 1=local, 2=region
CLI: 'advert periodic scope <zero-hop|local|region>',
     'advert nightly scope <follow|local|region>'.
Auflösung: resolveConfiguredAdvertScope (local=#local Build-in-Key; region=geo-
aufgeloest via chooseGeoFallbackScope, Fallback #local). doNightFloodAdvert nimmt
bei !=follow den konfigurierten Scope; doPeriodicZeroHopAdvert sendet bei
local/region scoped flood (3-Byte-Pfad, hop-limitiert) statt zero-hop -- Scope VOR
createSelfAdvert aufgeloest (kein Paket-Leak). advert status + 'advert ?' zeigen
beide Scopes. Defaults unveraendert -> kein Verhaltensbruch.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
fkallay1 added a commit to fkallay1/MeshCore that referenced this pull request Aug 20, 2026
@fkallay1 @claude
feat(nicerf2021): ring buffer guardu + A/B pravidla CMD_DAT vs odtlacok
953ea4c 
Doteraz sme vedeli, ze guard vystrelil 8x v jednom 25s okne, ale nie ci to boli
skutocne zachrany alebo falosne poplachy - guard nic nezaznamenaval. A zaroven
sme netestovali samotnu opravu navrhnutu do RadioLibu, len jej kriterium.

Toto riesi oboje. Za #ifdef FK_LR2021_SPI_DIAG ide getPacketLength() cez novy
fkDiagPktLen(), ktory:

1. cita dlzku sam (fkRawPktLen, dve transakcie), takze vidi status bajt PRAVE
   toho citania, ktore hodnotu vyrobilo - inak sa to overit neda, RadioLib si
   status spotrebuje vnutri;
2. o zastaralosti rozhoduje podla CMD_DAT, teda podla pravidla navrhnuteho
   upstreamu - cize ta oprava realne bezi na zeleze;
3. zaroven vyhodnocuje aj nase odtlackove pravidlo (hodnota == irq[31:16]) a
   zapise, ktore z nich vystrelilo;
4. ak ani po 4 pokusoch nedostane CMD_DAT, spadne na kniznicne citanie, aby sme
   na tom nikdy neboli horsie.

Udalosti (fp, prva hodnota, finalna hodnota, stat, pocet pokusov, ktore pravidlo)
idu do kruhoveho buffra na 8 zaznamov. Z horucej RX cesty sa NIC netlaci - zapis
do Serialu by zastavil prijem. Vypis je az cez CLI 'fk spifix'.

Tym sa da rozlisit falosny poplach: rule=FP bez CMD a first == final znamena, ze
dlzka bola spravna od zaciatku a odtlacok sa len nahodou zhodoval. To je presne
podozrenie na tych 8 udalosti z 09:11 - v tom okne boli dva hodnoverne 68
bajtove ramce a 68 je odtlacok pri RX_DONE|CRC_ERROR, cize 2 x 4 pokusy = 8.

Nediagnosticka cesta ostava nezmenena (overene buildom MeshTracker_X1_repeater),
PR vetva sa toho netyka.

Overene na zeleze, build meshcore-dev#460: prijem zdravy (11 ramcov, rxerr=0, miss=0) a dlzky
spravne - #1 len=61 path[4] -> meshcore-dev#2/meshcore-dev#3 len=63 path[5], teda +2 bajty na hop.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

2 participants

@NyanHelsing @ripplebiz