Did MESHTASTIC Die At Hamvention??

We have extremely dense meshes in areas of the UK now and have seen the same issues. Hopefully the techniques in this video will make it to the nerds over here 👍

"Packet" is the right term. The "CHIRP" is still a packet similar to tcp ip. CHIRP's (used in LoRa and other applications) involves transmitting data via chirp waveforms, which are organized into packets. [At least that's my story and I'm sticking to it 😅] Nice video, Thanks!!

Very honoured to be referenced in one of your videos. Thank you.

Meshtastic simple doesn't scale. It's not just airtime, but also the entire MQTT link concept and the fact that your node can "fill up" with node IDs, leading to the dreaded memory full message.

I put up my first Solar charging Rak 4630 device using Meshtastic OS. I picked up a 283 mile device, Which has since dropped off. I also picked up a 19 mile device. So it is working. not alot of activity local so it is something I will need to monitor for sure! Attempted an install on the garage roof but the light poles were too large... need to get larger hose clamps for it. Had rain and it is still working... charging as well... been on for 20 hrs and still at a 95% charge! So very happy with the performance. Also got a T-Deck and using it to test with as well. Always great to learn about things that are new! Now to connect with Jason here in TX and see if we can expand our influence. ;)

MQTT can be very useful and isn't necessarily a problem to the mesh. The problem arises because it is a fairly complex system and not well understood. New users that try MQTT using the default settings on the default channel will cause congestion, but using MQTT on a private channel with a custom MQTT topic (or through a private MQTT broker) is really not a problem. The thing is, unless you know what this all means and also have a known use case for MQTT, you are certainly better off leaving it alone. I have found it very useful for remote telemetry over Meshtastic, and it works well with my configuration and does not cause channel congestion.

Josh, Thank you for your awesome videos on Meshtastic. Due to your videos, I now have my new device sitting here, waiting on me to get off of my behind to print a new case.

Josh, I always enjoy that when you explain something, you give relevant technical details, go enough into the weeds to satisfy the hard core nerds and yet still break it down to the "green crayon is green" level for people like me.

Haven't gone down the meshtastic rabbit hole yet. That being said, our club is talking about it, so will probably go there soon. Thank you Josh!(for spending more of my money LOL) 🙂

The mesh at hamvention was crazy. Someone definitely had default mqtt server turned on the default channel. I was seeing nodes show up on the map from across the country. I also had mqtt on as well but I was using a club owned mqtt server so people back home could see everything that was happening.

I was experiencing issues similar that I actually paid for on my cellphone a decade ago and attributed it to system congestion then too. That bumping the head on ceiling quip toward the end was awesome btw.

One slight detail, unlike many other mesh protocols Meshtastic does not need to build the mesh up, it does not currently track who is in the mesh or where packets should be flowing. The mesh is implemented by using very clever CSMA/CA hacking, every-time a node hear a message it tries to rely it, but before doing so it waits the amount it waits is based on how well the message was received, if the reception was good it waits a very long time, if it were bad it waits a short time, and if while waiting it hear someone else relaying the packet is cancel it's own relay attempt, this mean just by waiting and listening you know if someone else farther away is relaying the message already, and if they are you do not yourself, if the wait time expire and you didn't heard anyone then you relay yourself. The congestion is usually NodeInfo (automated « I am here » messages used to show the list of Nodes in the app, but completely optional and not used in the meshing) and people trying to use the app as designed and send messages.

This happened in the UK a few months back as well. This is great real world testing and will be interesting to see how these tips help prevent it in the future.

I need to learn more about Mesh. I do a lot of volunteer work where cell phones have no coverage. Some folks are bulky about radios. FRS, enough said and GMRS has cost and licensing issues. Mesh might be great but IP68 or higher is a must. Excellent video and 73, KF0NNQ & WRVR260.

This is the same problem we had in the early days of networking And the early days of Wifi. This is why they created 100 base-T and 1000 base-T Because the old 10 base-T really got overwhelmed and we were not getting through from computer to computer on the network. Back then it worked just like this. There was no router It sounds like the system needs network controllers. So if a control station assigned the priority and who is on the network and when to send. Like cell phone cells work

CHIRP is the sound of the modulation. Regardless of what anyone calls it, packet is the correct term for the chunk of data transmitted as a unit (using CHIRP modulation). While not a "bug" in mestastic, the exhibited failure to scale is definitely a design limitation inherent in the choice of flood routing. There are smarter mesh network routing approaches that could be implemented and IIRC meshtastic is working on such. Flood routing is quick and easy to understand and implement, but it always fails this way and has since at least the days of even the limited flooding done by Netware SPX/IPX and NetBEUI in the 1980s and 1990s.

That one with the screen makes me think I of the Cybiko devices of the early 2000s.

Packet is a correct term; it is used by Semtech in the datasheets for the transceiver chips, such as the SX1276, etc.

The mesh should be adaptive, so each node can sense how many nodes are around it, and coordinate with them so they each take their turn and don't try to talk over the others. I imagine a protocol that's almost like a tune which they all know and sing together, allowing them to slot their messages in one after the other in a constantly repeating cycle. So each segment of time has 2 components, one where a new node can ask for that slot, and one where either a message is sent or a hold signal is sent to mark the slot as occupied. If your node asks for a slot, the others note it, if no other nodes are asking for it and there's no message or hold signal in that slot for a certain number of cycles then the mesh allocates it to your node. When you send a message, your node waits for its time in the cycle to broadcast and all the other nodes stay silent during that moment.

LONG-FAST is a modem preset, not a per-channel setting.