That would depend on the software you are running on the end node. It sounded like you were using Dragino’s software, not LMiC.
Please be specific about the software - eg, link to the exact source version
Thanks, cslorabox,
This is the one I’m using. Version 3.2.0.
It’s not Dragino’s software. Am I wrong?
Where did you get that idea?
I believe it may be a mistaken confusion with the non-standard setting documented for EU868.
I could perhaps be wrong, but it does not match the published TTN AS923 settings
https://www.thethingsnetwork.org/docs/lorawan/frequency-plans.html
In your attempts, at what frequency spreading factor is the gateway actually transmitting?
This idea comes from Dragino agent in Japan.
Currently I don’t use this setting.
And to be honest I don’t know exactly what LMIC file defines the TTN AS923 setting.
Where can I see those settings?
Can I have any advices?
Nobody knows?
What have you looked at? There should be no obvious reason for you to change any of the LMIC files to setup regional settings.
Please can you stop posting screen shots by default, particularly of web pages that can be linked to. If it’s a log, it should be copy & pasted as text. See here on how to format posts.
Here are three things to do:
- Post a copy (as text) of your lmic_project_config.h so we can see the regional settings in use.
- Set #define LMIC_DEBUG_LEVEL to 1 in config.h so you get more debug output and then post it (as text) showing from power up to join fail or downlink fail.
- Post the gateway log (as text) for the corresponding time period.
Thanks, descartes,
- Post a copy (as text) of your lmic_project_config.h so we can see the regional settings in use.
Here is my lmic_project_config.h.
// project-specific definitions
//#define CFG_eu868 1
//#define CFG_us915 1
//#define CFG_au915 1
//#define CFG_as923 1
#define CFG_as923jp 1
// #define LMIC_COUNTRY_CODE LMIC_COUNTRY_CODE_JP /* for as923-JP */
//#define CFG_kr920 1
//#define CFG_in866 1
#define CFG_sx1276_radio 1
//#define LMIC_USE_INTERRUPTS
This is the recommendation of Japanese Dragino agent.
To be honest I’m not sure it’s enough or not.
Hi, descartes,
- Set #define LMIC_DEBUG_LEVEL to 1 in config.h so you get more debug output and then post it (as text) showing from power up to join fail or downlink fail.
This seems to be a good information for me. But I tried I got memory usage error.
I have to cut memory usage. I need time to strugle.
Anyway I think my problem was caused by downlink packet frequency and timing.
So I need following information.
(1)Do I have a way to check, measure the current setting of RX1 and RX2 on my endnode?
(2)What files on LMIC library define those numbers?
(3)Do I have a way if downlink messages can reach my endnode from the gateway within the RX1/RX2 time frame?
(4)I’ve read downlink problems can be solved by extending the RX1/RX2 length. How can I do that?
I asked several times. But nobody answered to my question. Why?
People are trying to help by providing information on how to debug your issues. The answers may not be the ones you are expecting, but they are sound.
In answer to your questions:
- Yes if you know how to modify the LMIC code and connect the node to an oscilloscope. Given your questions I seriously doubt you will be able to accomplish this.
- Have you searched the source code? What did you find?
- That would link back to question 1.
- This question is answered almost weekly on the forum. However randomly changing things in the hope it will start to work is not a sound solution. If you still want to try, add the following line at the end of your init function.
LMIC_setClockError((MAX_CLOCK_ERROR * 10) / 100);
Perhaps because you, yourself, have not answered our questions: what frequency and spreading factor is your gateway actually transmitting the missed downlinks on?
As for the debug logging:
I tried I got memory usage error.
This is why trying to squeeze a LoRaWAN stack into an ATmega328 cannot be recommended
2 Likes
Thanks, kersing,
- Yes if you know how to modify the LMIC code and connect the node to an oscilloscope. Given your questions I seriously doubt you will be able to accomplish this.
- Have you searched the source code? What did you find?
- That would link back to question 1.
- This question is answered almost weekly on the forum. However randomly changing things in the hope it will start to work is not a sound solution. If you still want to try, add the following line at the end of your init function.
LMIC_setClockError((MAX_CLOCK_ERROR * 10) / 100);
(1)Oscilloscope!? Is it the only way to check them? Do you have any good documents which tells
how to do that? I expect somebody had done similar things.
You don’t have another way? like applying some debug codes in the source code and print
some values. Dragino guy told me applying AT commands. But recently he said Dragino LoRa
mini doesn’t have AT command functions …
(2)I found some information in my code. But I’m not sure these are the right part. As I said several
times. I don’t think my problems are not a special one for the experienced people. For the people
who have implemented OTAA and downlink, some people know how to solve the problems. That’s
why I’m asking for “common sense” information to solve problems.
(3)Same as above (2). Please give me “common sense”, typical, well-experienced, easy method to
solve problems. Many documents says “ABP is easy. But OTAA is trouble-some.” But I think it’s
strange nobody provides easy-to-solve documents or books, like “OTAA/downlink for Dummies.”
I’m expecting common, typical procedure how to analyze problems, adjust RX1/RX2 time-frame,
frequencies and succeed for OTAA. I’m a novice engineer. But I’m expecting genius engineers in the
world have good technique and knowledge I don’t know.
(4)Is that the only way? I tried, but no changes. And Dragino guy didn’t tell the code realizes changing
RX1/RX2 length. Is there another method to extend RX1/RX2 length?
You may want to reconsider your approach to getting volunteer engineers who give up their valuable time to answer questions.
Given all the moving parts that make up LoRaWAN, it is not as simple as creating a Dummies guide because all sorts of things could be going on.
The Dragino LoRa mini dev is basically an Arduino Pro Mini with a radio chip which is a combination I use a fair amount for appropriate applications. If you want to read this, you’ll see that it took me a while to get to grips with this hardware combination and that it does in fact work:
I think this entire thread has got in to a tailspin and about the only thing we haven’t looked at is the possibility that the hardware is compromised in some way. So rather than collectively banging our head against the wall, perhaps you could get a different device to try out - preferably one with more RAM & Flash.
One possibility is the Adafruit Feather M0 with RFM95. I know this works because I’m helping out someone on another thread (see here) so I have one on my desk working away quite happily. Note, you will need to add a connection to the board for it to work with LoRaWAN - all the details are on the Adafruit website.
Alternatively if you want to sidestep all the LoRaWAN challenges, then the Arduino MKR WAN 1310 has both a powerful processor and a dedicated LoRaWAN module that will take care of LoRaWAN code for you, but you will still need to configure it.
1 Like
This is indeed a good choice, particularly as it’s the original platform used for development of MCCI LMiC. Also worth noting that they have some historic experience with Japan, and test equipment able to run closed-loop tests on the frequency plan used by one region, even while physically sitting in another. If you were using the feather & RFM95 board, issues getting it to work in Japan would be quite appropriate to raise in an issue on the github repo.
That has historically not had perfect support for all regions, so it would make sense to double check that it will actually work in Japan before purchase. In theory the LoRaWAN stack is user-fixable, in practice it’s going to be a bit more complex to do so in such context.
1 Like
- experienced engineers have been trying to help you. They haven’t written a dummy guide because there are different solution to different problems and documenting them all does take a lot of time for which no-one is paying.
- you expect something, based on what? We are providing a free service to the community. If that service does not match your expectations, feel free to search for paid for help, don’t make your mismatched expectations our problem.
- you should not need to adjust RX1/RX2 timeframe in the MCCI LMIC stack. Depending on the hardware you might have to relax the timing so your hardware listens at the right time. The only way to know for sure is to use hardware (oscilloscope) to check the timing because added debug messages using the serial port change that timing.
(4)I’ve read downlink problems can be solved by extending the RX1/RX2 length. How can I do that?
Hi, Abe-san,
In my experience,the number of times is more important than the RX1/RX2 length.
There is a great deal of variation in the time it takes for the gateway to throw Join Request to the TTN server and receive Join Accept.
.(At least in my enviroment it’s not a level to extend the RX1/2 length, and in most cases Join Accept has not reached in RX1/2 correspoding to Join Request.)
Therefore, the Gateway that received Join Accept after RX1/2 has waiting for the timing RX1/2 that its own station can transmit next.
If.possible, the End device will send empty frame that does not affect the OTAA authentication process and the Gateway will get the timing to send the Join Accept. I dit that.
(The other method is for the End device to send another Join Request to receive Join Accept, but the Join Accept that can be received at that time is for the old Join Request and is confusing, so I stopped it.)
Please forgive me if there is a lack of understanding.
Thank you.
Thanks, cslorabox,
Do you think I can use Adafruit Feather M0 with RFM95 in Japan?
I don’t think so unfortunately.
Why not?
That should not be causing issues; if it is, the gateway needs a lower latency internet connection.
If.possible, the End device will send empty frame that does not affect the OTAA authentication process and the Gateway will get the timing to send the Join Accept.
No, that’s not workable. The join accept can only be sent in direct response to the join request, not in response anything else.
Provided it is the right frequency radio module, this would be an issue of software not hardware.
As I was explaining before, this is one of the test platforms for MCCI LMiC, who have some past experience in Japan, and also have the ability to conduct “closed” tests on LoRaWAN operation in one country, even while sitting in another.
From my understanding we can NOT use Adafruit Feather M0 with RFM95. Because it’s not
authorized, allowed to be used in Japan.
The device with RF function must meet technical standards compliance, and put the ahtorized
symbol, TELEC mark, on it.
Please let me know if I’m wrong, or you guys have information Adafruit Feather M0 with RFM95 is already autorized in Japan. I welcom such imformation.