If one deletes the node database the nodes list gets replenished over time. But the names only are shown quickly first. No further data. Only slowly does the node location and telemetry get shown. Is this due to a random timing of sending of node ID data and random sending time and variable sending interval of other data? Say one has a static fixed node with static fixed location information… Can one set it to synchronise all data and send all info at the same time? i.e. all node ID with location and telemetry etc. (Even if this uses more power… I ask about the principle, not the utility or desirability of synching all data.)
There is no way to ‘transfer’ or sync a node database over the mesh as such.
A devices node database will just populate slowly as packets arrive. The nodes name (long+short) are in one packet. The telemetry and position data arrive separately via the own messages.
In general there is no direct ‘syncing’ between the different type of packets. They all send on their own schedule from each node. (and differnet people have different settings for each!)
The node names often appear sooner, as that gets send out in response to new nodes, not just ‘periodically’.
Telemetry and position can be requested from a remote node, but don’t think there is any automated requests for it.
1 Like
Thanks. If I re-set the database, are the nodes that appear answering or responding by MY NODE appearing to be new to them? What determines how soon a node appears? In my case within seconds I got nodes appearing - but they were the known high up far away ones or other nodes of mine in the house. Why do they appear so fast? Is it due to my having a good direct SEND path to them and they answer my automatic ID sending ? Thanks for your help thus far ! Sorry to dig…
I dont think resetting the nodedb, will specifically request nodeinfo from others.
But, if your device receives a message from a unknown node (ie not in the nodedb), it shoudl then send its own nodeinfo, which includes a request for a reply to find their identiy.
So if a remote node happens to send a message after your reset, they should in general appear quite quickly in your list.
Also it can be that the just happen to send a ‘scheduded’ packet after your reset. Ie they set to send once an hour, and you just happen to reset just before the top of the new hour.
(but as say, they should appear in your list quite quickly after sending anything - so could be their other periodic messages, nodeinfo, postion, telementry, but even neighbour info packets etc)
@adingbatponder I don’t think it’s quite what you’re asking for, but if your node has a user-button, a double-click will tell your radio to send an out-of-band nodeinfo packet. You can only do this, I think, every 5 minutes to prevent spam.
I use this when arriving into a new area, cresting a hill, rounding a bend, etc…if anyone is out there in earshot, I’ll get their node reply pretty quickly. This has the added benefit, where if you then send a message out, all nearby nodes who heard your nodeinfo already know your name, and, presumably, you theirs, so messages should then arrive with fully fleshed out long/short names.
Best,
Pol
1 Like
Thanks. What is the “out-of-band” attribute?Is that a special radio frequency when button pressed, or an attribute of all nodeinfo?
Thats cool. Didn’t know that! Just tried it now and the screen showed ‘send ad-hoc position’, so it might be a position packet rather than nodeinfo. (on heltec v3) But should be similar result. Will prompt others to prompt you to share nodeinfo.
… when ‘wardriving’ I fumble with the phone, and request position from an arbitary node (even one I know not around) just to send out a packet. double press of button much easier!
1 Like
“Out of band” meaning out of the regularly scheduled broadcast rotation. Your radio will periodically send out nodeinfo packets on a schedule. I think it’s usually set to something like an hour, but you may change this under radio configuration → device.
It’s not recommended to set this terribly high, I use 7200 seconds myself, but you don’t need to be sending this out with aggressive frequency, since as soon as your radio receives a packet from a sender not known to it, your radio will send that same nodeinfo in order to exchange IDs.
So the button will just let you fire one of those packets out at your discretion, no more often than 300 seconds. Don’t spam it…but it’s kind of neat to watch your node list in the app, fire off a node-info, and see who comes back NOW…those are your immediately accessible neighbors at that moment in time.
I’m sure the other hardware platforms can support it too, but my only experience is with the Rak units.
Best,
Pol
1 Like
Checked the code, and seems it will tend a position packet if possible, if the device doesn’t have a position will be a nodeinfo. The screen (if present) shows which was sent.
which makes sense.
2 Likes
If it’s helpful, you can also use the user-button to:
- Single Click: Change the page of a screen if installed
- Double Click: Issue an Ad-Hoc ping to the mesh
- Triple Click: Toggle Power Delivery to GPS Radio
- Quad Click: On Nodes with E-Ink screen, force a screen refresh
- Long Click(5+ Seconds): Initiate Super Deep Sleep (Near Shutdown)
- Single Click, While Sleeping: Wake from Super Deep Sleep
It’s a really nice upgrade and I don’t even have screens on my nodes! There is an option in the config to disable the triple click as one may not want to inadvertently shut off their gps.
2 Likes
-
Can I make this button pressing happen using bluetooth? Or only via physical press?
-
I have a button: do you mean that one labelled “reset”? Or a special one one has to add soldered on certain pins as in the images posted above?
- Do all versions of firmwear have this ? (sorry if already answered above…)
It’d require a solder job, but it’s fairly simple…trust me, I’m not good at soldering and I make it work 
You’ll need a momentary switch of some kind, the kind that’s normally open, but closes when pressed. You don’t want a latching switch, just momentary.
Solder up one “leg” of your switch to GRND and the other leg to AIN1 on the baseboard. It’s a lot easier after you’ve done one or two, trust me…just be careful as the printing on the PCB is very small…take a picture, blow it up…the usual…
While you’re in there, and the iron is hot, consider a latching switch between GRND and IO2 if you want to add a GPS defeat switch so you can toggle the GPS off and on physically.
Check this for a more detailed write-up with some pictures:
Keep in mind if you’re adding the user-button, there’s a config change necessary in the Mesthastic app, that’s an easy one to forget! 
Best luck, happy to field questions as they come up!
Pol
Ps: I no longer use wireless charging, it’s not worth it. I just use a surface mounted USB-C input, so I can get both power and serial comms…plus the wireless charging was terribly slow relative to direct USB…and you’ve already got a USB cable out to run your charger…
1 Like
Questions: does a noneinfo packet get automatically forwarded in the mesh just like any other?Does nodeinfo received from ANY node get put up in the app’s list of nodes? But I note that many nodes are listed that have/show no traceroute …
Yes. Forwarded like any other. It may even be encrypted and hence not decodable by intermediate nodes, so they just forward everything.
Yes any NodeInfo packet you receive (and can decode!) should show in your Node List!
… it’s still the identity of the original sender. Forwarding the packet shouldn’t change it (other than decrementing Hop Limit, to prevent forwarding forever.
It’s possible that you receive a node info, but the mesh is not reliable enough for two way communication. NodeInfo Packets only need to get TO you, you don’t need to be able to communicate BACK to the other node.
It can also be that there are typically lots of NodeInfo packets get sent. Only one need to get though.
In a contrived example that only 25% of packets get though. There is fair chance that a node info packet will get though. 1 in 4 of them is enough!
But the traceroute is ‘one shot’ - If just one of the packets fails, the whole traceroute fails. (although there is some reduency if there are multiple paths thought the mesh!)
1 Like
Thanks. Is the node info subject to the max 7 hop rule ?
Same for all packets. 7 is hardcoded in the protocol, as only uses 4 bits.