nodeDB only seem to be updated when the sending device gets a gps location lock

[mc-hamster]

The values of n where ( NodeInfo *n = nodeDB.getNode(mp.from); ) only seem to be updated when the sending device gets a gps location lock (and maybe from a phone, I haven’t looked). Given that, n->user.long_name and n->user.short_name are both blank until the sender gets a location lock. In another round of tests, n->user.long_name and n->user.short_name are both unset for half an hour even after the location is updated in the receiver’s node database. Is this expected behavior? Is there a bug here?

Edit: Sometime between 20 and 60 minutes in (I my terminal ran out of buffer) n->user.long_name and n->user.short_name got populated. Regardless, that’s a long time for a new node to know who else is on the mesh.

[geeksville]

This issue has been mentioned on Meshtastic. There might be relevant details there:

https://meshtastic.discourse.group/t/on-device-api-now-available-feedback-requested/1872/28

[mc-hamster]

This was discovered while working on:

https://github.com/mc-hamster/Meshtastic-device/blob/master/src/plugins/RangeTestPlugin.cpp

[geeksville]

great find! i'll investigate tonight.

[mc-hamster]

I should add ...

The sender was configured to send a packet once every 60 seconds, so it's not as though it didn't have an opportunity to send something over the air.

[geeksville]

hi @mc-hamster
re: name updates being slow
hmm - I'm having a hard time reproducing this if send_owner_interval is the default of 4 and position_broadcast_secs is 60, it should send the owner info every 240 seconds. Is that not happening?

[mc-hamster]

I was working with device defaults. I'll get you better reproduction steps this weekend.

[mc-hamster]

Take a look at the attached CSV.

At timestamp 00:44:04 both sender and receiver were restarted.

From timestamp 00:44:00 -> 01:18:57 the receiver never got the sender's name.

At 1:20:52, the sender restarted and then the name started to show up.

rangetest-26.csv.zip

[mc-hamster]

I'm still seeing this but will retest after 1.2 comes out. Maybe it'll be magically fixed by then.

[sachaw]

@mc-hamster can you please confirm that this is now fixed?

[mc-hamster]

I have not seen this issue in 1.2.

Closing.