How increase STM32WL55JC payload upload interval from 10 s to a larger value

End Devices (Nodes)
1

STM32Cube_FW_WL_V1.2.0, lorawan_end_node project:

For testing the payload is sent every 10 seconds. I believe the following is the resultant airtime calculation:

.016696 sec per payload message

2 messages per upload

10 second interval

2 x 6 x 60 x 24 = 1066 seconds per day

Just a bit over the 30 second fup limit.

In the STM32Cube_FW_WL_V1.2.0, lorawan_end_node project:
file: lora_app.h has the following line:

#define APP_TX_DUTYCYCLE 10000 << meaning 10 sec

Increasing the 10000 (=10 sec) does not work; the stm32wl55jc board will not join any longer.

What variable can be changed to increase it from 10 sec to a larger interval? <<

Am I missing something re the airtime calculation?

1 Like
2

Welcome

On what SF and bandwidth are you basing your calculation?

Is this two bytes or two sensors values (like temperature and humidity)?

3

I doubt it, minimum air time would be circa 45mS ā€¦

1 Like
4

Increasing it to what value?

The STM32Cube WL is not aware of TTN so it knows nothing of the FUP - although 10 seconds is a bit much for any private network anyway.

If you do a search for references to APP_TX_DUTYCYCLE it should lead you to where it sets the timer period which will inform you of the data type - which is 32 bit so should be more than capable of running for 49 days ā€¦

What board are you using?

1 Like
5

Itā€™s from the TTN console, live data, Event Details. This is the info from each payload, each 10s.

received_at": "2022-09-16T18:52:02.898360924Z",
      "consumed_airtime": "0.061696s",
      "network_ids": {
        "net_id": "000013",
        "tenant_id": "ttn",
        "cluster_id": "nam1",
        "cluster_address": "nam1.cloud.thethings.network"
6

I did get a good reply from my ST ticket. Here is the info further below.
I am learning C so am not confident in ability to make this simple change. So, if a kind soul could show how to change the periodicity in the code below, that would be wonderful. Then, I could base my next debug steps on at least one known thing. Could someone make the change to 60 seconds ?

[MCU Support Center --] (ST Employee)

Actions for this Feed Item

Hi,

in the file lora_app.c, there is a function call which allows you to change the periodicity.

You should be able to call this function and set the rate.

Also, in the code below, you will see there is a timer associated with the periodicity. You should be able to set this timer directly.

Hope this helps.

ST MCU Support

static void OnTxPeriodicityChanged(uint32_t periodicity)

{

/* USER CODE BEGIN OnTxPeriodicityChanged_1 */

/* USER CODE END OnTxPeriodicityChanged_1 */

TxPeriodicity = periodicity;

if (TxPeriodicity == 0)

{

/* Revert to application default periodicity */

TxPeriodicity = APP_TX_DUTYCYCLE;

}

/* Update timer periodicity */

UTIL_TIMER_Stop(&TxTimer);

UTIL_TIMER_SetPeriod(&TxTimer, TxPeriodicity);

UTIL_TIMER_Start(&TxTimer);

/* USER CODE BEGIN OnTxPeriodicityChanged_2 */

/* USER CODE END OnTxPeriodicityChanged_2 */

}
1 Like
7

There is, sadly, no such thing. The answer has only marginal relevance to the matter at hand, this is a support pattern typical of ST staff unless you have a FAE assigned to your account.

Nope, because that would breach TTN Fair Use Policy.


I work with this code base multiple times per week and I personally have no trouble at all setting the figure to any value I like. As soon as you answer my question above I will be able to help.

1 Like
8

Additional: Questions, as there are two.

And please format code and serial output using the </> tool

1 Like
9

Hi, thanks again for the reply. Apologies for ignoring your questions. I got all exited about a reply from ST. And, I do know better re formatting the code for posting - again I was in ā€˜do it quick modeā€™; bad form. I also am pretty anxious about this thing running at 10s per upload; I want to test it but I donā€™t want to use so much airtime.

Anyway, here is my try at responding properly:

  1. Increasing it to what value? I was looking to at least test 60s, then move it to 6 hours for example. I am simply using the example that ST discussed in their 5 part getting started series. Temp, humidity.
  2. What board are you using? Nucleo_WL55JC. With the IKS01A3 mounted.

I am trying to keep these messages brief, so please let me know where I have missed providing required info.

10

There is no quick mode with LoRaWAN ā€¦

Whilst breaking FUP, there is no reason why 60000 for APP_TX_DUTYCYCLE shouldnā€™t work - as above, the timer value is a uint32 so can run to 4,294,967,295 which is ~49 days. I normally set it something like this:

#define APP_TX_DUTYCYCLE (5 * 60 * 1000)

for clarity - ie five minutes - which would be 300,000.

And I canā€™t think why this would stop it from joining.

Can you share the serial debug output (appropriately formatted).

I normally use the TTI GNSE which is the same chip and the LoRa-E5 which is single core, but I do have the STM32 board plus a Cube workspace so easy enough to check - but the GNSE which Iā€™ve been working on most of this week is pretty much identical to what you have.

The ST crew pointed you to the function to change the period which you could use at some point in your code, but by your own admission you havenā€™t the experience to know where, which you can get in time, but be aware that the code base is a tangled web that takes a fair amount of time for even an experienced C programmer to figure out. But you can see in that function that it defaults to APP_TX_DUTYCYCLE and that the function takes a uint32, so changing APP_TX_DUTYCYCLE in lora_app.h does exactly the same right from boot up.

1 Like
11

I started out yesterday modifying APP_TX_DUTYCYCLE to a larger value. Given your advice I went back to that, as it is a clearer change in the code, and it is supposed to work.
In fact it does work. Where my problem was/is, is with say a 5 minute duty cycle, it also means that the join process also follows the 5 minute cycle it appears.
The problem is that the rejoin process runs into the dreaded DevNonce issue. When it was set at 10s it sorted itself out fairly quickly. But at 5 minute it takes a lot longer. I forced myself to leave the room, and start making dinner. After that was under way, I checked back, and lo and behold the guy had joined.
Now the payload is happening every 5 minutes as expected.
I just had to be more patient.

Many thanks for being patient with me.

Now, I can proceed, knowing I can stay within the FUP at will.

Maybe I will now order up another of those boards also.

1 Like
12

I can tell you how to kick start a first uplink after a join - but the reality is that most devices join once or twice in their life so this shouldnā€™t be an issue for deployment - however it is a PitA for development. Iā€™ll dig out a STM32WL board to check where the code is in the Cube code base - mines evolved quite a bit over the last year.

Maybe order something with a wider support base & simpler code - like using LMIC on an Adafruit Feather M0 with RFM95 - using the Arduino environment.

LoRaMac-node is a handful and all the parts are spread over many files so you end up making changes all over the place and then losing track. And then when you want to implement a sensor, then it can get messy.

Whereas if you are starting out with C & LoRaWAN, then the Arduino format is far more productive.

13

That tip for kick starting a first uplink would be great.
I have a longer story that I held back on. I indeed have a few other toys at my disposal, and have gotten the Arduino IDE up and running. I also see that maybe I can even interface the Nucleo WL with the Arduino IDE, and the hello world prints out all the sensors. It sure would be easier to fashion a lora app from this.
Adding a sensor to the ST software looks to be a real torture.
Maybe sometime I will expose my fun with MKR1310. Not a good story so far.
But itā€™s all a great learning. Nice to find a use for my C Udemy course :).

14

I believe you are right re LMIC/Feather M0. It appears to be well supported. I figure on giving it a try. The Wio-E5 looks promising also. I had got an E5 working via AT commands a while ago.
The RAK7201 buttons work well and the added cost of a finished product may just be worth it.
The ST stuff may have to sit on the side until/if more arduino support happens.
Just wondering your opinion re the mass deprecation of anything pre-V3 of ttn. It seems such a waste of good information - wouldnā€™t some small updates render a lot of support information useful?

15

What is the opinion on PlatformIO?
From their github: ā€œPlatformIO is used instead of Arduino IDE because more flexible, more powerful and it better supports cross-platform development.ā€
Is it better?

16

Itā€™s not clear but assuming you use the ST Cube WL AT commands and use a serial link to another MCU that is programmable via Arduino, then yes, easier in some contexts.

What does this mean?

Thats approximately identical to the STM32WL + Arduino combo above.

They will rust before that becomes a reliable option.

What is ā€œanything pre-V3ā€? Do you mean the docs on the TTN site? Perhaps as part of your learning you could transfer it over to the v3? Or just read the bits that are generic and discount the older stuff. Almost ALL the technical documentation is a movable feast - you end up learning to figure your way through the maze. Thereā€™s too many moving parts for there to be one comprehensive source of information.

The best IDE is the one you know well & can work efficiently & effectively with. There are many IDEs that get imposed on you - there can never be one true IDE. So like learning to drive cars that have controls in different places, so it is with IDEā€™s.

However PlatformIO isnā€™t an IDE - itā€™s a system / UI implemented in an IDE that then uses other libraries to provide a coding environment for different microcontrollers. Think Russian dolls.

Learn to code in assembly on paper, hand compile the code to hex and enter it with on/off switches - the only direct & reliable way! Or learn GCC + make. After that it all goes down hill.

17

MKR1310: It means the radio does not appear to work. All my other devices are visible in my gateway logs, but this isnā€™t, and it wonā€™t join. Itā€™s a longer story and requires supporting data, logs etc. I simply should not have written my note at all. Maybe after I have had the scope on the RF.

Looks like we violently agree on the pre-V3 info note.

I actually did exactly the process you mention: toggled the code via switches, but in octal. Loaded a paper tape loader. Then loaded the OS with the paper tape. Then the program. It took half the booked slot to get the teletype working.

My feather M0 should arrive tomorrow. Better times.

Thanks for the discussion.

2 Likes