Matthew GreenI’ve been working on a little simulator for MeshCore, written entirely using Claude Code. I was hoping some MeshCore devs might take a look and let me know if there are features they could use. https://github.com/matthewdgreen/meshcore_sim #meshcore
MarSik@matthew_d_green I wonder if it is possible to adapt the #MeshCore core logic to run as a PC app and transmit or receive via a serial KISS TNC. Basically separating the protocol from the radio head. Because I just built one for testing LoRa and FSK ;)
tugaBroadcast abuse isn't well received in software networks.
You can breach the domain with STUN and similar but it would no longer be mesh.
🤔
@tuga @matthew_d_green I think you misunderstood the idea.
I would put a KISS protocol TNC radio module (just a modulator and PA really) out and run the whole #MeshCore logic as a software on a remote computer. Similar to how telcos use eCPRI.
This would still act as a regular MeshCore device.
What you are talking about is a bit unclear to me, but it sounds like the tncattach or 802.15.4 / 6LowPAN use case. Which is also totally valid, but different from what I want here.
fdlamotte 🇩🇴@marsik @tuga @matthew_d_green maybe have a look at pymc core
@fdlamotte @marsik @tuga All of these projects seem to operate on a 1:1 PC/radio model. I think a better design would move the client logic to a PC/smartphone, but each radio device could support many clients — each with their own public key/identity. You’d have to use BLE advertisements to support many clients per radio.
@fdlamotte @marsik @tuga I’m planning to prototype this next week just for fun, to see if it works. But curious if there have been any experiments in this model or if it’s a bad idea for known reasons. (I know iOS background BLE receiving is very very bad.)
This was talked already and totally valid. You don't even need different advert types, as you only have to tell the radio to send/receive packets and let the PC deal with everything related to identities
All the receiving part is already possible using rx_log from companion radio. So I think the only missing piece would be a send_raw_packet
Big advantage is that it breaks the contact number limit. The drawback is you loose mailbox operation.
@fdlamotte @marsik @tuga My big concern is that in public spaces you have to throttle or gate people accessing the thing. For broadcast (read) only that doesn’t matter but for writes I guess you’d need permissioning or throttling.
Taasz/Woof@marsik @matthew_d_green I remember playing around with Reticulum awhile back and it can operate over a bunch of different hardware like that. https://reticulum.network/
@marsik I think that’s basically what this does. It’s a real MeshCore node with all the radio layers turned into stdio ports. A better design would define this explicitly as a HAL.
@marsik oh never mind, I understand what you’re saying. What I want is that but bigger: I want a single radio to be able to support 100 simultaneous smartphone clients via BLE advertisements. For protests and natural disasters.
@marsik I’m planning to code this up next week.
@matthew_d_green Cool, I wonder how the bluetooth will fare in such situation. I think you will face issues with pairing keys, frequency spectrum usage and buffering in the TNC. Heltec V4 (for example) has 2MB of PSRAM and that is plenty for MeshCore packets, but LoRa is slow sending that out. Also the duty cycle limits will kick in (max 10% where I live).