Maybe I should watch this again more carefully, but I did not understand how to get a map of my area to see whether I should deploy a repeater and where.
@@lua-nya Don't feel bad, there's a lot to that question. I believe the data for the map came from his discord meshtastic group for the area, but I don't believe he says for sure. As to where and when to deploy a repeater? What I've been telling people is that it's something that kinda has to be planned for, you should talk to your local community. One part of it, is the node for a repeater should be able to see a lot more nodes than any other node in the area. This is because a repeater forces packets to route through it, so if you don't see a large area with the repeater, you're just wasting hop counts for no reason, much like how the first part of the video explains. The second part, is you want the repeaters to be far apart from each other. They should be able to consistently make contact with only a few (and really, as few as possible to get the coverage you want) repeaters in their range. This is also explained by the first part of the video. If there's a repeater in between two others, then packets are just going to waste hops going through a repeater they didn't need to. Did that help any?
@@PockyBum522 One part of the community outreach is that you need to have a better idea than just 'I live on a hill...' I'd say that at the very least you should have, or perform a site survey, where you first see if you can see one or more 'rotuer' elements that can see each other. If you can, then you may want to set up as a Client first, as it will resend packets as well, If you can see two router elements that can't see each other, then your node _may_ provide a bridge for packe traffic between clients of either or both of those nodes. If you are a ham, you might consider a repeater to be a bit like a 2m or 440 repeater (or any of the other bands they are on, 10m, 5m, 220, 10cm) where a client is acting a bit more like a cross band repeater in your car or on your roof, that you link with your HT to in order to reach out to the greater mesh. I would love it if I had an easy way (that I know, so it's mostly just training on my part) to set up my mobile link with short-fast, and the link I'm treating as a client be able to interlink that shortfast with the long-slow (or even short-slow..) Effectively I'd like to be able to bridge my t-deck in 'local/low power' mode to a larger mesh through a T-beam on a home tower that can see the people in the area. (or one in my truck when mobile, or, you get the idea.) Perhaps I'm just missing elements of the configuration that I need to learn.
Thank you for the video! One thing I have not seen a good explanation of is tracker mode. The scenarios I would use are tracking individuals in town at an event, tracking kids in a neighborhood, and tracking while camping or hiking. Even if we are on a private channel/encryption key, I worry about flooding the mesh.
Sure thing! Appreciate you being mindful of the mesh! It should probably be fine, just depends on how many people are on the mesh. Meshtastic will still route encrypted traffic even if it's your own key, so your concern there is correct. Since most of your scenarios are at a local level, you likely wouldn't need help from the greater mesh and use your own mesh in these scenarios by either switching the modem preset to LONG_MODERATE or staying on LONG_FAST and changing the frequency slot.
Some scenarios not mentioned here. Temporary but high altitude nodes. Ie, Kite flown, or drone based nodes. they can be 400' up, for 10-20 minutes (or a couple hours in a kite or balloon) router/repeater/router_client modes are probably not ideal or appropriate. Maybe client? Or the recent trend in "commercial airplane passenger" nodes.
Glad the algorithm showed me this video. We were just talking about what modes to use in the long fast chat tonight. changing a few of mine to client mute now.
I wish those of us in Roane had access to a tower way up in the air. Then we could have one "Router" and a few Clients. Unfortunately neither your nor my nodes show on the maps of this video.
@@The_Comms_Channel I made that comment for Yardsale. On one of the latter maps of the video it showed a Client where I know a Meshtastic user lives. Due to the terrain of this part of Roane County it is difficult to have comms between us. EX: I live at 800' ASL and I have two other Meshtastic users within 5 miles of me but they also live at 800' ASL but on the other side of a ridge that peaks at 1000' ASL.
Awesome video, I’d like to see some urban scenarios. I’m in Seattle and would like to put a router on a large building. I also want to place enough clients around to relay, but don’t want to mess up the mesh
Question: You initially demonstrated the 'ideal' router scenario, then went on to show an improper config. How does Meshtastic devices 'know' that there is another router taking the hop count(s)? For instance, bounce 3 became bounce 2, but if it already received the data (as previously demonstrated), why wouldn't it re-broadcast as 3 vs. 2 and so on?
Meshtastic uses the signal level to determine which hop is the "furthest". So if the mountain top routers have good signals to each other and then someone who makes their rooftop node a router with maybe a crappy antenna, or the signal has to go through trees, etc. then that node appears to be the furthest and will be the next hop.
I am very new to this and one of the first setup videos I watched they specifically said to use the router setting. I'm sure there's a lot of bad info going around to us beginners.
Neato! That definitely helps for deployment options Out of curiosity, are there actual mesh routers in S.TN? Like Cleveland, Etowah, Ooltewah, etc? I'm curious because I can see some of those mountains from my house...
Thank you for the great explanation. Layer 2 routers actually have tables so they know what to forward, because they are part of that link. Question - has anyone set up nodes with Yagi antennas? Four nodes with four antenna's on the same roof, Each antenna only RX/TX in one cardinal direction: N,E,S,W The nodes communicate with each other. electrically not using RF since each Yagi is "blind" to the other three not in that Yagi's line of sight.
Sure thing! For the yagi question, yagi will still send some signals out around it, so they would still be in range of each other. In my testing I've had to get at least a half a mile away before loosing signal
In the first scenario; what keeps the the original routers from still receiving and rebroadcasting even with the less-than-ideal-configured ones in the mix?
Sure thing! Thanks for watching! The only time these should be used is at the highest point in a location. Generally, this means on mountain tops or if you're in a flat area, a tall tower or building. ROUTER_CLIENT is going away due to this issue being so prevalent. ROUTER and REPEATER are the same for the most part. Except REPEATER won't show up as a node on the list.
Being in client_mute seems antithetical to the decentralised mesh ideal, and I think that may be a stumbling block for a number of people. As a noob I know it feels uncomfortable, I don't want to be seen as a leecher, but I begrudgingly accept that I'm more helpful by shutting up, haha
Have you heard about the FCC's latest proposal for rulemaking WT Docket No. 24-240 to take a portion of the 900 MHz band away from amateur radio operators? This would affect Meshtastic users. RUclips user K0LWC has a great video explaining it.
Was the fact that you had drone footage in Ramsay a concidence? We have a group here wanting to set up a mesh. If you know more than I do about the area, I would like to meet with you.
Nice tips and all very useful video Can you revisit how to admin a node through admin channel? I think they added a safer way to do it but I can't find many information about how to set it up. Thank you
Disaster Scenarios ? there are some places that were completely cut off, And Meshtastic not needing a Ham maybe good for general people (client_mute mode) ?? Scenarios: > Already established Meshtastic network for Disaster. > Rapid Deployment Scenarios. > Temporary high altitude nodes. anyways my main takeaway is that "Client" = "Client localized repeater" "Client_Mute" = "Client End-user"
If it's a festival with 100+ nodes, then the last example in the video is best (SHORT_FAST and CLIENT) If it's less than that, then MEDIUM_FAST and CLIENT should be fine. Since these scenarios are away from the main mesh, CLIENT is fine.
Thanks for the comment and question! There is a tracker role that wasn't discussed in the video in order to focus on the more common ones. The tracker role is very GPS tracking focused and broadcasts GPS positions as a priority so it's not the best fit for a mobile node intended for communicating.
@The_Comms_Channel Thank you. I kind of guessed that it would be similar to a Client_Mute since ATAK would need as much bandwidth as possible, but I didn't know if there was testing/data on it.
Need plug-n-play compatibility with ATAK CIV, portable, solar rechargeaable. Currently meshtastic a little cumbersome and confusing for average consumer. Something built to power on and connect to ATAK meshtastic plugin without configuring anything other than network name/login, would greatly imporove the reach and use of this technology
I'm new to matchstick but if I remember right they change the protocol to try to send packets to the farthest nodes you have a good signal to to try to keep wasted hops down to a minimum. And I could be wrong on this but is it recommended to increase your hops allowed to the maximum of 7 if you're trying to go a long distance add densely populated mesh Network?
It's not recommended to increase to 7 hops. 3 or 4 is recommended. Only increase if absolutely necessary. High hop counts are another issue, but I didn't discuss in the video.
Meshtastic uses the signal level to determine which nodes are the furthest for the next hop. If someone has a node at their house set as a router, it's likely going to have a lower signal level than the node on top of the mountain and look further so the next hop will be that home router node instead of the next router on the mountain.
@@The_Comms_Channel I have a good idea every now and then currently there are no nodes in my area of Middle Tennessee so I will be putting up a couple thanks for the difference between client and repeater
While this is a video for the BBS, you could follow the same process up until 4:14 in the video to install it ruclips.net/video/4LuVoDQY-Kc/видео.htmlsi=2apubUq7NPqLmPQU
I think that would be best in my opinion, but I can see the other side of that where it wouldn't be a mesh and the user's may not know to change it to meet their situations.
Would it make sense/be possible that if a user selects the router role, that the hop count isnt counted? I could see this over loading certain devices if the router role is selected, but maybe a pop up warning could be shown if selected. Edit: Thinking about it more, i suppose this might cause an infinite loop if routers keep picking up the message. Does each message have a unique ID? The router could not rebroadcast tha ID more than say 2 times if so.
They are encrypted, so it is anon in that sense. Since they are radios, it is potentially possible to locate them via their signals and direction finding. I suspect they are harder to find than normal radios though. We'll be testing this out in a future video
@The_Comms_Channel thanks for responding. I'm interested in off grid free forms of communication I came across mesh networks a year ago and have been doing research on it. Modern tech is to big brother and unreliable at times I want a way to send text within a few miles without 3g 4g ect. Any direction you can point me in to get started as far as devices. I have a few pc's plus sdr radio receivers ham radios ect and other things so I'm pretty good with tech and setting up things. thanks again.
@@brittanycunningham787 Sure thing! Meshtastic or a ham radio with APRS should fit the bill! Meshtastic is the best if you need encryption There's a number of good options out now that don't require you to build it yourself. I've done some reviews on them and linked them below if you're interested in learning more ruclips.net/video/YPguv_C6LOY/видео.html ruclips.net/video/F1b7BYhhMTM/видео.html ruclips.net/video/Y7V54jMnmOg/видео.html Also just reviewed an inexpensive ham radio with APRS ruclips.net/video/4mQucwO8FJU/видео.html
This is a good site but even if an area appears empty on this map, there could be something there that isn't reporting its location meshtastic.liamcottle.net/
isnt meshtastic calculate the smallest route anyway? so if you have 50nodes between A and B the packets will only use the nodes that are most efficent and low count to reach the final destination.
It uses the signal level to calculate the furthest node. So if you have direct line of sight from mountain top router to mountain top router with good signal and a user sets up a router with a crappy antenna or a signal that has to go through trees, etc. it's going to have a lower signal level and appear to be the furthest node when it really isn't.
@@The_Comms_Channel but i think it does like a traceroute to see what node the packets need to go thru to reach the destination. so if there are more or less stations in between it doesnt matter since it will adapt itself anyway. it is the dynamic part of the mesh.
@@crowbrocaw you can change the amount of hops (7 max) but it's not recommended to do more than 4. High hop counts also create another issue I didn't discuss in this video - congestion
Nodes in shown examples are not named, so its hard to talk about them. But lets try anyway. At 3:56 you have scenario with added redundant routers. Since 4 is heard by 3 and 2 at the same time, i would assume that 2 would not use TTL decreased by node 3, and in fact both of 3 and 2 would retransmit the packet with TTL of 3. Same situation for next hop between 2-0. With this i do not think that hop count is a problem here. What could be instead is what you mention at the end - ch and/or air util. Proposal at 5:11 places the local central node as a client instead of router, which means that it sometimes will see a packet from remote place but wont retransmit. That would mean creating a local pocket of mute clients with very unreliable communication. Please do correct me if my understanding of situation is not correct.
My understanding is that Meshtastic uses the signal level to determine how far a node is and will use that one as the next hop. Since the mountain top nodes are in elevated positions with direct line of sight, they will have a stronger signal than a node on someone's roof that has to go through trees or maybe doesn't have as good of an antenna. Even though these are closer, since these will have a weaker signal, they'll appear to be farther away and it will try to use that one for the next hop.
The example at 5:11 100% does not need to be a router. Client will be perfectly fine in this situation. Best rule of thumb is if there are Routers in the area on tops of mountains or tall towers, there is no need for additional.
Main problem is congestion. routers / nonmuted clients are more chatty, generating unnecessary / redundant traffic. less traffic is better ➡ less chatty nodes are better. this is radio system. radio spectrum does have limited "real estate", every timeslot matters.
Network routing is hard. Mesh routing is even harder. Can we show some hard evidence what in fact is better? Hard rules, maybe multiple simulation tests?
I can’t reach the nodes in my area on medium fast and they are all switching to MF from long fast because they say the next software will myMF the default I could reach them on long fast
I can't find anyone saying that there. Also, there is no mention of that in their goals board github.com/orgs/meshtastic/projects/20 There's also a goal to update LONG_MODERATE to be further away from LONG_FAST to reduce collisions
The problem is that Meshtastic doesn't understand its own architecture. It should use the layout of the nodes in the area to dynamically determine how to route.
@@The_Comms_Channel Yes, it's a proper challenge. But I think it's something the Meshtastic guys need to build into the protocol. Communicating the GPS locations of nodes and signal strengths would allow building optimised routing. The users might just perhaps want to configure whether they prioritise distance or bandwidth between certain nodes.
@@ChristieNel Sounds like a good idea. Every node shares what they see to the mesh -> GPS info and signal strenghts. Based on that, the mesh as a whole could build a rudimentary map of whats out there. This way every node has an rough idea of node locations and how best best route packets. Not sure how complicated this would be, but I'd assume if you'd let the "map info" slowly propagate thought out the mesh, it could work and not just cause massive congestion.
@@samik83 Something along those lines is what I'm thinking. The challenge is to do it in a decentralised fashion. You don't want one node to do all the deciding, or one naughty/bad node can blow up the whole network. And different versions of nodes can also cause chaos. Best might be to design the routing such that each node makes its own decisions and the deciding algorithm is such that this optimises the overall network. So it comes back to nodes specifying a path rather than just the next hop.
This is fantastic. Now I have something to link every time someone asks "should I set my node to router"
Haha, happy to help!
Maybe I should watch this again more carefully, but I did not understand how to get a map of my area to see whether I should deploy a repeater and where.
@@lua-nya Don't feel bad, there's a lot to that question.
I believe the data for the map came from his discord meshtastic group for the area, but I don't believe he says for sure. As to where and when to deploy a repeater?
What I've been telling people is that it's something that kinda has to be planned for, you should talk to your local community. One part of it, is the node for a repeater should be able to see a lot more nodes than any other node in the area. This is because a repeater forces packets to route through it, so if you don't see a large area with the repeater, you're just wasting hop counts for no reason, much like how the first part of the video explains.
The second part, is you want the repeaters to be far apart from each other. They should be able to consistently make contact with only a few (and really, as few as possible to get the coverage you want) repeaters in their range. This is also explained by the first part of the video. If there's a repeater in between two others, then packets are just going to waste hops going through a repeater they didn't need to.
Did that help any?
@@PockyBum522 One part of the community outreach is that you need to have a better idea than just 'I live on a hill...' I'd say that at the very least you should have, or perform a site survey, where you first see if you can see one or more 'rotuer' elements that can see each other. If you can, then you may want to set up as a Client first, as it will resend packets as well, If you can see two router elements that can't see each other, then your node _may_ provide a bridge for packe traffic between clients of either or both of those nodes.
If you are a ham, you might consider a repeater to be a bit like a 2m or 440 repeater (or any of the other bands they are on, 10m, 5m, 220, 10cm) where a client is acting a bit more like a cross band repeater in your car or on your roof, that you link with your HT to in order to reach out to the greater mesh.
I would love it if I had an easy way (that I know, so it's mostly just training on my part) to set up my mobile link with short-fast, and the link I'm treating as a client be able to interlink that shortfast with the long-slow (or even short-slow..) Effectively I'd like to be able to bridge my t-deck in 'local/low power' mode to a larger mesh through a T-beam on a home tower that can see the people in the area. (or one in my truck when mobile, or, you get the idea.) Perhaps I'm just missing elements of the configuration that I need to learn.
Perfect timing for this video, thanks! Have just spent all afternoon driving around the hills wondering why I can't see my remote nodes.
Sure thing! Hope it helps spread the word!
This channel and the quality of topics/content you provide is fantastic. I truly appreciate what you’re doing for the community 👍👍
Glad my channel has been helpful! Really appreciate the comment!
Thank you for the video! One thing I have not seen a good explanation of is tracker mode. The scenarios I would use are tracking individuals in town at an event, tracking kids in a neighborhood, and tracking while camping or hiking. Even if we are on a private channel/encryption key, I worry about flooding the mesh.
Sure thing! Appreciate you being mindful of the mesh! It should probably be fine, just depends on how many people are on the mesh. Meshtastic will still route encrypted traffic even if it's your own key, so your concern there is correct. Since most of your scenarios are at a local level, you likely wouldn't need help from the greater mesh and use your own mesh in these scenarios by either switching the modem preset to LONG_MODERATE or staying on LONG_FAST and changing the frequency slot.
Thaaank you! Will change my “router” in a great but not router-worthy location to “client”. ✌️
Sure thing! Thank you!
Some scenarios not mentioned here. Temporary but high altitude nodes. Ie, Kite flown, or drone based nodes. they can be 400' up, for 10-20 minutes (or a couple hours in a kite or balloon) router/repeater/router_client modes are probably not ideal or appropriate. Maybe client? Or the recent trend in "commercial airplane passenger" nodes.
Thanks for the scenarios!
Glad the algorithm showed me this video. We were just talking about what modes to use in the long fast chat tonight. changing a few of mine to client mute now.
Glad it was helpful!
Great video!!!! This is what I needed to see and hear to make it stick! Thank you!
Sure thing! Glad the video was helpful!
Wow what a good description of how to set the mode of a node. Thank you and keep this kind of content coming!!
Thanks, will do!
Well thank you! Finally a video that explains something useful about meshtastic! Great Work
Great presentation. I'm changing the configuration of my nodes accordingly.
Glad it was helpful!
This is great. Hoping lots of folks see this and take action!
Thanks! Hope so!
A local channel! Thanks for the info. Meshtastic is something I want to get into.
Sure thing! Feel free to reach out anytime with questions here or our Discord. There's a TennMesh channel there.
I wish those of us in Roane had access to a tower way up in the air. Then we could have one "Router" and a few Clients. Unfortunately neither your nor my nodes show on the maps of this video.
@@bartlmay The nodes on this map are just theoretical for the most part
@@The_Comms_Channel I made that comment for Yardsale. On one of the latter maps of the video it showed a Client where I know a Meshtastic user lives. Due to the terrain of this part of Roane County it is difficult to have comms between us. EX: I live at 800' ASL and I have two other Meshtastic users within 5 miles of me but they also live at 800' ASL but on the other side of a ridge that peaks at 1000' ASL.
This was a great explanation, thank you for doing this!
Glad it was helpful! Happy to help!
Can you make a video explaining the possible use to triangle signals in the mesh, for lost and found for example. Thanks for the content
Excellent video! Thank you for your clear and concise educational videos.
Sure thing! Glad it was helpful!
This is it, this is the info I needed, thanks so much for making this!
Sure thing! Glad the video was helpful!
Awesome video, I’d like to see some urban scenarios. I’m in Seattle and would like to put a router on a large building. I also want to place enough clients around to relay, but don’t want to mess up the mesh
Thank you! A new user, this was very useful and appreciated information.
Sure thing! Glad it was useful!
Great video 🙂
Thanks Andy! Appreciate the comment!
Great breakdown! Keep the good info coming.
Will do! Thanks for the comment!
So at a large event, should everyone be set as Client or Client-Mute?
So useful and clear ! Thanks ! 🤝
Sure thing! Glad it was helpful! 🤝
Thank you, very helpful. I learned something new today.
Sure thing! Glad it was helpful!
Question: You initially demonstrated the 'ideal' router scenario, then went on to show an improper config. How does Meshtastic devices 'know' that there is another router taking the hop count(s)? For instance, bounce 3 became bounce 2, but if it already received the data (as previously demonstrated), why wouldn't it re-broadcast as 3 vs. 2 and so on?
Meshtastic uses the signal level to determine which hop is the "furthest". So if the mountain top routers have good signals to each other and then someone who makes their rooftop node a router with maybe a crappy antenna, or the signal has to go through trees, etc. then that node appears to be the furthest and will be the next hop.
Thanks! Great visualization of good node setups.
Sure thing! Thank you so much for the support!
I am very new to this and one of the first setup videos I watched they specifically said to use the router setting. I'm sure there's a lot of bad info going around to us beginners.
Welcome to Meshtastic! I think a lot of the earlier info out there recommended this. Hopefully this video is able to help spread the word.
not sure if that is possible. but maybe meshtastic clients can figure out the best setting by themself. that would be perfect
Neato!
That definitely helps for deployment options
Out of curiosity, are there actual mesh routers in S.TN?
Like Cleveland, Etowah, Ooltewah, etc?
I'm curious because I can see some of those mountains from my house...
The map in the video is theoretical for the most part. I know there are some in that area though. I think Oswald Dome and Athens, ect.
Thank you for the great explanation.
Layer 2 routers actually have tables so they know what to forward, because they are part of that link.
Question - has anyone set up nodes with Yagi antennas? Four nodes with four antenna's on the same roof, Each antenna only RX/TX in one cardinal direction: N,E,S,W The nodes communicate with each other. electrically not using RF since each Yagi is "blind" to the other three not in that Yagi's line of sight.
Sure thing! For the yagi question, yagi will still send some signals out around it, so they would still be in range of each other. In my testing I've had to get at least a half a mile away before loosing signal
Super useful. Thank you!
Sure thing! Thanks!
We don't actually talk about the best way to set them up. It's fun to watch tho!
Great info!
Thanks for watching and appreciate the comment!
In the first scenario; what keeps the the original routers from still receiving and rebroadcasting even with the less-than-ideal-configured ones in the mix?
Great video, thanks! I'm just still confused with the Router, Router_Client and Repeater modes. What would be ideal scenario for each one?
Sure thing! Thanks for watching! The only time these should be used is at the highest point in a location. Generally, this means on mountain tops or if you're in a flat area, a tall tower or building. ROUTER_CLIENT is going away due to this issue being so prevalent. ROUTER and REPEATER are the same for the most part. Except REPEATER won't show up as a node on the list.
@@The_Comms_Channel Great, thanks for clarifying it! 👍👍
Sure thing!
This is an excellent overview, thanks! What mapping software are you using here?
Sure thing! Thanks for watching and commenting!
@@The_Comms_Channelwhat mapping software are you using?
@@TouYubeTom I can recognize he is using Openstreetmap, but do not know which program. But many programs can use those maps.
umap.openstreetmap.de/en/
Being in client_mute seems antithetical to the decentralised mesh ideal, and I think that may be a stumbling block for a number of people. As a noob I know it feels uncomfortable, I don't want to be seen as a leecher, but I begrudgingly accept that I'm more helpful by shutting up, haha
Seems to me it's something that sh/could be handled automatically.
Have you heard about the FCC's latest proposal for rulemaking WT Docket No. 24-240 to take a portion of the 900 MHz band away from amateur radio operators? This would affect Meshtastic users. RUclips user K0LWC has a great video explaining it.
I have heard about that. Hopefully doesn't go through. Hate seeing us lose bands or portions of them.
How about a video on how your areas meshtastic network performed during and after Helene? What were the lessons learned? 73 de AF5OI
Was the fact that you had drone footage in Ramsay a concidence? We have a group here wanting to set up a mesh. If you know more than I do about the area, I would like to meet with you.
Just a coincidence I'm afraid. I just used stock footage of a water tower for that part of the video. Looks like a beautiful area! Where is Ramsay?
Nice tips and all very useful video
Can you revisit how to admin a node through admin channel? I think they added a safer way to do it but I can't find many information about how to set it up. Thank you
Thanks! Will look into doing that!
One of my V3s is probably in that list, it’s stuck in a boot loop on router and I don’t have keys small enough right now to pull the power 🙃
I can check, haha. What's the name?
Disaster Scenarios ?
there are some places that were completely cut off, And Meshtastic not needing a Ham maybe good for general people (client_mute mode) ??
Scenarios:
> Already established Meshtastic network for Disaster.
> Rapid Deployment Scenarios.
> Temporary high altitude nodes.
anyways my main takeaway is that
"Client" = "Client localized repeater"
"Client_Mute" = "Client End-user"
So would you want to be on Client mute if you're going to be around other nodes like at a festival, or keep it default as client? Thanks.
If it's a festival with 100+ nodes, then the last example in the video is best (SHORT_FAST and CLIENT) If it's less than that, then MEDIUM_FAST and CLIENT should be fine. Since these scenarios are away from the main mesh, CLIENT is fine.
Damn you live in the most beautiful part of the US. Congrats!!!
Sure do! Absolutely love it here!
For vehicles does it make more sense to call them “tracker” role?
Thanks for the comment and question! There is a tracker role that wasn't discussed in the video in order to focus on the more common ones. The tracker role is very GPS tracking focused and broadcasts GPS positions as a priority so it's not the best fit for a mobile node intended for communicating.
I am curious how the TAK role plays into this. Does it operate more like a Client or Client-mute if anything at all?
It reduces routine broadcasts so it is sort of an in between of CLIENT and CLIENT _MUTE I would say. Not much info in the docs other than that
@The_Comms_Channel Thank you. I kind of guessed that it would be similar to a Client_Mute since ATAK would need as much bandwidth as possible, but I didn't know if there was testing/data on it.
Sure thing! Not done any testing myself so just going off of what the docs say.
Lol Stillwater? Was that a random clip selection? I see a few nodes there
Yeah it was just a video clip I used. Not mine. There was another comment from someone else in the area as well lol
Need plug-n-play compatibility with ATAK CIV, portable, solar rechargeaable. Currently meshtastic a little cumbersome and confusing for average consumer. Something built to power on and connect to ATAK meshtastic plugin without configuring anything other than network name/login, would greatly imporove the reach and use of this technology
I'm new to matchstick but if I remember right they change the protocol to try to send packets to the farthest nodes you have a good signal to to try to keep wasted hops down to a minimum. And I could be wrong on this but is it recommended to increase your hops allowed to the maximum of 7 if you're trying to go a long distance add densely populated mesh Network?
It's not recommended to increase to 7 hops. 3 or 4 is recommended. Only increase if absolutely necessary. High hop counts are another issue, but I didn't discuss in the video.
Meshtastic uses the signal level to determine which nodes are the furthest for the next hop. If someone has a node at their house set as a router, it's likely going to have a lower signal level than the node on top of the mountain and look further so the next hop will be that home router node instead of the next router on the mountain.
@@The_Comms_Channel it would be nice if they put an option in the menu to hop to nodes that have the highest GPS elevation 2 combat the house router
That's a good idea.
@@The_Comms_Channel I have a good idea every now and then currently there are no nodes in my area of Middle Tennessee so I will be putting up a couple thanks for the difference between client and repeater
Could you do a video on how to get the python CLI setup in Linux or in a Linux VM? My python CLI on powershell crashes the node and doesn’t work.
While this is a video for the BBS, you could follow the same process up until 4:14 in the video to install it
ruclips.net/video/4LuVoDQY-Kc/видео.htmlsi=2apubUq7NPqLmPQU
Does it make sense to change the default role to client_mute? I assume most users set the locale and leave the defaults.
I think that would be best in my opinion, but I can see the other side of that where it wouldn't be a mesh and the user's may not know to change it to meet their situations.
Scenario: I'm setting up the first node in an area. Can't find anything else around in range. What role should it be?
Will depend on the area - 5:36 is one example and 5:56 is another
Would it make sense/be possible that if a user selects the router role, that the hop count isnt counted? I could see this over loading certain devices if the router role is selected, but maybe a pop up warning could be shown if selected.
Edit: Thinking about it more, i suppose this might cause an infinite loop if routers keep picking up the message. Does each message have a unique ID? The router could not rebroadcast tha ID more than say 2 times if so.
That would create another issue I didn't really discuss in the video of too many hops creating congestion.
so can the node and routers or whatever you call them be found? or is this a complete anon way of communicating?
They are encrypted, so it is anon in that sense. Since they are radios, it is potentially possible to locate them via their signals and direction finding. I suspect they are harder to find than normal radios though. We'll be testing this out in a future video
@The_Comms_Channel thanks for responding. I'm interested in off grid free forms of communication I came across mesh networks a year ago and have been doing research on it. Modern tech is to big brother and unreliable at times I want a way to send text within a few miles without 3g 4g ect. Any direction you can point me in to get started as far as devices. I have a few pc's plus sdr radio receivers ham radios ect and other things so I'm pretty good with tech and setting up things. thanks again.
@@brittanycunningham787 Sure thing! Meshtastic or a ham radio with APRS should fit the bill! Meshtastic is the best if you need encryption
There's a number of good options out now that don't require you to build it yourself. I've done some reviews on them and linked them below if you're interested in learning more
ruclips.net/video/YPguv_C6LOY/видео.html
ruclips.net/video/F1b7BYhhMTM/видео.html
ruclips.net/video/Y7V54jMnmOg/видео.html
Also just reviewed an inexpensive ham radio with APRS
ruclips.net/video/4mQucwO8FJU/видео.html
Is there a location where one could search for meshes on-line?
This is a good site but even if an area appears empty on this map, there could be something there that isn't reporting its location
meshtastic.liamcottle.net/
isnt meshtastic calculate the smallest route anyway? so if you have 50nodes between A and B the packets will only use the nodes that are most efficent and low count to reach the final destination.
It uses the signal level to calculate the furthest node. So if you have direct line of sight from mountain top router to mountain top router with good signal and a user sets up a router with a crappy antenna or a signal that has to go through trees, etc. it's going to have a lower signal level and appear to be the furthest node when it really isn't.
@@The_Comms_Channel but i think it does like a traceroute to see what node the packets need to go thru to reach the destination. so if there are more or less stations in between it doesnt matter since it will adapt itself anyway.
it is the dynamic part of the mesh.
Unfortunately not
So its limited to 4 hops??
@@crowbrocaw you can change the amount of hops (7 max) but it's not recommended to do more than 4. High hop counts also create another issue I didn't discuss in this video - congestion
Nodes in shown examples are not named, so its hard to talk about them. But lets try anyway.
At 3:56 you have scenario with added redundant routers. Since 4 is heard by 3 and 2 at the same time, i would assume that 2 would not use TTL decreased by node 3, and in fact both of 3 and 2 would retransmit the packet with TTL of 3. Same situation for next hop between 2-0. With this i do not think that hop count is a problem here. What could be instead is what you mention at the end - ch and/or air util.
Proposal at 5:11 places the local central node as a client instead of router, which means that it sometimes will see a packet from remote place but wont retransmit. That would mean creating a local pocket of mute clients with very unreliable communication.
Please do correct me if my understanding of situation is not correct.
My understanding is that Meshtastic uses the signal level to determine how far a node is and will use that one as the next hop. Since the mountain top nodes are in elevated positions with direct line of sight, they will have a stronger signal than a node on someone's roof that has to go through trees or maybe doesn't have as good of an antenna. Even though these are closer, since these will have a weaker signal, they'll appear to be farther away and it will try to use that one for the next hop.
The example at 5:11 100% does not need to be a router. Client will be perfectly fine in this situation. Best rule of thumb is if there are Routers in the area on tops of mountains or tall towers, there is no need for additional.
Main problem is congestion. routers / nonmuted clients are more chatty, generating unnecessary / redundant traffic. less traffic is better ➡ less chatty nodes are better. this is radio system. radio spectrum does have limited "real estate", every timeslot matters.
☝️
Network routing is hard. Mesh routing is even harder. Can we show some hard evidence what in fact is better? Hard rules, maybe multiple simulation tests?
I can’t reach the nodes in my area on medium fast and they are all switching to MF from long fast because they say the next software will myMF the default
I could reach them on long fast
I don't believe that is true about the next version being MF. What area?
@@The_Comms_Channel Oregon
several people in the discord group have said v3 will be mf default like it’s a sure thing
I can't find anyone saying that there. Also, there is no mention of that in their goals board github.com/orgs/meshtastic/projects/20
There's also a goal to update LONG_MODERATE to be further away from LONG_FAST to reduce collisions
Mqtt just jams everything up
💯💯💯
Having more that 10% of the project documented would help these issues.
People don't read the docs and are why my videos exist 🙂
I wish someone would sell the devices. That would be great.
There's a link with Meshtastic equipment in the video description
First comment, yes.
🥇
The problem is that Meshtastic doesn't understand its own architecture. It should use the layout of the nodes in the area to dynamically determine how to route.
That's hard to do with a user deployed system with no coordination. It has no way of knowing the layout.
@@The_Comms_Channel Yes, it's a proper challenge. But I think it's something the Meshtastic guys need to build into the protocol. Communicating the GPS locations of nodes and signal strengths would allow building optimised routing. The users might just perhaps want to configure whether they prioritise distance or bandwidth between certain nodes.
Fair points and ideas 👍
@@ChristieNel Sounds like a good idea.
Every node shares what they see to the mesh -> GPS info and signal strenghts.
Based on that, the mesh as a whole could build a rudimentary map of whats out there.
This way every node has an rough idea of node locations and how best best route packets.
Not sure how complicated this would be, but I'd assume if you'd let the "map info" slowly propagate thought out the mesh, it could work and not just cause massive congestion.
@@samik83 Something along those lines is what I'm thinking. The challenge is to do it in a decentralised fashion. You don't want one node to do all the deciding, or one naughty/bad node can blow up the whole network. And different versions of nodes can also cause chaos.
Best might be to design the routing such that each node makes its own decisions and the deciding algorithm is such that this optimises the overall network. So it comes back to nodes specifying a path rather than just the next hop.
Great series, looking forward to additional information. KO4GVH
Really well done. 🫡
Thank you!
To me this is like reinventing the pager with much cooler features like encryption and gps