[Feature Request]: Please Enable More Frequent Device Metrics/Telemetry for Router Role Devices ONLY in Crowded Mesh

[Deuteranomalous1]

Platform

NRF52

Description

The improvements to Metrics/Telemetry broadcasting for busy meshes are great at reducing congestion.

However, it's also created a bit of an issue for busy mountain top Routers. Routers are by definition meant to be located high and clear of obstructions. This means they are very likely to see more than 40 nodes and also see the highest channel utilization in any given mesh.

This has created somewhat of an issue after upgrading my main router to 2.4.x. I am now seeing metrics updated maybe once every few days due to the exceptional viewshed it possesses which overlooks the entirety of the south Salish Sea from Vancouver down to Puget Sound. The channel util at the site was perpetually hovering around 50% based on my last on site visit. This has grown substantially since the unit was installed in March when it was reliably around 20%. Since then I have had a steady decline in frequency of updates corresponding with increase in channel utilization but the metrics were received more than often enough to be useful data. Upon upgrading to 2.4.0 a few weeks ago the updates have almost ceased entirely.

Routers mode devices are also remote and the metrics/telemetry are instrumental in preemptively spotting issues such as under charging and moisture ingress. Having multiple days pass between received telemetry information significantly hampers this ability.

My ask is that the frequency scaling for Metrics/Telemetry on Router mode ONLY nodes be altered in a future release. Perhaps an interval of every X hours regardless of number of online nodes and channel utilization? Perhaps 3 hours? In a low traffic mesh the current scaling could still be observed. Or simply allow the user specified interval to be observed if it is set to a value greater than 60 minutes?

Once again, this request is for Router mode nodes ONLY.

I've attached screenshots from my device and another user to illustrate the infrequency of useful telemetry reception.

Thank you!

[b8b8]

My recommendation a few months ago on Discord was to have ROUTERS send telemetry (including an environmental packet) every 6 hours even when channel utilization is high.

[GUVWAF]

Even at high channel utilization, you can still request the telemetry with the Python CLI command --request-telemetry. This is not (yet) in the phone apps, but technically it can.

Currently ROUTERs only send their telemetry every 12 hours because they are assumed to be a permanent install, either powered or with a good solar set-up. I'm not sure if making an exception for ROUTER would be a good idea, because it would be another incentive for people to use this role while they maybe shouldn't, especially if your mesh is already crowded.

[thebentern]

Actually Routers should already be exempt from this scaling logic, so this might indeed be a bug rather than feature request. I'll have to do some digging, as the code in Default.cpp straightforward, but perhaps it's not picking up the value somehow.

[thebentern]

@Deuteranomalous1 could you post a config dump of one of these routers (without sensitive information)?

[GUVWAF]

Probably it's then just the high channel utilization that's causing it to not send it out:

firmware/src/modules/Telemetry/DeviceTelemetry.cpp

Line 23 in efc27f2

airTime->isTxAllowedChannelUtil(config.device.role != meshtastic_Config_DeviceConfig_Role_SENSOR) &&

[thebentern]

Probably it's then just the high channel utilization that's causing it to not send it out:

firmware/src/modules/Telemetry/DeviceTelemetry.cpp

Line 23 in efc27f2

airTime->isTxAllowedChannelUtil(config.device.role != meshtastic_Config_DeviceConfig_Role_SENSOR) &&

Good point. We might consider adding ROUTER role to that exclusion since it is more important to know if routers are healthy than client nodes on the mesh.

[GUVWAF]

Yeah, I think that's fair. Then it will send it still up to 40% instead of 25% channel utilization.

Just don't document it as a feature for the ROUTER role ;)

[Deuteranomalous1]

@Deuteranomalous1 could you post a config dump of one of these routers (without sensitive information)?

Sorry its a 5-6 hour round trip hike this time of year but I can get it for you next trip if you still need it but it seems like its well in hand :)

Thanks guys!

[ashleycawley]

Actually Routers should already be exempt from this scaling logic, so this might indeed be a bug rather than feature request. I'll have to do some digging, as the code in Default.cpp straightforward, but perhaps it's not picking up the value somehow.

What ever came of this? In our area we are seeing issues with Routers not reporting their Device Metrics / battery levels for numerous days (if your lucky).

Through some prior discussions on Discord I think I determined that the Router role should be broadcasting out this information once every 12 hours, however what I've read here makes me think this will only occur if its under a certain Channel Util % threshold. I've tried to find where that threshold is set in the code base but I'm not confident with reading this language.

Could someone confirm if the above assumption is correct and if so what the current % threshold is set to?

Also, if the Router role is set to broadcast so infrequently (12hrs) would it not make more sense to bypass Channel Util checks? One packet every 12 hours isn't going to exacerbate or cause congestion issues.

[GUVWAF]

Routers are now considered "impolite", meaning they will send their DeviceTelemetry up until 40% channel utilization instead of 25%:

firmware/src/modules/Telemetry/DeviceTelemetry.cpp

Line 22 in 9afadde

IS_ONE_OF(config.device.role, meshtastic_Config_DeviceConfig_Role_SENSOR, meshtastic_Config_DeviceConfig_Role_ROUTER);

You can also request DeviceTelemetry using the Python CLI --request-telemetry command, which would still work even at high channel utilization.

[ashleycawley]

Yes I am aware that there is a manual work-around method using the CLI as you covered that in this convo back August, thank you for mentioning that back then as it was useful to me in a pinch. 👍

However, the vast majority of users will interact with their nodes and do quick health-checks via mobile Apps and that alternative method does not help those majority of users there.

... they will send their DeviceTelemetry up until 40% channel utilization instead of 25%:

Two points from this I guess:

1. Are you able to point me to the file / line number where that % is specified? I'm convinced we're seeing it blocked at values <40% (perhaps in the 25-40% bracket).
2. What is the rationale behind preventing the broadcast of one very useful packet which is dispatched very infrequently (12hrs)?

[GUVWAF]

1. It's here:

   firmware/src/airtime.h

   Line 70 in 2c65445

   uint8_t max_channel_util_percent = 40;

2. If your mesh is really above 40% channel utilization, then it will already be very unreliable. The reason you might miss the packets now might be simply because of collisions due to the congestion. Also, the 12 hour interval is just the default, you can set another interval as long as it's not less than the minimum (30 min.).

[ashleycawley]

1. Thank you!
2. As I've tried to emphasise I don't think our channel util is above 40%, I think its below that. Our small mesh in my vicinity is very reliable, we don't have congestion, we live a very rural area with no major cities nearby. We have a small budding mesh building in our area but 8-14hrs can easily go by with not a single user generated message on the primary/public channel, just to give you a sense for how quiet / busy it is. Device Metrics are reliably gathered from other Client nodes in the local mesh.

the 12 hour interval is just the default, you can set another interval as long as it's not less than the minimum (30 min.).

This is one of the first things we tried and had no joy with, it seemingly made no difference. Is that setting adhered to the same when a device is using the Router role?

If the remedy was that easy to change that setting then why was that not proposed to the original author on this issue? My prior testing suggested it was having no effect when changed, which is what led me to going down this path of finding other hidden attributes discussed in here (channel util %) which can get in the way and block this.

If the device metric broadcast for Routers was permitted once every 12 hours irrespective of channel util % then this would all be a mute point and people would be able to easily get the data they need. I'm struggling to see the rationale behind that limitation.

[GUVWAF]

Is that setting adhered to the same when a device is using the Router role?

I believe so, I can't find in the code where it wouldn't respect this for routers.

If the remedy was that easy to change that setting then why was that not proposed to the original author on this issue?

The original issue was specifically about the high channel utilization. Back then it was still 25% and the interval is scaled with the number of online nodes. Now, for routers it's 40% and not scaled with the number of online nodes.

If the device metric broadcast for Routers was permitted once every 12 hours irrespective of channel util % then this would all be a mute point

So why would relaxing this constraint help for you if your channel utilization is very low?

[ashleycawley]

So why would relaxing this constraint help for you if your channel utilization is very low?

Because the broadcast for the Router role has been demoted to be very infrequent (12hrs) and I think sometimes our channel utilization may range around 20-35%. And as I've been trying to state from testing I think lower than 40% thresholds have still been imposing a block potentially.

I have LoS to a Router 1 mile away which I can communicate with flawlessly, remote admin etc. but I can go many days with no Device Metrics being retrieved. I can on-demand, manually use the CLI on my PC just to retrieve them reliably, so the link is good.

My understanding of channel utilisation from a official Meshtastic video led me to believe that non-Meshtastic traffic on the band (other LoRaWAN / Helium traffic) can also contribute to the channel utilisation figure, so I believe that some of what we're seeing locally is not Meshtastic traffic but other stuff on the air and due to Meshtastic's code logic choices its blocking informational broadcasts in a very quiet Meshtastic zone.

[GUVWAF]

I can go many days with no Device Metrics being retrieved.

Are you always connected with an app to a Meshtastic device? A node can only store around 30 packets of all types, and text messages get priority when the buffer is full.

My understanding of channel utilisation from a official Meshtastic video led me to believe that non-Meshtastic traffic on the band (other LoRaWAN / Helium traffic) can also contribute to the channel utilisation figure

This is highly unlikely if not impossible. They have to be using the exact same frequency and LoRa settings, as well as our custom sync word.

[ashleycawley]

Are you always connected with an app to a Meshtastic device?

Yes I have tried leaving it connected for days.

This is highly unlikely if not impossible.

Does that mean there is a mistake in the first 35 seconds of this official Meshtastic video: https://www.youtube.com/watch?v=aDud_5Bxtvc or perhaps I have misinterpreted the opening statements?

[ashleycawley]

Just to reiterate - I can at any point change this node from Router to Client and start getting Device Metrics reliably every hour, as soon as its switched back to Router it stops, no updates every 12hrs, even if you're patient and wait 48-72hrs.

[GUVWAF]

Does that mean there is a mistake in the first 35 seconds of this official Meshtastic video

Yes, while it's theoretically possible, I don't think there is currently any other system that uses the exact same LoRa settings and sync word as we do.

I can at any point change this node from Router to Client and start getting Device Metrics reliably every hour, as soon as its switched back to Router it stops, no updates every 12hrs, even if you're patient and wait 48-72hrs.

Strange, I don't see how this can occur. Can you try setting it to 30 min.?

[b8b8]

i have a router running firmware from the last month (cant remember which one exactly) and have it set to telemetry every 30min. In my busy mesh i normally end up getting telemetry every 1hr approx. Just set to to 30min (1800) and it will work as expected. The defaults have changed, but the minimum for us (you) that know what we're doing it still very good.

[Deuteranomalous1]

i have a router running firmware from the last month (cant remember which one exactly) and have it set to telemetry every 30min. In my busy mesh i normally end up getting telemetry every 1hr approx. Just set to to 30min (1800) and it will work as expected. The defaults have changed, but the minimum for us (you) that know what we're doing it still very good.

Agreed this is what I ended up doing as well.

FWIW requesting telemetry over CLI does not provide the whole picture. Just the basic telemetry built in to the node. At least not for me:

PS C:\Users\user> py -m meshtastic --request-telemetry --dest '!6e2718a'
Connected to radio
Sending device_metrics telemetry request to !6e2718a on channelIndex:0 (this could take a while)
Telemetry received:
Battery level: 91.00%
Voltage: 4.07 V
Total channel utilization: 12.09%
Transmit air utilization: 2.93%
Uptime: 710430 s

This node is equipped with an INA219 for voltage/current and a RAK 1901 for Temp/Humidity. The telemetry for those items sends just fine with the regular interval updates but apparently can not be requested over CLI.

Not complaining, just seems worth noting in case someone looks this up later.

[GUVWAF]

The telemetry for those items sends just fine with the regular interval updates but apparently can not be requested over CLI.

I believe you can if you update the CLI and use --request-telemetry power or --request-telemetry environment.

[Deuteranomalous1]

The telemetry for those items sends just fine with the regular interval updates but apparently can not be requested over CLI.

I believe you can if you update the CLI and use --request-telemetry power or --request-telemetry environment.

Hot diggidy thank you sir! Worked like a charm.

[ashleycawley]

OK, thanks for confirming that video had some false-statements.

Strange, I don't see how this can occur. Can you try setting it to 30 min.?

Certainly, I'd be happy to try new suggestions. I have tried this in the past but happy to try again, just for clarity as I know Android / iOS lay things out differently, on my iOS App I'm going to:
Settings > Module Configuration > Telemetry (Sensors) > Update Interval > Device Metrics > Thirty Minutes
If that is the wrong place then let me know.

After puttning that setting in place via Remote Admin I confirmed it was successful by querying via the CLI on another device and got back:

device_update_interval: 1800
power_update_interval: 1800

I have also cleared the log on my mobile app for the node so I can monitor what comes in over time.

My belief is that the isImpoliteRole logic block which only exists in DeviceTelemetry.cpp is getting triggered too easily (possibly below 40%) and this is causing issues, if someone more capable than myself who can interpret / understand the code is able to double-check the logic in that code block it would be greatly appreciated.

IIRC the video said the Channel Util was measured every minute, is that correct or false as well? If it is a % being measured over the period specified by the update interval, then a longer period update interval (ie. 12hrs) would gather a higher % over the time? I realise its probably not this last bit.

[GUVWAF]

My belief is that the isImpoliteRole logic block which only exists in DeviceTelemetry.cpp is getting triggered too easily (possibly below 40%) and this is causing issues, if someone more capable than myself who can interpret / understand the code is able to double-check the logic in that code block it would be greatly appreciated.

I double-checked the logic and I don't see anything wrong.

IIRC the video said the Channel Util was measured every minute, is that correct or false as well?

This is correct.

[ashleycawley]

Thank you for confirming those two things @GUVWAF 👍

After switching the Device Metrics to thirty minutes earlier this morning and verifying it via the CLI, so far today I've received just one metric broadcast at 12:00pm. This is to that LoS Router 1 mile away with no hops.

Stats from that one Device Metric were:
Channel Util: 22.04%
Airtime: 1.09%

Manually running meshtastic --request-telemetry --dest '!433ae044' --no-time now at 17:30 just to get another perspective on channel util / airtime later in the day I get:

Telemetry received:
Battery level: 86.00%
Voltage: 4.03 V
Total channel utilization: 27.05%
Transmit air utilization: 6.20%

Are you able to confirm that the logic which changes Router's device metric broadcasts to be every 12 hours does not override and take precedence over the manual configuration of the setting shown in my screenshot above?

If you have any further suggestions on things to try then I'm happy help in testing what I can.

[GUVWAF]

Are you able to confirm that the logic which changes Router's device metric broadcasts to be every 12 hours does not override and take precedence over the manual configuration of the setting shown in my screenshot above?

In DeviceTelemetry it calls getConfiguredOrDefaultMsScaled() with the setting:

firmware/src/modules/Telemetry/DeviceTelemetry.cpp

Lines 25 to 26 in 02a5a91

	Default::getConfiguredOrDefaultMsScaled(moduleConfig.telemetry.device_update_interval,
	default_telemetry_broadcast_interval_secs, numOnlineNodes))) &&

And this eventually uses the configured interval if you have set it:

firmware/src/mesh/Default.cpp

Lines 7 to 8 in 02a5a91

	if (configuredInterval > 0)
	return configuredInterval * 1000;

So, yes, that seems good to me. Also b8b8 confirmed it's working as expected for his router.

If you have any further suggestions on things to try then I'm happy help in testing what I can.

What's the firmware version of your router actually? If it's <2.4.3 the limit would still be at 25% channel utilization, which you seem to exceed sometimes.

[ashleycawley]

1. It's here:

   firmware/src/airtime.h

   Line 70 in 2c65445

   uint8_t max_channel_util_percent = 40;

I've just noticed the line beneath that one you highlighted above is:

firmware/src/airtime.h

Line 71 in 2c65445

uint8_t polite_channel_util_percent = 25;

Doesn't that variable sound more relevant to the whole polite / impolite logic block we have been discussing?
Also as I've mentioned, it feels like through testing Chan Util in between 25-40% has been getting blocked, so when I spotted this line it got me excited. Apologies if its a red herring.

[ashleycawley]

What's the firmware version of your router actually?

2.5.15

[GUVWAF]

Doesn't that variable sound more relevant to the whole polite / impolite logic block we have been discussing?

If it's a router isTxAllowedChannelUtil() is called with false and then it uses max_channel_util_percent:

firmware/src/airtime.cpp

Lines 123 to 125 in 5196ee3

	bool AirTime::isTxAllowedChannelUtil(bool polite)
	{
	uint8_t percentage = (polite ? polite_channel_util_percent : max_channel_util_percent);

[ashleycawley]

OK, so I'm around 28hrs into my Router being set to a Device Metric Interval of every thirty minutes now and this is what I have so far:

Just one metric. When potentially there could have been over 50 which could have come through.

As mentioned if I switch it from router to client they will start coming through more regularly and more successfully. Given the results I'm seeing you can appreciate how I began to think:
a) The device metric interval setting was being ignored when the router role was used.
b) The impolite logic block may have been catching chan util <40% but I appreciate you've checked that.

I'm not the only one seeing this either, I have heard the same from another router operator around 10 miles from me.

Any thoughts on what else I can try or test @GUVWAF ? Thanks for your time and help.

[garthvh]

Router and repeater send metrics every 12 hours.

[ashleycawley]

Router and repeater send metrics every 12 hours.

Yes, I learnt that some time ago, however @GUVWAF gave me the impression recently that the Device Metric Update Interval setting would still over-ride that and take precedence even when the role was Router. Are you saying that's not the case?

[garthvh]

Router and repeater send metrics every 12 hours.

Yes, I learnt that some time ago, however @GUVWAF gave me the impression recently that the Device Metric Update Interval setting would still over-ride that and take precedence even when the role was Router. Are you saying that's not the case?

You have to make a manual request, the broadcast interval is unchanged

[ashleycawley]

You have to make a manual request, the broadcast interval is unchanged

OK, so there we have it then: the Device Metric Update Interval setting (aka telemetry.device_update_interval) has no effect when the role is ROUTER.

We still have the mystery of why some router operators in a very quiet Meshtastic area are not metrics every 12 hours. I'll continue to investigate...

[GUVWAF]

has no effect when the role is ROUTER.

It does, you can still set it as long as it's at least 30 min. @b8b8 confirmed this is working as expected.
To be completely sure, I just lowered the minimum to 30 seconds and hard-coded my channel utilization to 30%. I set my role to ROUTER and it's happily sending DeviceTelemetry every 30 seconds (see logs below).

I think the only way you can debug this is checking the serial logs of your router.

INFO | ??:??:?? 276 [DeviceTelemetry] Send: air_util_tx=0.094194, channel_utilization=30.000000, battery_level=101, voltage=-0.001000, uptime=276
DEBUG | ??:??:?? 276 [DeviceTelemetry] Partially randomized packet id 886124043
DEBUG | ??:??:?? 276 [DeviceTelemetry] updateTelemetry LOCAL
DEBUG | ??:??:?? 276 [DeviceTelemetry] Node status update: 3 online, 3 total
INFO | ??:??:?? 276 [DeviceTelemetry] Send packet to mesh
DEBUG | ??:??:?? 276 [DeviceTelemetry] Update DB node 0xbff18ce4, rx_time=0
DEBUG | ??:??:?? 276 [DeviceTelemetry] handleReceived(LOCAL) (id=0x34d12e0b fr=0xbff18ce4 to=0xffffffff, WantAck=0, HopLim=3 Ch=0x0 Portnum=67 priority=10)
DEBUG | ??:??:?? 276 [DeviceTelemetry] No modules interested in portnum=67, src=LOCAL
DEBUG | ??:??:?? 276 [DeviceTelemetry] Add packet record (id=0x34d12e0b fr=0xbff18ce4 to=0xffffffff, WantAck=0, HopLim=3 Ch=0x0 Portnum=67 priority=10)
DEBUG | ??:??:?? 276 [DeviceTelemetry] Expand short PSK #1
DEBUG | ??:??:?? 276 [DeviceTelemetry] Use AES128 key!
DEBUG | ??:??:?? 276 [DeviceTelemetry] enqueue for send (id=0x34d12e0b fr=0xbff18ce4 to=0xffffffff, WantAck=0, HopLim=3 Ch=0x8 encrypted len=49 hopStart=3 priority=10)
DEBUG | ??:??:?? 276 [DeviceTelemetry] txGood=5,txRelay=1,rxGood=5,rxBad=0
DEBUG | ??:??:?? 276 [DeviceTelemetry] Use channel 0 (hash 0x8)
DEBUG | ??:??:?? 276 [DeviceTelemetry] Expand short PSK #1
DEBUG | ??:??:?? 276 [DeviceTelemetry] Use AES128 key!
DEBUG | ??:??:?? 276 [DeviceTelemetry] decoded message (id=0x34d12e0b fr=0xbff18ce4 to=0xffffffff, WantAck=0, HopLim=3 Ch=0x0 Portnum=67 hopStart=3 priority=10)
DEBUG | ??:??:?? 276 [PowerFSM] Radio wait to sleep, txEmpty=0
DEBUG | ??:??:?? 276 [RadioIf] Started Tx (id=0x34d12e0b fr=0xbff18ce4 to=0xffffffff, WantAck=0, HopLim=3 Ch=0x8 encrypted len=49 hopStart=3 priority=10)
DEBUG | ??:??:?? 276 [RadioIf] Packet TX: 600ms
INFO | ??:??:?? 276 [PowerFSM] setup LORA_DIO1 (GPIO33) with wakeup by external source
INFO | ??:??:?? 276 [PowerFSM] setup RF95_IRQ (GPIO26) with wakeup by gpio interrupt
INFO | ??:??:?? 277 [PowerFSM] Exit light sleep gpio: btn=0
INFO | ??:??:?? 277 [PowerFSM] Exit state: LS
DEBUG | ??:??:?? 277 [PowerFSM] State: NB
DEBUG | ??:??:?? 277 [RadioIf] Completed sending (id=0x34d12e0b fr=0xbff18ce4 to=0xffffffff, WantAck=0, HopLim=3 Ch=0x8 encrypted len=49 hopStart=3 priority=10)
DEBUG | ??:??:?? 280 [RadioIf] Lora RX (id=0x34d12e0b fr=0xbff18ce4 to=0xffffffff, WantAck=0, HopLim=2 Ch=0x8 encrypted len=49 rxSNR=10.25 rxRSSI=-65 hopStart=3)
DEBUG | ??:??:?? 280 [RadioIf] Packet RX: 600ms
DEBUG | ??:??:?? 280 [Router] Rx someone rebroadcasting for us (id=0x34d12e0b fr=0xbff18ce4 to=0xffffffff, WantAck=0, HopLim=2 Ch=0x8 encrypted len=49 rxSNR=10.25 rxRSSI=-65 hopStart=3)
DEBUG | ??:??:?? 280 [Router] Didn't find pending packet
DEBUG | ??:??:?? 280 [Router] Found existing packet record for fr=0xbff18ce4,to=0xffffffff,id=0x34d12e0b
DEBUG | ??:??:?? 280 [Router] Add packet record (id=0x34d12e0b fr=0xbff18ce4 to=0xffffffff, WantAck=0, HopLim=2 Ch=0x8 encrypted len=49 rxSNR=10.25 rxRSSI=-65 hopStart=3)
DEBUG | ??:??:?? 280 [Router] Ignore dupe incoming msg (id=0x34d12e0b fr=0xbff18ce4 to=0xffffffff, WantAck=0, HopLim=2 Ch=0x8 encrypted len=49 rxSNR=10.25 rxRSSI=-65 hopStart=3)
DEBUG | ??:??:?? 280 [Router] Incoming msg was filtered from 0xbff18ce4
WARN | ??:??:?? 281 [Position] Ch. util >25%. Skip send
WARN | ??:??:?? 286 [Position] Ch. util >25%. Skip send
INFO | ??:??:?? 287 [PowerFSM] lsEnter begin, ls_secs=86400
INFO | ??:??:?? 287 [PowerFSM] setup LORA_DIO1 (GPIO33) with wakeup by external source
INFO | ??:??:?? 287 [PowerFSM] setup RF95_IRQ (GPIO26) with wakeup by gpio interrupt
INFO | ??:??:?? 317 [PowerFSM] Exit light sleep cause: 4
INFO | ??:??:?? 317 [PowerFSM] setup LORA_DIO1 (GPIO33) with wakeup by external source
INFO | ??:??:?? 317 [PowerFSM] setup RF95_IRQ (GPIO26) with wakeup by gpio interrupt
INFO | ??:??:?? 317 [PowerFSM] Exit light sleep cause: 4
DEBUG | ??:??:?? 317 [Power] Battery: usbPower=1, isCharging=0, batMv=-1, batPct=0
WARN | ??:??:?? 317 [Position] Ch. util >25%. Skip send
WARN | ??:??:?? 317 [GPS] 1 new GPS checksum failures, for a total of 1
INFO | ??:??:?? 317 [PowerFSM] setup LORA_DIO1 (GPIO33) with wakeup by external source
INFO | ??:??:?? 317 [PowerFSM] setup RF95_IRQ (GPIO26) with wakeup by gpio interrupt
INFO | ??:??:?? 347 [PowerFSM] Exit light sleep cause: 4
INFO | ??:??:?? 347 [PowerFSM] setup LORA_DIO1 (GPIO33) with wakeup by external source
INFO | ??:??:?? 347 [PowerFSM] setup RF95_IRQ (GPIO26) with wakeup by gpio interrupt
INFO | ??:??:?? 348 [PowerFSM] Exit light sleep cause: 4
DEBUG | ??:??:?? 348 [Power] Battery: usbPower=1, isCharging=0, batMv=-1, batPct=0
WARN | ??:??:?? 348 [Position] Ch. util >25%. Skip send
INFO | ??:??:?? 348 [DeviceTelemetry] Send: air_util_tx=0.110861, channel_utilization=30.000000, battery_level=101, voltage=-0.001000, uptime=348
DEBUG | ??:??:?? 348 [DeviceTelemetry] Partially randomized packet id 2507858444
DEBUG | ??:??:?? 348 [DeviceTelemetry] updateTelemetry LOCAL
DEBUG | ??:??:?? 348 [DeviceTelemetry] Node status update: 3 online, 3 total
INFO | ??:??:?? 348 [DeviceTelemetry] Send packet to mesh
DEBUG | ??:??:?? 348 [DeviceTelemetry] Update DB node 0xbff18ce4, rx_time=0
DEBUG | ??:??:?? 348 [DeviceTelemetry] handleReceived(LOCAL) (id=0x957ae20c fr=0xbff18ce4 to=0xffffffff, WantAck=0, HopLim=3 Ch=0x0 Portnum=67 priority=10)
DEBUG | ??:??:?? 348 [DeviceTelemetry] No modules interested in portnum=67, src=LOCAL
DEBUG | ??:??:?? 348 [DeviceTelemetry] Add packet record (id=0x957ae20c fr=0xbff18ce4 to=0xffffffff, WantAck=0, HopLim=3 Ch=0x0 Portnum=67 priority=10)
DEBUG | ??:??:?? 348 [DeviceTelemetry] Expand short PSK #1
DEBUG | ??:??:?? 348 [DeviceTelemetry] Use AES128 key!
DEBUG | ??:??:?? 348 [DeviceTelemetry] enqueue for send (id=0x957ae20c fr=0xbff18ce4 to=0xffffffff, WantAck=0, HopLim=3 Ch=0x8 encrypted len=49 hopStart=3 priority=10)
DEBUG | ??:??:?? 348 [DeviceTelemetry] txGood=6,txRelay=1,rxGood=6,rxBad=0
DEBUG | ??:??:?? 348 [DeviceTelemetry] Use channel 0 (hash 0x8)
DEBUG | ??:??:?? 348 [DeviceTelemetry] Expand short PSK #1
DEBUG | ??:??:?? 348 [DeviceTelemetry] Use AES128 key!
DEBUG | ??:??:?? 348 [DeviceTelemetry] decoded message (id=0x957ae20c fr=0xbff18ce4 to=0xffffffff, WantAck=0, HopLim=3 Ch=0x0 Portnum=67 hopStart=3 priority=10)
DEBUG | ??:??:?? 348 [PowerFSM] Radio wait to sleep, txEmpty=0
DEBUG | ??:??:?? 348 [RadioIf] Started Tx (id=0x957ae20c fr=0xbff18ce4 to=0xffffffff, WantAck=0, HopLim=3 Ch=0x8 encrypted len=49 hopStart=3 priority=10)
DEBUG | ??:??:?? 348 [RadioIf] Packet TX: 600ms
INFO | ??:??:?? 348 [PowerFSM] setup LORA_DIO1 (GPIO33) with wakeup by external source
INFO | ??:??:?? 348 [PowerFSM] setup RF95_IRQ (GPIO26) with wakeup by gpio interrupt
INFO | ??:??:?? 349 [PowerFSM] Exit light sleep gpio: btn=0
INFO | ??:??:?? 349 [PowerFSM] Exit state: LS
DEBUG | ??:??:?? 349 [PowerFSM] State: NB
DEBUG | ??:??:?? 349 [RadioIf] Completed sending (id=0x957ae20c fr=0xbff18ce4 to=0xffffffff, WantAck=0, HopLim=3 Ch=0x8 encrypted len=49 hopStart=3 priority=10)
DEBUG | ??:??:?? 351 [RadioIf] Lora RX (id=0x957ae20c fr=0xbff18ce4 to=0xffffffff, WantAck=0, HopLim=2 Ch=0x8 encrypted len=49 rxSNR=11.5 rxRSSI=-64 hopStart=3)
DEBUG | ??:??:?? 351 [RadioIf] Packet RX: 600ms
DEBUG | ??:??:?? 351 [Router] Rx someone rebroadcasting for us (id=0x957ae20c fr=0xbff18ce4 to=0xffffffff, WantAck=0, HopLim=2 Ch=0x8 encrypted len=49 rxSNR=11.5 rxRSSI=-64 hopStart=3)

[ashleycawley]

@garthvh & @GUVWAF you're both Meshtastic developers and I'm not. I seem to be getting conflicting information (I've had this on Discord too). Could you please confirm one way or the other for clarity on the statement in my last message?

Did I misinterpret @garthvh's contribution?

[GUVWAF]

I already showed you the code and now I proved that it's working as expected for me, and b8b8 confirmed this as well.

Indeed the default is 12 hours, but you can still set it differently so "the broadcast interval is unchanged" is then not true.

[ashleycawley]

I already showed you the code and now I proved that it's working as expected for me, and b8b8 confirmed this as well.

You're assuming you're talking to someone who can interpret the code, which I can't reliably. Also even what I can understand I don't know how it fits into the bigger picture exactly with the rest of the code, so I don't know the nuances like you folks.

Indeed the default is 12 hours, but you can still set it differently so "the broadcast interval is unchanged" is then not true.

I understand the default for router is 12 hours, I don't know how many times I have to say that.

So what do you make of my router + the other router operator in my county who have both set their telemetry.device_update_interval to 1800 but aren't receiving anymore than one or two a day?

The above would suggest it is being limited to once every 12 hours as @garthvh said and possibly encountering chan util issues.

Do you think the Router needs a reboot after changing the setting? Traditionally I've been used to it rebooting itself if it requires it. I'm just trying to think of whatever else could possibly be causing a disparity between what you're seeing versus what we're seeing. We are in the UK on 868MHz if that makes any difference to logic used in the firmware.

[GUVWAF]

You're assuming you're talking to someone who can interpret the code

You were asking for me to confirm the logic. I can of course say "yes, checks out", but then I'd rather also show it. I also tried to reproduce your issue, but I couldn't.

So what do you make of my router + the other router operator in my county who have both set their telemetry.device_update_interval to 1800 but aren't receiving anymore than one or two a day?

I'm sorry, but at this point I don't know why you're having these issues and I think the only way would be to check the serial logs of your router.

Do you think the Router needs a reboot after changing the setting?

No, shouldn't be necessary and since you got the correct setting back when by querying from the CLI, you should be good.

[GUVWAF]

@ashleycawley Ah, finally found something. Your own transmit air utilization is quite high, when you requested it, it was 6.20%. Since you are using a region with 10% duty cycle, it won't transmit DeviceTelemetry above 5% transmit utilization to avoid reaching the point where you cannot send anything at all anymore.

The reason this happens only in ROUTER role, is because then you're rebroadcasting way more packets.

[ashleycawley]

Interesting find! I see, so that's the "Transmit air utilization", there's some logic that says not to transmit device metrics if its above 5%? Nice find. Would that be stated in the same airtime.h file we were talking about previously?

[GUVWAF]

Yes, it's 50% of the duty cycle, so 50% of 10% is 5%:

firmware/src/airtime.h

Line 72 in 4c3a3ca

uint8_t polite_duty_cycle_percent = 50; // half of Duty Cycle allowance is ok for metadata

[ashleycawley]

I think you've found it @GUVWAF - Over the past 2.5 hours I've been requesting and logging data via the CLI from my Router and look at the Airtime Utilization:

Transmit air utilization: 6.58%
Transmit air utilization: 6.79%
Transmit air utilization: 6.83%
Transmit air utilization: 6.78%
Transmit air utilization: 6.41%

All over 5%, meaning the logic in that code-block would prevent Device Metrics from being published.

I've then looked at the other Router owned by someone else 10 miles away and although the device metrics is still vastly lacking in frequency, it transmitted more metrics than my router but all the data has a airtime of 5% or less, not a single one over that mark.