Limiting the number of bytes on the uplink

I’m using a wl55jc1 ST demo board for development and I’m testing an example end node. I am using port 12 DR2 and acknowledgment in the packet. My payloads are limited to 8 bytes of data. If I try to send more than that it won’t. I don’t have much knowledge, but I believe that the issue is the Data Rate. Can someone confirm to me if the problem is to be using DR2? I’m not the one who selects the DR. It already defines this DR2 by default.
Any help I appreciate.
Thanks

Check out airtime calculation for payload limits and duty cycle/dwell time limits in your territory for any given DR/SF e.g.
https://avbentem.github.io/airtime-calculator/ttn/eu868/53

Note:

Please dont! Use forum search and consider TTN FUP - limits downlinks…

Your using acknowledgement with TTN ?

Also I assume you are in Brazil? (US915?) In EU DR2 is SF10 for US DR2 is SF8 - can you confirm what baseline you are using? SF8 should be well in margin assuming you are not sending too often, SF10 starts to butt up against Dwell Time constraints! As ever on the forum…details details…dont have the volunteer have to ask too many questions! :wink:

Hi, thanks. Yes i do. → MSG TYPE:CONFIRMED [NACK]

Dude, thank you so much. I’m breaking new ground, hehehe. Yes, I’m from Brazil and I’m using the AU915 frequency. There are many questions and little information. Your help is important.

I send with a very high frequency. And excuse my ignorance, but I didn’t understand what FS8 or FS10 means. Who limits the traffic of my messages? is TTN?

The Police.

There is plenty of information in the documentation about duty cycle and fair use policy, which requests that you do not use acknowledgements as a default as you are limited to 10 downlinks a day. And sending at a very high frequency is not good either, check out the air time calculator web link above.

Thanks Nick McCloud, where do i access this documentation? My ttn account is free. I didn’t know about this msg limitation. I will need to transmit tens of thousands of messages per day. With confirmation. I will need to find another solution. Maybe create my own NS.
Thanks

(1) Sorry but that is not a LoRa or LoRaWAN use case…. Don’t even attempt it

Absolutely….

See (1)!

Use the airtime calculator….even with zero payload and just using FPort value to indicate some signal/condition au915 is max 647msg/day at fastest SF7…. As stated NOT LoRaWAN use case….
https://avbentem.github.io/airtime-calculator/ttn/au915/0

Jeff-UK, In my case, I use a gateway, in the radio part. My device connects to this gateway directly, so in this case there is no data usage limitation on the radio. This limit only happens when I send the data from the gateway through The Things Network to my application. I need TTN to validate my lorawan keys.

If I could create my own NS I wouldn’t need any third party to transfer my data. Then there would be no msg quantity limitation.

Yes you do have limitations, read Nick post and look up your local RF authorities limitations on ISM (915) usage.

The FUP is to do with the load you are putting on the RF and TTN servers, so every time you verify your keys you are using there server.

I don’t think the authorities will agree with you.

And even if you use your own LNS, the gateway(s) will not be able to transmit that many confirmations.

Maybe if you explain what you are trying to achieve, other than heavy fines or even a jail sentence, we can advise you better.

Yes there is. You share the frequencies with others. Monopolizing the frequencies will not be popular with other users of them.

In that case, even if you escape the TTN FUP you are still constrained wrt messages to 776 zero byte/hr…. See above link for details….not 000’s! Start adding payload and count quickly falls….and that with poorest range on SF7. Also if acking messages remember when gw tx’s an ACK it goes deaf to any other uplinks! Effectively creating a DoS for yourself, you can quickly find if the ack important and node missing one does a retry you cascade into message storm and near total message fail……to say nothing of impact to scarce shared spectrum and other users per Jac et al…… it comes down to (2)!!!

Not sure I understand - are you saying your gw is effectively a node ie no LoRaWAN radio connection between sensor and gw? Just hard wired? The Gw I then just an internet router and can talk directly to your own back end (over IP) and no LNS need be involved!

It would be very helpful to the members of this forum, who are volunteers trying to help people, if you describe, in some detail, what your project actually is, how you currently have the devices arranged, and what changes you want to make that seem to involve TTN.

"

And please provide the details on this also, why exactly do you need ‘tens of thousands’ of messages a day ? How many devices are there, how much data do they send and how often, why exactly is confirmation required ?

@lafourcade. Reading a bit of this thread, I think you are better off learning a bit more on LoRaWAN and LoRa in general. That should help answer most of the questions yourself.

You can use the following videos to learn about the basics of LoRaWAN.

The radio concepts that you are referring to Data Rate, Spreading Factor etc are explained by Thomas in the following awesome video.

TL;DR: Governments in each region have dedicated regulations committees to define how much data can be sent and how often on each frequency used. LoRaWAN specifications are then created to fit into those regional regulations. Creating a private NS won’t help since you are sharing radio frequencies with other devices in your region.

Thanks everyone for the messages. Jeff, Communication is wireless, using the AU915 frequency. I need to certify my device with the local agency, Anatel. At this point I will have to adapt to local determinations. Lorawan is a new technology and will also evolve. I’ll bet on it. Initially, I believe I can stay, initially, with a rate of 200 msgs per day, per device. There would be 100 confirmed uploads and 100 downloads. Every message I send is sensitive and needs confirmation.