2019-04-03 02:48 AM
Hello!
I have a NUCLEO-L073RZ development board, with the SX1272MB2DAS LoRa RF expansion board (from Semtech). I have downloaded code for it here at ST at: https://my.st.com/content/my_st_com/en/products/embedded-software/mcu-mpu-embedded-software/stm32-embedded-software/stm32cube-expansion-packages/i-cube-lrwan.license=1554282163016.product=I-CUBE-LRWAN.version=1.2.1.html
I have managed to get the code running, and I get contact with a gateway and can upload data to the server I want. The problem I have is that I can't find where I tell the board how often it should transmit the data. Currently the board transmit the data at the start when it get a connection to the gateway, and then 150 seconds later. After that it follows the pattern +165s in, +25s in, which repeats over and over. I wish to transmit the data to the gateway once an hour. How do I change this?
I have managed to find a constant that tells the board how often it should save data to AppData.Buff, which is the buffer that LoRa transmits. No matter how long or short that constant is it still transmits the data at the ~150 seconds interval.
If anything is unclear I can try to clarify further.
Kind regards,
Albin
2020-04-15 06:20 AM
Hi Albin,
I realise this is quite an old topic now, but did you ever resolve this? I am currently looking for the same thing.
Thank you,
Odhran
2020-04-21 04:20 AM
Hey Odhran!
I’m glad that someone else needed to use the card in a similar way as I did, when no one answered here I assumed my problem was something you �?shouldn’t do�? on the card.
I did manage to come up with a solution, a really simple one really. But hey, it works. Almost at the start of the main.c file there’s a defined dutycycle:
#define APP_TX_DUTYCYCLE x // x = time in ms
If I remember correctly, when that dutycycle number has been reached a flag will be raised which allows the circuit to make a transmission. So my solution was to change that number to however long I wanted it to wait. The shortest time that worked fine for me was 165 000 ms because of the pattern I wrote about in the post. I did try times up to 1 hour successfully, which is the time I needed, but it will most likely work with longer times as well.
I hope this solution can help you as well!
Kind regards,
Albin
2020-06-08 07:25 AM
Hi Albin,
I am currently still having this problem. I tried to set APP_TX_DUTYCYCLE to 5000ms.
This doesn't change a thing for me, i still get the 150 second waiting time between my two packages.
Do you have any other idea to fix this.
Looking forward to your response,
Kind regards,
Frank
2020-06-09 10:43 AM
Hello Frank!
As I wrote to Odhran previously the shortest time that worked 100% of the time for me was 165 000 ms, so 165 seconds. Maybe 150 seconds also works fine, I never tested it that much since I just needed to be able to choose a time at all. I never found any way to get it to transfer packages more often though sadly.
Good luck,
Albin
2020-06-09 02:05 PM
Hello Albin,
I did now tried every 5 min so 300 000 ms. But after like 3 sends the software is resetting, did you also had this problem?
My goal is to sent data once every hour or even bigger time gap between the sending.
2020-06-09 10:21 PM
2020-06-10 01:36 AM
Hey,
Thank you for your quick replies.
Too bad that nobody have some knowledge about this.
I put the time to 3 600 000 ms. and around every 15 min the code sent's a new message:
The counter is also 1 again at the TTN server so it looks like a reset of the code. (last post i said 3 times 5 min = 15min is the same.
I guess there is like a hard reset after 15 min using this software.
Could you maybe test this if your project is doing the same, if you still have it ofcourse.
Otherwise thank you for your help!
Kind Regards,
Frank
2020-06-10 01:44 AM
2020-06-10 02:45 AM
Hey,
Thanks,
And yes i used TeraTerm to see the prints, but after 15 it looks like the connection with the teraterm is gone also.. dont see any new prints.
Thank you for your help, maybe somebody else will answer this, but i have a bad feeling since nobody replied to your case since 1 year.
Frank