Does Meshtastic support a full mesh network between all nodes or is it only between nodes designated as routers?
If it’s between all nodes, what is the function of designating one as a router instead?
In terms of performance of router nodes, the overview in the wiki states that the ESP32 has to wake from sleep which results in delays in messages, does this mean the nRF52 is a better candidate for a router node or does that only impact the Bluetooth side of things on the ESP32?
1 Like
From what I’ve read in the docs, any node can act as a relay, the router designation is to allow that specific device to stay active more often and therefore more likely to be available to relay traffic. However I’m sure someone who knows will give you an accurate answer!
There is some pretty good docs on this here: Router Settings | Meshtastic
I did look through the docs but not currently having any device meant I was unaware of some of the terminology, and also no where I could find stated if non-router devices also acted as part of the mesh, or if they were the spokes in a distributed star type topology so if anyone can definitively answer that for me, that would be awesome.
Same with a definitive answer on the 2nd part of my question regarding ESP32 vs nRF52.
I’m currently holding off buying any until I was able to work out what would best suit my needs.
1 Like
Non-router devices do act as part of the mesh a router mode is just set up to be more optimized for a non moving node.
The delay mentioned in the documents is referring to the delay between you sending a message to the ESP32 via bluetooth from a phone as the ESP32 will not be awake to receive it till it wakes from sleep and turns on Bluetooth. As soon as the ESP32 receives a message from the LoRa Radio it will wake it.
The nRF52s are better for power consumption if you don’t need wifi.
Hope that makes sense.
Yes everything is part of the mesh, from what I have read the plan is for the routers eventually to be preferred with the idea that they are positioned well for line of sight compared to a moving bag of water.
The nRF52 based boards seem like they will be much better router nodes once some software bugs are worked out. They have already improved a ton in a couple of months. I have 5 of the 4631 RAK boards on hand that I have been testing a little over a week now and I am pretty confidant they will eventually run continuously on solar, they use hardly any power at all.
I had avoided looking at the RAK boards because the wiki mentioned “fledgling support” so I was comparing between the T-Beam and T-Echo, but the latter is substantially more expensive.
How is the power on a T-Beam if you disable GPS, screen and WiFi so it’s used as a pure repeater?
My intention was to run entirely on solar (With the battery keeping it running overnight) whilst keeping the enclosure (and therefore solar panel) as small as possible.
1 Like
I think the RAK and T-echo are at about the same support spot. The RAK boards are the way to go for solar, they even have a nice enclosure with a built in panel.
There’s several people who have setup solar devices, I’d do a search for that.
Oops. I’ll get round to removing that wording in the next couple of weeks. Been busy with work and uni over the past couple of months, so documentation has taken a back seat…
I have built two t-beam solar devices using a solar management board and 6v 6w panels, they work pretty well and run continuously in the summer so far but in my testing it seems like a much larger panel will be required to power a t-beam vs the RAK board.
What solar management board did you use?
I was looking at the RAK after it was suggested that it’s not ‘fledgling support’, but it’s in so many parts and it starts to add up once you start adding GPS, antennas, display, base, processor.
At this rate I’m probably just going to buy 2 of each and play around with them and see how they go. There’s a number of things I want to do with them, and a router was only one of those.
I also want to have a kid tracker for when we go out hiking (and they go exploring while I’m cooking or setting up a fire), but they are young and I wouldn’t give them a phone to take too, but I’d love to see some sort of smart watch that can pair with one of these modules with very limited options (i.e. a help and emergency button) as well as the ability to ping it to say come back etc.
I used a DFRobot Sunflower solar management board.
If your requirement for your router is continuous operation on solar I would recommend the RAK board for routers and the T-Beam to carry if you just want to use solar to extend the life some T-beams work fine.
I had not considered pairing a smart watch before, interesting thought.
2 Likes
@garth and I have talked a lot about solar power options.
These are also great option for higher voltage solar external power mgmt:
For regulating down to 5V from higher power panels (and relying on the charging circuit of the device), I like these as well:
https://www.digikey.com/en/products/detail/murata-power-solutions-inc/OKI-78SR-5-1-5-W36-C/2259781
Does the RAK allow message storage (I noted that the store and forward plugin mentions ESP devices as a requirement) without the flash module? If so, can the flash module be used to increase the stored messages?
How many messages could be stored in either case?
Also does it support the IoT module to allow the routing function to extend over a cellular connection?
Based on this $25 low power dev board with solar: Rak4630 (now included in regular builds) - #44 by geeksville I dont expect the WiFi module to be compatible with meshtastic
Not the WiFi module, the LTE one: Supply your WisBlock system with LTE capabilities with RAK5860 Module – RAKwireless Store
1 Like
I don’t believe any form of cellular connection supported in the firmware. I suspect that’s a whole big ball of wax in terms of implementation. It would be neat though.
Looks like it is functionally the same AT style interface as the WiFi one.
- Programmable with Quectel AT command set