Please enable MAC command linkCheckReq

Is your feature request related to a problem? Please describe. A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]

I am trying to send a MAC linkCheckReq command to the server in order to get the gwmargin and ngws values from the server (see also #823). I have tried calling put_mac_uplink_byte(0x02) prior to scheduleUplink(fPort, payloadBuffer, payloadLength);) but this appears to have no effect.

NOTE: With my Python based Dragino system I see console trace messages for linkCheckReq and I get the gateway margin and count sent back but this doesn't happen with this arduino-lmic code.

The current LMIC_setLinkCheckMode() appears to just cause the server to provide an ACK from which SNR and RSSI can be obtained but not the number of gateways in range.

The gwmargin and ngws are useful to determine how good a connection might be in an urban environment.

Describe the solution you'd like A clear and concise description of what you want to happen.

I'd like to be able to add the linkCheckReq command to my uplinks so that I can report the readings in a log file or on a LCD display

Describe alternatives you've considered A clear and concise description of any alternative solutions or features you've considered.

I can record SNR and RSSI after transactions but the number of gateways is, IMHO, key to understanding if a location has some gateway redundancy.

Additional context Add any other context or screenshots about the feature request here.

None

You can't do mac bytes as a client. That's just not supported because of the strange way that the LMIC handles phy uplinks.
The LMIC currently doesn't implement an API that supports MCMD_LinkCheckReq. The MAC parser checks it because it's a valid downlink, and otherwise it would stop PHY parsing. So even though it should never happen (because it can't be requested), the parser needs a case for it. When I added that cases, I added the TODO, but didn't mention that we need an API to request this.

We would have to add an API LMIC_requestLinkCheck(), and as part of that, we'd have to decide whether that is queued (as LMIC_requestNetworkTime() is) or immediate. We'd further have to decide how to handle downlinks. My inclination would be to make it like LMIC_requestNetworkTime(), complete with callbacks, rather than to add two fixed values that receive the number of gateways -- because otherwise you don't know when they've been updated, if ever. That would result in more code and probably another configuration option so that small systems can get by without it. And it has to get documented, in the .docx file and release notes.

Not an invalid request, but it takes some work and testing.

Thank you for looking at this. Perhaps I clouded this issue with mention of SNR and RSSI - it is the gateway margin (gwmargin) and gateway count (ngws) that I would like access to.

I should have done more testing before raising #823 (guilty as charged) but, at the time, I thought that was all that was needed. That issue and this one are related so, on hindsight, I should really have raised this issue only.

In lmic.c the MCMD_LinkCheckAns response from the server has the required return values commented out. See lines 917..922 in src/lmic/lmic.c as shown next.

case MCMD_LinkCheckAns: {
// ***@***.***) capture these, reliably..
//int gwmargin = opts[oidx+1];
//int ngws = opts[oidx+2];
break;
}

Having exposed those values on my copy of this code and called LMIC_setLinkCheckMode(1) I found no evidence of the server receiving or responding to a linkCheckReq. I.e. was nothing in the TTN console to say it had received a linkCheckReq.

I am using LMIC-node on my Heltec compiled against this library. LMIC-node schedules an uplink once per minute - but I stop it after about 5 transmissions to be sure to avoid fair use infringement.

I tried to add a linkCheckReq uplink MAC command by exposing and calling this method from lmic.c :-

put_mac_uplink_byte(0x02);

immediately prior to scheduling an uplink, but that didn't work either.

I have closed #823 as suggested but would still like to be able to add a linkCheckReq MAC command to an uplink.

I can do this successfully with python on a raspberry Pi but it's a lot of hardware when a battery powered Heltec should suffice.

My aim is to identify suitable places in town to install sensor nodes and so the gateway margin and number of gateways would be a big help.

Regards Brian

On 10/12/2021 16:30:55, Chris Stratton @.***> wrote: The current LMIC_setLinkCheckMode() appears to just cause the server to provide an ACK from which SNR and RSSI can be obtained but not the number of gateways in range. If the server complies with the LoRaWAN spec, it will encode both of these pieces of information in the response. If any response is being generated at all, the issue is not with the request sent by LMiC, but withe either the server, or how LMiC is parsing the response. Concerns with response parsting would make this a redundant duplicate of your existing issue #823 [https://github.com/mcci-catena/arduino-lmic/issues/823] and thus something that should be closed. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub [https://github.com/mcci-catena/arduino-lmic/issues/825#issuecomment-991115560], or unsubscribe [https://github.com/notifications/unsubscribe-auth/ADY5NXM5JM6XTXRXIQTOB4DUQITL5ANCNFSM5JOZCRGQ]. Triage notifications on the go with GitHub Mobile for iOS [https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675] or Android [https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub].

Our emails crossed in the post - LOL

Ok, well, I guess I could obtain the number of gateways in range from TTN mapper instead and just rely on the SNR and RSSI values to indicate viability of a site for a sensor install.

So, that's another way to skin my cat.

If you want to close this request then feel free but as you say LMIC_requestNetworkTime() is very similar and the spec says linkCheckReq should be available.

Regards Brian

On 10/12/2021 18:45:01, Terry Moore @.**> wrote: You can't do mac bytes as a client. That's just not supported because of the strange way that the LMIC handles phy uplinks. * The LMIC currently doesn't implement an API that supports MCMD_LinkCheckReq. The MAC parser checks it because it's a valid downlink, and otherwise it would stop PHY parsing. So even though it should never happen (because it can't be requested), the parser needs a case for it. When I added that cases, I added the TODO, but didn't mention that we need an API to request this. We would have to add an API LMIC_requestLinkCheck(), and as part of that, we'd have to decide whether that is queued (as LMIC_requestNetworkTime() is) or immediate. We'd further have to decide how to handle downlinks. My inclination would be to make it like LMIC_requestNetworkTime(), complete with callbacks, rather than to add two fixed values that receive the number of gateways -- because otherwise you don't know when they've been updated, if ever. That would result in more code and probably another configuration option so that small systems can get by without it. And it has to get documented, in the .docx file and release notes. Not an invalid request, but it takes some work and testing. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub [https://github.com/mcci-catena/arduino-lmic/issues/825#issuecomment-991209706], or unsubscribe [https://github.com/notifications/unsubscribe-auth/ADY5NXNMEU6JP6T7M76UVPTUQJDC3ANCNFSM5JOZCRGQ]. Triage notifications on the go with GitHub Mobile for iOS [https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675] or Android [https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub].

If you want to close this request then feel free but as you say LMIC_requestNetworkTime() is very similar and the spec says linkCheckReq should be available.

I plan to leave it open. Just don't have any time to look at it at the moment. I think that other contributors might be able to look at the code enabled by LMIC_ENABLE_DeviceTimeReq and create a patch using LMIC_ENABLE_LinkCheckReq, and then do a PR. Or at some point I'll try to look at this myself. It's not very hard; I just have other things I have to do the next few days.

Ok, that's fine with me. On 10/12/2021 19:04:42, Terry Moore @.***> wrote: If you want to close this request then feel free but as you say LMIC_requestNetworkTime() is very similar and the spec says linkCheckReq should be available. I plan to leave it open. Just don't have any time to look at it at the moment. I think that other contributors might be able to look at the code enabled by LMIC_ENABLE_DeviceTimeReq and create a patch using LMIC_ENABLE_LinkCheckReq, and then do a PR. Or at some point I'll try to look at this myself. It's not very hard; I just have other things I have to do the next few days. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub [https://github.com/mcci-catena/arduino-lmic/issues/825#issuecomment-991222496], or unsubscribe [https://github.com/notifications/unsubscribe-auth/ADY5NXLL4H3TMILB2DNDL5DUQJFMVANCNFSM5JOZCRGQ]. Triage notifications on the go with GitHub Mobile for iOS [https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675] or Android [https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub].

mcci-catena / arduino-lmic

Please enable MAC command linkCheckReq #825