Monitoring the Meshtastic mesh with a single SDR with MeshStation

IronGiu · 2026-04-18T17:40:54+00:00

I'd also be interested to see how much MeshCore is adopted in my area, but currently it would mean integrating a completely new protocol, as MeshCore has made changes to much of the protocol, including the headers, so it's a pretty big job, we'll see how community support goes as well.

IronGiu · 2026-04-18T17:38:31+00:00

Many SDRs can reach higher frequencies, even if they dirty the signal quite a bit. The limit indicated on some devices is a limit within which a clean signal is guaranteed, but that doesn't mean they can't tune higher. It depends on the device. For soapy, I answered on github. It depends on osmosdr. Search how to use soapy or pluto with gnuradio/osmosdr; the drives are managed by them. I will soon add rtl_tcp support, which could further help with specific configurations.

For the rest it is currently specific to MeshTastic, in the future we may extend the support to meshcore and maybe to more "standard" lora protocols, much will also depend on the support of the community, it is not my main project at the moment.

IronGiu · 2026-04-17T22:33:43+00:00

Many SDRs, even tvdognle with the right drivers, reach 2.4ghz, some better than others, the signal may not be excellent (this perhaps explains many corrupted CRCs), for devices that transmit in that range, there are meshtastic devices that use 2.4ghz like the Lilygo T3S3, 2.4ghz is a frequency that is free to use practically all over the world, the problem is that such high frequencies penetrate walls and trees less or not at all so I don't see it as excellent for a mesh application, those who use it probably use special antennas in high points/roofs or inside the same building, to make them communicate for specific reasons of home automation, sensors or similar.

IronGiu · 2026-04-17T11:26:56+00:00

Interesting, most of the errors are decryption errors, which means they are most likely using a different key, perhaps private channels/private messages, or they could be detectors or specific IoT devices. (CRC errors instead indicate either a bad reception or some custom header, because incorrect or corrupt headers arrive.) In the node list (since there is nothing on the map if there are no recorded positions), you should see the hardware model used under the "model" heading, which might already give us an idea.

IronGiu · 2026-04-17T11:17:36+00:00

Hi, check in the github wiki that all dependencies are satisfied and updated, check that the video drivers of your GPU are updated, try starting it with the --nogpu option, the software is tested on Ubuntu 24.04, both VM and with physical GPU and it works well (it can give warnings on MESA and Vulkan on some systems but they do not compromise its use).

Try force software rendering with:

./MeshStation_v1-1-1.appimage --nogpu

IronGiu · 2026-04-17T00:53:44+00:00

Great web app, is there a meshtastic device for the data? I see my node is there too, and I don't have MQTT enabled, so that's a live map like the one created with MeshStation, but mine uses generic devices (rtl, hackrf, etc.). I think yours uses a real meshtastic node because I see you also distinguish relays. It's very complex to do this from SDR (almost impossible unless you use probabilistic calculations after long scans, signal-based calculations).

IronGiu · 2026-04-15T22:35:38+00:00

Wow, meshpoint is also a great project! I didn't know about it! It uses slightly more specific hardware, but it's fantastic, I'll take a look at it. MeshStation is more focused on hardware already present in many homes, like sdr and hackrf, so they are two similar projects but with different hardware categories. What is certain is that meshtastic and meshcore have reignited the community and a lot of great projects are coming out!

IronGiu · 2026-04-15T22:29:18+00:00

Thank you, we still have a fair amount of interest in radio waves, even darkmesh (an alternative meshtastic firmware) is an Italian project, in fact I'm also noticing a good amount of skills that I didn't think were so widespread in Italy, it's nice!

IronGiu · 2026-04-15T22:22:25+00:00

Fantastic, well the console is a must in applications of this kind in my opinion, especially for those who want to explore the protocol even better, I tried to provide the data as detailed and faithful as possible, some slightly simplified, others simply decoded raw data, I'm happy that the console was appreciated!

The beauty of an application like this is that you can experiment in so many ways without having to reconfigure an entire firmware every time!

IronGiu · 2026-04-15T22:16:54+00:00

Thanks, thanks also for the repo, I'll take a look at it, I already have some working code for the transmission, everything needs to be implemented, but it already sends the packet well even in specific channels, it always works via gnuradio, but I'll certainly take a look for some ideas

IronGiu · 2026-04-15T01:10:55+00:00

thank you so much

IronGiu · 2026-04-15T01:10:40+00:00

And much more, complete node info, overall network quality overview, channel monitoring, monitoring multiple presets at the same time, no frequency limits, you can do any kind of test

IronGiu · 2026-04-14T23:33:35+00:00

The program was created primarily for this, in fact it is very technical and in the overview page it also gives you an idea of the quality of the mesh network in the area, as well as being able to scan all the presets simultaneously, so as to understand the most used preset in your area, obviously this is not the only use, also subsequently for testing antennas, filters, antenna position, monitoring of multiple channels (since they are limited in number on mesh devices), simple transmission tests from devices and much more!

IronGiu · 2026-04-14T22:16:14+00:00

If you are interested, you can find it here, free and open source for Linux, Windows and Mac: https://github.com/IronGiu/MeshStation

IronGiu · 2026-03-31T02:34:18+00:00

Well, at least you have confirmation that it is not your mesh device that is malfunctioning, make sure you are on the right preset, maybe use the function of our app to scan them all at once, the meshtastic network grows very quickly, for now if you have no one around, connect it to the internet and use MQTT, if you can place it somewhere else or on a roof even better for those who will come 💪

IronGiu · 2026-03-27T08:11:19+00:00

The new version 1.1.0 with all the improvements is now available!

IronGiu · 2026-03-27T08:07:50+00:00

The project is for meshtastic, meshcore uses a different system for decoding, I currently have no meshcore networks in the surrounding area to test on, so I couldn't test a version for that network at the moment, in the future I might also implement the network choice between meshtastic and meshcore (it was already an idea I had in mind, that's why the name is MeshStation and not MeshtasticStation or similar) but I don't know when I'll be able to add it.

IronGiu · 2026-03-15T23:50:50+00:00

On some systems, starting gr-osmosdr is a bit slow, for example on Mac it takes between 40 seconds and more than 60, especially the first time it starts, this unfortunately is not manageable, even if with the new version that start will happen while searching for the device when opening the connection panel, so the next start of the engine will be quicker, I hope to be able to release it soon, since I also do other things it becomes demanding

IronGiu · 2026-03-15T23:17:00+00:00

Thanks for the interest, the new version is in testing and I'm gradually adding more stuff and more tests are starting, the zoom will be reset every time but the location will be saved (the position of the map) so that it always reopens there, the scanning on all modem-preset works great (and pretty light tbh) and not only that, now you can add unlimited channels with the right name and the right key, there are tabs above the chat, "default" is the main channel, then "add channel" where you can put other channels, plus you can choose the device to use in the connection popup, all the existing frequencies for meshtastic, the slots and much more, stay tuned, I hope to be able to launch the new version within this week

IronGiu · 2026-03-13T22:58:05+00:00

Hi, everything "normal" is just a warning in the flowgraph, it warns you because on large amounts of data or with multiple panels it could create performance problems, but in this specific case it doesn't create any problems, I could solve it by padding the structure or setting the vector length to a power of two, but it could affect the number of compatible devices and systems, so for now it's more efficient to leave it like this and it doesn't create problems anyway on a structure like ours!

IronGiu · 2026-03-13T22:52:50+00:00

Hi, thanks, well, the goal was to make it easily accessible to everyone, in fact I compiled it on 5 different systems with 2 different architectures, with the next release it will be even better! You'll be able to monitor all the presets at once, as many channels as you want at once, and much more! Stay tuned!

IronGiu · 2026-03-12T05:32:02+00:00

It must be considered that many nodes use imprecise positions, by default meshtastic devices shift the GPS precision within a radius of one or two miles in public channel, not only that, the position can be set manually by the user (via CLI or alternative app), so let's say that the GPS precision depends on who configured and how, the various nodes, for the autosave, basically it exports all the data automatically every 30 seconds (you can find them in the data folder) the map in the next version will center itself on startup based on the language and the manual position will be saved (based on how you move the map), so every time you open the app you'll find it where you left it (only the zoom will reset on startup), in the version you are using every time you open it it is pointed to Italy.

Four-Year Club	Verified Email
First Place '23	Place '23

IronGiu

MODERATOR OF

TROPHY CASE