Join Requests are not be acknowledged

[chipmc]

I am using v2.3.1 of LMIC library and 0.5.2 of this library with MachineQ LoRaWAN service. I can see the Join MAC requests in the serial stream and the MachineQ sending a join accept. Yet, the device never acknowledges this and records EV_JOIN_FAILED after a few minutes. Any suggestions on what I can do to remedy this? Thanks, Chip

[terrillmoore]

@chipmc, sorry for the slow response. The emails get buried and then there's no good dashboard when managing multiple repos. (Probably there's an app for this.)

Anyway, it worked for me last time I tried it. Did you try changing your clock rate accuracy using LMIC_setClockError()? That's the most likely problem, opening the RX windows too late. What platform are you using?

[chipmc]

@terrillmoore , Thank you for responding and completely understand about having to track a number of message sources.

I do have a line in setup for clock error: LMIC_setClockError(MAX_CLOCK_ERROR * 1 / 100);

I am using the Adafruit Feather M0 LORA for this work.

Any other suggestions are greatly appreciated.

Thanks, Chip

[terrillmoore]

Hmm, I tested on a Feather M0 LoRa and it worked for me.

If you're adding a bare Feather M0 LoRa, you must jumper D6 to DIO1. MCCI's wings do this, so if you're using one of our wings, don't worry about this. Otherwise, jumper JP1-1 to JP3-9. (It's bizarre, I thought this was documented everywhere, but apparently not.)

After confirming that, try changing the clock error to 10%: LMIC_setClockError(MAX_CLOCK_ERROR * 10 / 100);.

If still no luck, you can try using MCCI's SAMD board package in the Arduino board selection menu, select the Catena 4410 as the target board. We fixed a number of things related to clock (ms-timer) handling, and it's possible that we inadvertently introduced a requirement to work with our BSP.

[chipmc]

Terry,

Thank you! I had installed the jumper as required but will give your other suggestions a try when I get back home.

Thank you!

-- Chip McClelland 919-624-5562

On February 10, 2019 at 4:02:11 PM, Terry Moore (notifications@github.com) wrote:

Hmm, I tested on a Feather M0 LoRa and it worked for me.

If you're adding a bare Feather M0 LoRa, you must jumper D6 to DIO1. MCCI's wings do this, so if you're using one of our wings, don't worry about this. Otherwise, jumper JP1-1 to JP3-9. (It's bizarre, I thought this was documented everywhere, but apparently not.)

After confirming that, try changing the clock error to 10%: LMIC_setClockError(MAX_CLOCK_ERROR

• 10 / 100);.

If still no luck, you can try using MCCI's SAMD board package in the Arduino board selection menu, select the Catena 4410 as the target board. We fixed a number of things related to clock (ms-timer) handling, and it's possible that we inadvertently introduced a requirement to work with our BSP.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/mcci-catena/arduino-lorawan/issues/74#issuecomment-462171974, or mute the thread https://github.com/notifications/unsubscribe-auth/AF5tbReTq4jhuTLor_OTRrZ7GSVj_ZL_ks5vMIjSgaJpZM4ZkPOg .

[chipmc]

Terry,

Well, I finally got to this item on my queue. First, I tried adjusting the clock error as you suggest (LMIC_setClockError(MAX_CLOCK_ERROR * 1 / 100);). This did enable me to connect but, only after a couple dozen failed attempts. I also tried using your Catena 4410 BSP but, this did not seem to make any difference. Would it be possible for you to share the test sketch you used? Or, could you try my sketch on your device - just trying to isolate the issue. My Github repo is at: https://github.com/chipmc/Simple-Sense-LoRA-Prototype

Thank you in advance for your help.

Chip

[terrillmoore]

I'm running around today, but I'll try to take a look at the code during travel this afternoon.

[terrillmoore]

Very sorry @chipmc, this fell off my list. Is this still a problem?

[chipmc]

Terry,

Yes, and any help would be greatly appreciated.

Thanks, Chip

[terrillmoore]

I just re-noticed that this is for machineQ. My suggestions are as follows.

1. Please update to "current" LMIC and LoRaWAN. There are a number of fixes relative to JOIN that don't affect The Things Network but probably do affect machineQ.

2. Please try running the compliance script from current LMIC (changing credentials to match machineQ). It's very simple, but it's better instrumented. Send logs.

Thanks, --Terry

[chipmc]

Terry,

OK, so I have updated to the latest LMIC (2.3.2), LoRAWAN (0.5.3) and ADK (0.2.0) libraries from MCCI. I can see the join requests coming to the MachineQ LogStream and, each time, I see a "Join Accepted" going back out. However, this accept is never acknowledged by the device which keeps sending Join requests.

So, I have completed your #1 above. I am happy to do #2 as well but, I need a little more direction as a Google search and a review of the LMIC documentation did not, for me, turn up a compliance script or how to run it.

Again, any help appreciated.

Thanks, Chip

[terrillmoore]

Ah, I wasn't clear.... you have to download the latest (post-release) versions of the LMIC and LoRaWAN libraries. For the compliance script, all you need is "current" LMIC -- it will show up as an example named "compliance-otaa-halconfig". Apart from the logging, which is done via a queue and therefore is a bit convoluted, I think it's pretty clear. The logging, however, is what we want, as it will show exactly what is going on during the JOIN-ACCEPT, including timestamps. If you're using git, clone the library and rename it to replace the existing library in ~/arduino/libraries.. definitely don't want the old one anywhere near by. If you have got it via the library manager, they insist on it being called mcci-lorawan-lmic-library; if you installed yourself, it's probably at arduino-lmic. In either case, zip up the old version and delete it, or move it somewhere altogether else (not in the arduino/libraries path). Then put the new version where the old version was (using git clone, unzip, etc.)

[chipmc]

OK, progress. Downloaded post release LMIC and LoRaLAN. Found the compliance script, edited it to add my credentials. But, I am getting a warning on compile and the following message in the serial terminal: "board not known to library; add pinmap or update getconfig_thisboard.cpp"

My board is the: Adafruit Feather M0

I then added the MCCI Catena Board Support Package and this got me past that issue.

Here is what I see in the serial terminal:

Starting Packet queued 313397: EV_JOINING 313485: EV_TXSTART: ch 13 rps=0x4 (SF10 BW125 CR 4/5 Crc IH=0), datarate 0, opmode 88C 633646: EV_RXSTART: freq=926.3 rps=0x94 (SF10 BW500 CR 4/5 NoCrc IH=0), datarate 0, opmode 88C, txend 336695, delta ms 4751 693650: EV_RXSTART: freq=923.3 rps=0x96 (SF12 BW500 CR 4/5 NoCrc IH=0), datarate 0, opmode 88C, txend 336695, delta ms 5711 733654: EV_JOIN_TXCOMPLETE: saveIrqFlags 0x80 794117: EV_TXSTART: ch 65 rps=0x12 (SF8 BW500 CR 4/5 Crc IH=0), datarate 4, opmode 88C 1106334: EV_RXSTART: freq=923.9 rps=0x91 (SF7 BW500 CR 4/5 NoCrc IH=0), datarate 4, opmode 88C, txend 795934, delta ms 4966 1152890: EV_RXSTART: freq=923.3 rps=0x96 (SF12 BW500 CR 4/5 NoCrc IH=0), datarate 4, opmode 88C, txend 795934, delta ms 5711 1192894: EV_JOIN_TXCOMPLETE: saveIrqFlags 0x80 1478728: EV_TXSTART: ch 8 rps=0x4 (SF10 BW125 CR 4/5 Crc IH=0), datarate 0, opmode 88C 1798893: EV_RXSTART: freq=923.3 rps=0x94 (SF10 BW500 CR 4/5 NoCrc IH=0), datarate 0, opmode 88C, txend 1501941, delta ms 4751 1858896: EV_RXSTART: freq=923.3 rps=0x96 (SF12 BW500 CR 4/5 NoCrc IH=0), datarate 0, opmode 88C, txend 1501941, delta ms 5711 1898904: EV_JOIN_TXCOMPLETE: saveIrqFlags 0x80 1922948: EV_TXSTART: ch 65 rps=0x12 (SF8 BW500 CR 4/5 Crc IH=0), datarate 4, opmode 88C 2235165: EV_RXSTART: freq=923.9 rps=0x91 (SF7 BW500 CR 4/5 NoCrc IH=0), datarate 4, opmode 88C, txend 1924765, delta ms 4966 2281721: EV_RXSTART: freq=923.3 rps=0x96 (SF12 BW500 CR 4/5 NoCrc IH=0), datarate 4, opmode 88C, txend 1924765, delta ms 5711 2321795: EV_JOIN_TXCOMPLETE: saveIrqFlags 0x80 3130069: EV_TXSTART: ch 12 rps=0x4 (SF10 BW125 CR 4/5 Crc IH=0), datarate 0, opmode 88C 3450231: EV_RXSTART: freq=925.7 rps=0x94 (SF10 BW500 CR 4/5 NoCrc IH=0), datarate 0, opmode 88C, txend 3153279, delta ms 4751 3510234: EV_RXSTART: freq=923.3 rps=0x96 (SF12 BW500 CR 4/5 NoCrc IH=0), datarate 0, opmode 88C, txend 3153279, delta ms 5711 3550304: EV_JOIN_TXCOMPLETE: saveIrqFlags 0x80 3610194: EV_TXSTART: ch 65 rps=0x12 (SF8 BW500 CR 4/5 Crc IH=0), datarate 4, opmode 88C 3922410: EV_RXSTART: freq=923.9 rps=0x91 (SF7 BW500 CR 4/5 NoCrc IH=0), datarate 4, opmode 88C, txend 3612011, delta ms 4966 3968967: EV_RXSTART: freq=923.3 rps=0x96 (SF12 BW500 CR 4/5 NoCrc IH=0), datarate 4, opmode 88C, txend 3612011, delta ms 5711 4008977: EV_JOIN_TXCOMPLETE: saveIrqFlags 0x80

It does not seem to get past this point. On the MachineQ Logstream, I see the same JoinRequest / JoinAccept endless loop.

Hope this helps and thank you again for your time.

Chip

[paulalting]

Hi Terry and Chip, I am having a similar issue with the arduino-lmic library from Terry, and noticed your posts here Chip being similar to what I am having with that library.

So I thought I would use this library and see what results I get, so I downloaded the latest master of arduino-lorawan and use this with the compliance test as mentioned above.

My setup is Eclipse IDE with the Jantje plugin, Sloeber ver 4.3. Boards platform is Adafruit samd ver 1.2.8

I set the lmic_project_config.h to use au921 as I am in Australia and have my gateway setup for this band. Gateway is RAK831 on RPi running LoraServer OS, that is, packet forwarder and app and network server all in one system, which seems ideal for for testing.

So, when I run up the example code: 'compliance-otaa-halconfig.ino' I get results that appear to match what you are getting Chip. The output from the Feather M0 with onboard LoRa 915MHz appears the same as what you are getting, as well as the live LoRaWAN packets as seen on the gateway/net/app server, simply a endless loop of UpLink JoinRequest followed by DownLink JoinAccept.

Terry, what advice can you suggest ? Is there anything I can provide to assist ?

Edit: If I change both the gateway to US915 band plan and reset the lmic_project_config.h to us US915, the results appear the same both on the output of the Feather and LoRaServer.

Paul

[terrillmoore]

@paulalting: Thanks for the investigations. Can you post the Feather serial log from startup? It should be printing messages on each join attempt. I will try to repro your results with the Adafruit SAMD BSP. I don't have the Eclipse IDE, but I don't suspect that this is the problem.

[terrillmoore]

@chipmc -- "I am getting a warning on compile and the following message in the serial terminal: "board not known to library; add pinmap or update getconfig_thisboard.cpp" indicates a bug in the board autodetect logic. Would you mind filing an issue on that?

[terrillmoore]

@chipmc thanks for the log, I'll review the timestamps later this morning. The question will be "are they correct, or are they perhaps late?"

[paulalting]

I am still not making any progress, having tried any things, both at the gateway and server side as well as in the compliance code. I have tried directing the packet forwarder to another network/application server with no change in what I see.

Below is the printed data from the Feather M0

Starting
Packet queued
548935: EV_JOINING
549023: EV_TXSTART: ch 8 rps=0x4 (SF10 BW125 CR 4/5 Crc IH=0), datarate 2, opmode 88C
881738: EV_RXSTART: freq=923.3 rps=0x94 (SF10 BW500 CR 4/5 NoCrc IH=0), datarate 2, opmode 88C, txend 572243, delta ms 4951
944303: EV_RXSTART: freq=923.3 rps=0x96 (SF12 BW500 CR 4/5 NoCrc IH=0), datarate 2, opmode 88C, txend 572243, delta ms 5952
954115: EV_JOIN_TXCOMPLETE: saveIrqFlags 0x80
999972: EV_TXSTART: ch 65 rps=0x12 (SF8 BW500 CR 4/5 Crc IH=0), datarate 6, opmode 88C
1312190: EV_RXSTART: freq=923.9 rps=0x91 (SF7 BW500 CR 4/5 NoCrc IH=0), datarate 6, opmode 88C, txend 1001791, delta ms 4966
1373850: EV_RXSTART: freq=923.3 rps=0x96 (SF12 BW500 CR 4/5 NoCrc IH=0), datarate 6, opmode 88C, txend 1001791, delta ms 5952
1383664: EV_JOIN_TXCOMPLETE: saveIrqFlags 0x80

Terry, is there any other diagnostic data that we can get that would highlight more exactly where and what the problem is ? Many thanks for your efforts. Paul EDIT: just noticed your posts above after I posted this. No, the Eclipse IDE is great, no problems there at all. I just couldn't use the standard Arduino IDE, it's plain awful, especially with the amount of coding I do.

[terrillmoore]

@paulalting @chipmc

The logs from your gateways at the same time would be helpful (especially the details that show which channel they're transmitting on). The device logs look correct, so the logical possibilities are:

1. the clock is way off on the Feather (so it thinks it's opening the TX window at a given time, but it's really not that time)
2. the connection from DIO1 to D6 is not present
3. there's an extremely unusual RF problem on the boards.

I have multiple devices and so at this point I'd normally use one of the raw sketches (in lmic examples) to get two devices talking to each other -- that makes sure #2 and #3 are not an issue. Do you by any chance have two devices? Meanwhile, I'll think about whether there's a simple diagnostic that would give more info. Have to look at the paths that cause us to exit the receive state.

[paulalting]

Yes, I have two identical setups here as part of a project for measuring subterranean water levels for a local city council. I have had them initially doing exactly as you mentioned. But that was a while ago now and would be beneficial to try that again.

In terms of the clock being off, I have two identical setups here, with Feather M0 boards. Would they both be so far off. Maybe time to get the DSO out and measure the clock frequency ?

Yes, DIO1 is definitely connected to D6, let me meter that to check, yes, it is. I just now took a photo of one of the units: You can see the white USB cable back to my system and the black RG58 going to the antenna. There is another power board there to step up the 3.7Volts to 20Volts for an industrial pressure sensor for measuring the water level in the well.

I would be surprised if it were an RF problem. On the device above a small quarter wave ground plane and a standard antenna on the gateway as supplied with the RAK831. Typical RRSI are around -90dBm into the gateway with the gateway in another room some 10m away. I would suspect if it were RF, then the gateway would not see the join request. But RF can be tricky and as you say, it could be some very unusual situation.

As it is 01h40 here at present, I will look into collecting logs from LoRaServer in the morning. Thanks again Terry for your speedy response, much appreciated.

[terrillmoore]

Yes, I don't see an antenna on the device. Gateways are much more sensitive than devices. At -90 dB into the gateway, receive will be quite hit-or-miss.

I have been very successful with an 82mm wire on the Feather -- 17 miles at SF7 (line of sight). I wouldn't do anything more fancy than that.

[paulalting]

The quarter wave ground plane is essentially the 80mm vertical with four ground radials bet down at 45°. I built this for better performance for the particular project.

My understanding is that -90dBm is quite good actually. If it were further down than -125dBm then I would do something to improve the signal. Would that be your experience ?

Question, I have power down the gateway and removed all power from it, would you still continue to receive the same data from the Feather ? I am, and have reset the feather and it still streams the same data as above. My location is way out in the forest on the side of a mountain, and I don't expect there would be another gateway so nearby. Maybe I will try a dummy load in the morning to check.

[terrillmoore]

The feather will spew identically whether there's a gateway in range or not -- if it's not receiving. The logs show that it's not receiving.

With an antenna, you'd see -40 to -30 dB at the gateway. I've not carefully characterized, but I helped someone who clearly had an antenna problem; they' were getting join requests but no downlink, and the RSSI was comparable.

Gateways are much more sensitive; but in fact, on my gateways, -120 dB is the floor; I've never seen working -125 dB. The devices are not as sensitive (they're cheaper), and though I don't have good data I have enough experience to say that you won't be happy if you're at -90 dB with a gateway in the same building.

I don't quite understand the comment on antenna on the device. I don't see an antenna attached to the feather in the photo, and I don't see a feed. If you're using a u.FL, that's really awful on the Feathers in my experience. I have had numerous people have problems with that -- hard to solder and hard to get rigth and mechanically not stable. u.FLs have to be attached at the factory, I think.

Here's a photo of a (Feather-like) device showing what I mean by an antenna on a Feather.

[chipmc]

OK, getting back into this after having to do some day-job work.

On your three points note: 1) Clock may be off but I am including LMIC_setClockError(MAX_CLOCK_ERROR * 1 / 100); in Setup()

2) Yes, connected - pls see photo

3) I am using a Taoglas PC-91 antenna and was able to get the U.fl connector on. Am getting the following from the JSON I send to the gateway:

"root": {5 items "Gateway":"004A30E5" "RSSI":"-63.0" "SNR":"8.75" "ESP":"-63.543648" "Time":" 2019-04-16T20:15:31.246+02:00" }

[chipmc]

Here is something I just noticed.

When I run the compliance script, there is no activity on the gateway logs. When I run my modified ttn-otaa-feather-us915 from the LMIC examples it connects. So the radio and antenna seem to be off the hook.

Here are the changes I make to the Example: Add the following:

In the header:

include

My keys for machineQ

Add to Setup() LMIC_setClockError(MAX_CLOCK_ERROR * 1 / 100); LMIC_setLinkCheckMode(0);

Subtract from Setup() //LMIC_setDrTxpow(DR_SF7,14); //LMIC_selectSubBand(1);

Here is the Serial Log: Starting Packet queued 313299: EV_JOINING 313389: EV_TXSTART 718503: Unknown event: 20 720561: EV_TXSTART 1104263: Unknown event: 20 1470175: EV_TXSTART 1811428: EV_JOINED netid: 34 devaddr: 451FFC99 artKey: E2-91-D1-B9-50-15-DF-5-3F-5A-90-E9-3A-2D-B7-32 nwkKey: 10-7E-E1-46-79-7F-CD-42-13-D1-38-95-EE-7F-49-82 1811702: EV_TXSTART 2080713: EV_TXCOMPLETE (includes waiting for RX windows)

And here are the entries from machineQ

* Upload *** DevAddr Fport None MessageTypeText JoinRequest PayloadHex None MICHex 3a4ec9d0 PrimaryGatewayESP -56.22 SpreadingFactor SF 10 Airtime 0.370688 SubBand G20 Channel LC7 GatewayID 004A30E5 GatewayLatitide 34.7248 GatewayLongitude -86.590103 MacCommands 00000101010101010100ff1ee710b6769877ed3a4ec9d0 ADRbit 0 ADRAckReq 0 AckRequested 0 ACKbit 0 FPending 0 DecodedMacCommands

MAC.Command.JoinRequest MAC.JoinRequest.JoinEUI : 0x0101010101010100 MAC.JoinRequest.DevEUI : 0x9876b610e71eff00 MAC.JoinRequest.DevNonce : 0xed77

---

****. Download **** DevAddr Fport None MessageTypeText JoinAccept PayloadHex None MICHex PrimaryGatewayESP N/A SpreadingFactor SF 10 Airtime 0.329728 SubBand G20 Channel LC7 GatewayID 004A30E5 MacCommands 20214032de02e2b575f10a1858fed1fc0b ADRbit 0 ADRAckReq 0 AckRequested 0 ACKbit 0 FPending 0 DecodedMacCommands

---

Is this what you were looking for?

[terrillmoore]

@chipmc this is starting to make sense. Please see this line in the example:

https://github.com/mcci-catena/arduino-lmic/blob/dc18ee9568cb15d08adead0c367dbc660568317b/examples/compliance-otaa-halconfig/compliance-otaa-halconfig.ino#L533

It is:

 LMIC_selectSubBand(1);

Please comment it out, since you're using machineQ. They normally use a different subband, and it's not really consistent across their network. Once you remove this, the device will scan all 64 channels (randomly) trying to connect to the gateway. The JOIN_ACCEPT and subsequent MAC messages will include info to reduce the channel mask to the ones that are actually available in the neighborhood of the device.

You'll have to send a few more join messages (maybe as many as ten or twenty, because it really is random, and it's not optimum for machineQ). But you should eventually hit the gateway.

I use 5% clock error, not 1% clock error. The reason for the clock error is not clock error per se, it's the indeterminacy of the Arduino system. 5% gives you more margin of error in everything else.

[chipmc]

Yep, commenting out that one line enabled the compliance script to connect. Here is the log:

Starting Packet queued 313342: EV_JOINING 313423: EV_TXSTART: ch 15 rps=0x4 (SF10 BW125 CR 4/5 Crc IH=0), datarate 0, opmode 88C 633600: EV_RXSTART: freq=927.5 rps=0x94 (SF10 BW500 CR 4/5 NoCrc IH=0), datarate 0, opmode 88C, txend 336648, delta ms 4751 693603: EV_RXSTART: freq=923.3 rps=0x96 (SF12 BW500 CR 4/5 NoCrc IH=0), datarate 0, opmode 88C, txend 336648, delta ms 5711 733635: EV_JOIN_TXCOMPLETE: saveIrqFlags 0x80 773604: EV_TXSTART: ch 65 rps=0x12 (SF8 BW500 CR 4/5 Crc IH=0), datarate 4, opmode 88C 1085822: EV_RXSTART: freq=923.9 rps=0x91 (SF7 BW500 CR 4/5 NoCrc IH=0), datarate 4, opmode 88C, txend 775422, delta ms 4966 1132378: EV_RXSTART: freq=923.3 rps=0x96 (SF12 BW500 CR 4/5 NoCrc IH=0), datarate 4, opmode 88C, txend 775422, delta ms 5711 1172409: EV_JOIN_TXCOMPLETE: saveIrqFlags 0x80 1222800: EV_TXSTART: ch 53 rps=0x4 (SF10 BW125 CR 4/5 Crc IH=0), datarate 0, opmode 88C 1542977: EV_RXSTART: freq=926.3 rps=0x94 (SF10 BW500 CR 4/5 NoCrc IH=0), datarate 0, opmode 88C, txend 1246025, delta ms 4751 1602980: EV_RXSTART: freq=923.3 rps=0x96 (SF12 BW500 CR 4/5 NoCrc IH=0), datarate 0, opmode 88C, txend 1246025, delta ms 5711 1643013: EV_JOIN_TXCOMPLETE: saveIrqFlags 0x80 1652926: EV_TXSTART: ch 70 rps=0x12 (SF8 BW500 CR 4/5 Crc IH=0), datarate 4, opmode 88C 1965144: EV_RXSTART: freq=926.9 rps=0x91 (SF7 BW500 CR 4/5 NoCrc IH=0), datarate 4, opmode 88C, txend 1654745, delta ms 4966 2262568: EV_TXSTART: ch 5 rps=0x4 (SF10 BW125 CR 4/5 Crc IH=0), datarate 0, opmode 88C 2582745: EV_RXSTART: freq=926.3 rps=0x94 (SF10 BW500 CR 4/5 NoCrc IH=0), datarate 0, opmode 88C, txend 2285794, delta ms 4751 2603749: EV_JOINED: ch 5 netid: 34 devaddr: 451FFC99 artKey: C4-EB-B0-60-84-67-EF-3F-7E-5D-CE-E3-33-B0-C-40 nwkKey: 6D-AE-AC-DD-8C-15-6F-28-D6-4-86-78-ED-E4-45-42 2603883: EV_TXSTART: ch 2 rps=0x4 (SF10 BW125 CR 4/5 Crc IH=0), datarate 0, opmode 888 2689166: EV_RXSTART: freq=924.5 rps=0x94 (SF10 BW500 CR 4/5 NoCrc IH=0), datarate 0, opmode 888, txend 2629671, delta ms 951 2698173: EV_TXCOMPLETE: ch 2 rps=0x94 (SF10 BW500 CR 4/5 NoCrc IH=0) txrxflags 0x21 Packet queued 3010807: EV_TXSTART: ch 13 rps=0x4 (SF10 BW125 CR 4/5 Crc IH=0), datarate 0, opmode 888 3096092: EV_RXSTART: freq=926.3 rps=0x94 (SF10 BW500 CR 4/5 NoCrc IH=0), datarate 0, opmode 888, txend 3036597, delta ms 951 3156096: EV_RXSTART: freq=923.3 rps=0x96 (SF12 BW500 CR 4/5 NoCrc IH=0), datarate 0, opmode 888, txend 3036597, delta ms 1911 3244039: EV_TXCOMPLETE: ch 13 rps=0x96 (SF12 BW500 CR 4/5 NoCrc IH=0) txrxflags 0x20 Packet queued 3556674: EV_TXSTART: ch 34 rps=0x4 (SF10 BW125 CR 4/5 Crc IH=0), datarate 0, opmode 888 3641957: EV_RXSTART: freq=924.5 rps=0x94 (SF10 BW500 CR 4/5 NoCrc IH=0), datarate 0, opmode 888, txend 3582461, delta ms 951 3701960: EV_RXSTART: freq=923.3 rps=0x96 (SF12 BW500 CR 4/5 NoCrc IH=0), datarate 0, opmode 888, txend 3582461, delta ms 1911 3854495: EV_TXCOMPLETE: ch 34 rps=0x96 (SF12 BW500 CR 4/5 NoCrc IH=0) txrxflags 0x20 Packet queued 4167131: EV_TXSTART: ch 23 rps=0x4 (SF10 BW125 CR 4/5 Crc IH=0), datarate 0, opmode 888 4252413: EV_RXSTART: freq=927.5 rps=0x94 (SF10 BW500 CR 4/5 NoCrc IH=0), datarate 0, opmode 888, txend 4192918, delta ms 951 4312418: EV_RXSTART: freq=923.3 rps=0x96 (SF12 BW500 CR 4/5 NoCrc IH=0), datarate 0, opmode 888, txend 4192918, delta ms 1912 4411724: EV_TXCOMPLETE: ch 23 rps=0x96 (SF12 BW500 CR 4/5 NoCrc IH=0) txrxflags 0x20 Packet queued 4724357: EV_TXSTART: ch 10 rps=0x4 (SF10 BW125 CR 4/5 Crc IH=0), datarate 0, opmode 888 4809639: EV_RXSTART: freq=924.5 rps=0x94 (SF10 BW500 CR 4/5 NoCrc IH=0), datarate 0, opmode 888, txend 4750143, delta ms 951 4869643: EV_RXSTART: freq=923.3 rps=0x96 (SF12 BW500 CR 4/5 NoCrc IH=0), datarate 0, opmode 888, txend 4750143, delta ms 1912 5043849: EV_TXCOMPLETE: ch 10 rps=0x96 (SF12 BW500 CR 4/5 NoCrc IH=0) txrxflags 0x20

Looks like you fixed it - or fixed it as well as machineQ will allow.

Thank you

[terrillmoore]

Excellent. Now try rebuilding your main script sketch, but using the latest LMIC library, and see how it goes.

[chipmc]

Will do. So far, not that encouraging. Two questions as I work through what is breaking things:

1) I am getting a lot of this in the serial terminal: 0:00:13: Unknown event: 20 0:00:14: EV_TXSTART

• Any chance we could figure out what the Unknown event is?

2) I get that without selectBand(1) there will need to be a number of tries, is there anyway to speed that process up? Is there a way to try every second or two until we get connected and then slow the transmission frequency down?

[terrillmoore]

I know what the unknown event is; it's due to the improvements in the LMIC that aren't yet reflected in every script. That's EV_JOIN_TXCOMPLETE. Since this is the arduino-lorawn repo, I'm guessing you're using the built-in version and possibly not the latest one from the latest LMIC. It's harmless, you can ignore it for a moment.

On the excessive joins: try LMIC_selectBand(0);

Or the equivalent:

Arduino_LoRaWAN::cLMIC::SelectSubBand(
        Arduino_LoRaWAN::cLMIC::SubBand::SubBand_1
        );

(Subbands are numbered origin 1 in most places, but not by the LMIC itself, which for historical reasons uses origin 0.)

[chipmc]

hmm, neither of those options would compile.

First: /Users/chipmc/Documents/Maker/Arduino/Simple-Sense-LoRA-Prototype/Simple-Sense-LoRA-Prototype.ino: In function 'void setup()': Simple-Sense-LoRA-Prototype:88:22: error: 'LMIC_selectBand' was not declared in this scope LMIC_selectBand(0); ^ exit status 1 'LMIC_selectBand' was not declared in this scope

Second: /Users/chipmc/Documents/Maker/Arduino/Simple-Sense-LoRA-Prototype/Simple-Sense-LoRA-Prototype.ino: In function 'void setup()': Simple-Sense-LoRA-Prototype:88:5: error: incomplete type 'Arduino_LoRaWAN::cLMIC' used in nested name specifier Arduino_LoRaWAN::cLMIC::SelectSubBand( ^ Simple-Sense-LoRA-Prototype:89:33: error: 'Arduino_LoRaWAN::cLMIC::SubBand' has not been declared Arduino_LoRaWAN::cLMIC::SubBand::SubBand_1 ^ exit status 1 incomplete type 'Arduino_LoRaWAN::cLMIC' used in nested name specifier

[terrillmoore]

Sorry, it's LMIC_selectSubBand(0) -- just like the one you commented out.

If you#include <Arduino_LoRaWAN_lmic.h>, it should be in scope. And so will the other one, I believe.

[paulalting]

Coming back to provide an update for you.

I found that this library was not the problem at all in my case. What I did find was that the gateway I am using in this instance, a RAK831 Pilot, a RPi with RAK831 board with GPS sub board installed with LoRaServer-OS from Orne Brocaar was the issue.

I was simply getting joinRequest joinAccept loops, thinking that the Feather was deaf to the joinAccept from the gateway. I suspect the configuration from Brocaar is not quite correct for this gateway, which is something I intend to investigate further if time permits.

I was pulling my hair out thinking the problem was with the software I have on the Feather M0, which was not the case at all.

In fact, the compliance test from this library run fine as does my original code. Further to this, I have since moved back to using your other library Terry, mcci-LoRaWAN-lmic-2.3.2, where I first started with, and now works fine.

So, thank you for your persistence and efforts with the libraries you provide, I very much appreciate it, thank you.

[terrillmoore]

@paulalting Good! Thanks for the feedback.

@chipmc where are we on your problems?

[chipmc]

Some progress, using your example code, I can get connected. When I use my code, I run into issues. I need to spend some more time working the problem - hoping for a quiet Friday. Will let you know if I get stuck or find anything else that needs fixing. Can I do that and close this by Friday if I can't pin down any more related issues?

Thanks for all your help! Chip

[iotpanama]

Good morning. I am trying to connect via OTAA to my Ursalink gateway, with the MCCI LORAWAN LMIC library. I am getting an error EV_TXCOMPLETE: no JoinAccept. connecting with ABP I have no problem. Can you give me some kind of guidance. the version of the library is 3.2.0. The project is with an ESP32 and a HopeRFM95W