Mac commands are those commands. And if present they are part of the macpayload. The macpayload also contains the user data.
That is the general idea.
Macpayload can be in uplink and downlink. Mac commands mostly in the downlinks.
That would be strange as class A nodes do not listen for downlinks before sending an uplink. If you mean you would see a downlink with a Mac command before the node responds to it, you are right. However, Mac command is not equal to MAC payload as explained above,
That’s the most confusing part. On TTN, I never configured the nodes made by my friend (he made nodes for chirpstack server) the gateway is simply receiving pings on the console from his devices, is it because he had configured gateway earlier according to his device? please advise?
For my node I am adding device on TTN application and then taking the keys into my Arduino…
talking about the sequence on mac events
not the total class a behavior
sequence i have observed is or payload and mac
node uplink containing your data payload
lns mac downlink with in the rx1 window seldom in the rx2 window
node mac uplink few min later
could then be a lns mac downlink with in the rx1 window seldom in the rx2 window
node uplink few min later containing your data payload
here how did you configure the gateway
i can actually tell you you put “region”:“AS_923_3”
| ID | LoRaWAN Band ID | Base Frequency | Description |
|---|---|---|---|
AS_923_3 |
AS_923_3 |
915 |
Compatibility frequency plan for Asian countries with common channels in the 916.5-917.0 MHz sub-band |
if i recall correctly i used
| ID | LoRaWAN Band ID | Base Frequency | Description |
|---|---|---|---|
AS_920_923_LBT |
AS_920_923 |
915 |
TTN Community Network frequency plan for Asian countries, using frequencies ≤ 923 MHz with listen-before-talk |
You are so far behind the curve on LoRaWAN I’m not sure it’s possible advise but the short version is that ANY device registered on TTN that is heard by a gateway that is peering with TTN will have the uplinks delivered.
But wait, there’s more. Any LoRaWAN device that transmits in range of a gateway that is received correctly, that is it passes the CRC check, will be sent to the LNS, regardless of who’s device & which network it is on.
So all of these appear in the gateway console.
You may want to read all of: https://www.thethingsnetwork.org/docs/lorawan/
Depends entirely on the firmware in the node.
Hi @Piet_Pillay you mean I should change my gateway’s frequency to Asia 920-923 MHz with LBT? As I checked my gateway frequency is as below i.e. AS_923_3_DT
Don’t you think configuration of my gateway are fine? Since whatever the configuration be it is able to get data from my friend’s nodes… hence if it is able to work with his node then without any changes gateway should connect with mine, isn’t it? Please advise! I have attached the global_conf.json
global_conf.json (3.0 KB)
file downloaded from gateway ttn console as well. I remember I had edited this similar global_conf.json file in my rak gateway, just had changed ttn cloud address to make it work otherwise gateway was not being connected with ttn…
As descartes mentioned above, you see any valid LoRaWAN message in the gateway logs, and the chirpstack nodes do send valid messages and therefore appear in the gateway logs.
So then it can only be that there’s a problem with the node.
I’m wondering if your channel selection process is correct - your channels are defined under the EU868 band? Or what #define did you select?
if i read the description of AS_920_923_LBT i would consider changing to it
it is irrespective if my friends node are received or not it is about how ttn are set up
possibly the lns will listen to any frequency but only tx on certain frequency according to its setup you will need to analyze the lns setup to understand if it is possible or not
There’s no point redacting the gateway EUI & ID, it is of public record, like the IP address of your location and is included in every device’s meta data that is heard by the gateway.
It’s also pointless blocking it out if you then include it in a plain text file …
Hi @Ichthus_College_Info , thank you for your valuable response. I am also thinking in this direction, I am using following #define
#define CFG_as923 1
I did above by making modifications in lmic_project_config.h as suggested in readme of the library.
//#define CFG_eu868 1
//#define CFG_us915 1
//#define CFG_au915 1
#define CFG_as923 1
// #define LMIC_COUNTRY_CODE LMIC_COUNTRY_CODE_JP /* for as923-JP; also define CFG_as923 */
//#define CFG_kr920 1
//#define CFG_in866 1
#define CFG_sx1276_radio 1
//#define LMIC_USE_INTERRUPTS
//#define LMIC_LORAWAN_SPEC_VERSION LMIC_LORAWAN_SPEC_VERSION_1_0_2
//#define LMIC_DEBUG_LEVEL 1
#define DISABLE_BEACONS
#define DISABLE_PING
#define DISABLE_JOIN
to check for frequencies I have entered in the main program, please note the arduino code I have added in the post.
Thank you.
Hi @Piet_Pillay , I agree with you but based on the logic what @Ichthus_College_Info gave, it seems issue is from the node side.
But to be on safe side I can try what you say however it might get complicated since making a new gateway on TTN console with same gateway ID will give a issue so will need to change something in my gateway firmware i guess. I will do what you suggested, but I think, I will prefer to do it when I am almost gonna die solving this 
anyway, thank you so much for your suggestion! Hope I can resolve this soon!
Please take a close look at your setup(). You have given yourself the hint that you defined AS923, and I’ll give you the hint that EU868 is not defined.
you are miss understanding this id it can be anything you choose does not need to equal the eui of the gateway
you have two problems
Then consider older LMIC versions. The gateway is perfectly fine, it’s really the node that’s misbehaving. Hopefully you can get away with an older, slimmer version.
