Join Requests are not be acknowledged #74
Comments
|
@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 |
|
@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 |
|
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%: 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. |
|
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
<#74 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AF5tbReTq4jhuTLor_OTRrZ7GSVj_ZL_ks5vMIjSgaJpZM4ZkPOg>
.
|
|
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 |
|
I'm running around today, but I'll try to take a look at the code during travel this afternoon. |
|
Very sorry @chipmc, this fell off my list. Is this still a problem? |
|
Terry, Yes, and any help would be greatly appreciated. Thanks, Chip |
|
I just re-noticed that this is for machineQ. My suggestions are as follows.
Thanks, |
|
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 |
|
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.) |
|
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 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 |
|
Hi Terry and Chip, 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. 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 ? 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 |
|
@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. |
|
@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? |
|
@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?" |
|
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. Below is the printed data from the Feather M0 Terry, is there any other diagnostic data that we can get that would highlight more exactly where and what the problem is ? |
|
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:
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. |
|
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 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. |
|
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. |
|
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 ? |
|
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.
|
|
OK, getting back into this after having to do some day-job work. On your three points note:
"root":
|
|
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: In the header: Add to Setup() Subtract from Setup() Here is the Serial Log: And here are the entries from machineQ ******************* Upload ************************* MAC.Command.JoinRequest MAC.JoinRequest.JoinEUI : 0x0101010101010100 MAC.JoinRequest.DevEUI : 0x9876b610e71eff00 MAC.JoinRequest.DevNonce : 0xed77 ********************. Download ************************ Is this what you were looking for? |
|
@chipmc this is starting to make sense. Please see this line in the example: 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. |
|
Yep, commenting out that one line enabled the compliance script to connect. Here is the log: Starting Looks like you fixed it - or fixed it as well as machineQ will allow. Thank you |
|
Excellent. Now try rebuilding your main |
|
Will do. So far, not that encouraging. Two questions as I work through what is breaking things:
|
|
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 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.) |
|
hmm, neither of those options would compile. First: Second: /Users/chipmc/Documents/Maker/Arduino/Simple-Sense-LoRA-Prototype/Simple-Sense-LoRA-Prototype.ino: In function 'void setup()': |
|
Sorry, it's If you |
|
Coming back to provide an update for you. I found that this library was not the problem at all in my case. 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. So, thank you for your persistence and efforts with the libraries you provide, I very much appreciate it, thank you. |
|
@paulalting Good! Thanks for the feedback. @chipmc where are we on your problems? |
|
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 |
|
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 |
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
The text was updated successfully, but these errors were encountered: