Reduce data rate messages in TTS

Hi LoRa Community!

I am new to LoRa and TTS, and I need to send data from my MKR Wan 1300 to TTS device with a high frequency, between 0.5 and 1 second between packet and packet, as I would like to monitor a real time signal later in Ubidots. I have an Arduino program that sends a 64 byte packet every 6 seconds at the moment, because if I try to send these packets at a lower frequency it fails to send the packet, and I would like it to be sent, as I said, between 0.5 and 1 second. I use a Spreading Factor of 7, BW of 125kHz, in Europe 868 MHz. I would like to know if this packet sending frequency is possible in TTS.

Thanks for reading me !

1 Like

You cant/shouldnt not only will it likely breach RF Regs in your area it will certainly breach TTN FUP and is frankly anti-social to use the scarce RF Spectrum that is available to the whole (world - not just TTN) Community

If that is an imperative for you wrt monitoring recommendation would be find another technology other than using LoRaWAN… remember LoRa = Long Range, and even if your packets are intended to be captured at short range for your own use and at low SF the fact is you will be spamming ALL gateways in range of hearing your node be they TTN, TTS private, other public operators and of course other private LoRaWAN deployments…

Search the forum for prior discussions and advise and see also e.g.
https://loratools.nl/#/airtime
https://www.thethingsnetwork.org/airtime-calculator/
and perhaps best of all
https://avbentem.github.io/airtime-calculator/ttn/eu868/27

I appreciate you are new and have only joined the forum in the last 24hrs or so but clearly you have not read any materials on this on the Forum and you really should be doing some background research and reading on the capabilities of the technology before diving in with such outlandish expectations :wink:

You may benefit from the following:

Read all of:https://www.thethingsnetwork.org/docs/lorawan/
The devices section of: https://www.thethingsnetwork.org/docs/devices/
The gateways section of: https://www.thethingsnetwork.org/docs/gateways/
The network section of: https://www.thethingsnetwork.org/docs/network/
The applications and API sections of: https://www.thethingsnetwork.org/docs/applications/

And check out TTN CTO Johan’s LoRaWAN intro on TTN Youtube channel - “All you need to know about…”

2 Likes

That is not a valid LoRaWAN use case. Please use more suitable technology. LoRaWAN is means for low volume low update rates, not real-time control.
Your use case while technically possible does not match the TTN fair use policy of 30 seconds airtime a day.

LoRaWAN uses a shared medium, your use case would use 1% of that medium, imagine everyone in your vicinity wanting the same.

1 Like

Legal (police, courts, fines, handcuffs, blue lights, bad food, that sort of thing) issues aside, the LoRaWAN spec requires a delay between the end of transmission and the reception of any downlink messages - at a bare minimum of 1 second, that means the 64 bytes at DR5 = 138.5ms + 1second + ~60ms for a smallish downlink means even if it was legal & within fair use policy for the shared community resource, you would be pressed to send more than 1.2 seconds. Currently the delay after uplink is set to 5seconds to allow the infrastructure to respond.

The Murata radio module on the MKRWAN 1300 will be rejecting the uplinks as the firmware on it enforces regional duty cycles. That is, it’s keeping you out of harms way.

So, short answer, along with the other reasons, physics (speed of light) says it is not possible with TTS or any other form of LoRaWAN.

1 Like

OK, I understand everything you are telling me. Anyway, with the use of MKR Wan 1300, and what I have commented above, and always respecting the TTN FUP, what would be the minimum time for sending these messages to TTS (in seconds)?

1 Like

Way beyond what is legal.

That packet has an air time of circa 115mS, so if sent every 500mS thats a duty cycle of 23%, the legal limit in Europe is 1%.

You could send packet at that rate but the duty cycle limit only allows you an air time of 36 seconds per hour at the proposed rate you could only transmit, at the proposed rate, for 155 seconds.

Use a different technology, 2.4Ghz LoRa for instance, where there are no duty cycle limits.

1 Like

See my other post for some details.

At an air time of 115ms, and keeping to the TTN limit, you could send 160 packets per day.

1 Like

If you followed the links that @Jeff-UK provided, you would have your answer:

https://avbentem.github.io/airtime-calculator/ttn/eu868/64

We are all volunteers here, please read the responses we give in detail.

1 Like

Have you even bothered to look at the airtime calculators in the links I provided? Answers there - adding in Nick’s helpful addition that you need to allow for the downlink window to open/close before even thinking of sending next message… we know its easy for folk - esp newbies - to just ask another question, and hopefully get some level of answer as kindly provided by Stuart, but we are all volunteer contributors here and you really should be taking a breath to follow the advice you have been given as well as spending a reasonable amount of time to learn the basics of the subject matter - not least to save yourself some further problems and possible jail time :wink: I know we live in a era of instant gratification but your journey into LoRaWAN and TTN will be far more effective and productive if you now commit a lttle time yourself…

1 Like

Okey, thank you all!

1 Like

And to answer your PM, why are you even interested in how to configure TTS to send messages at that rate, noting that @descartes says its not possible ?

1 Like

@davidpatrizi, PM’s are for personal or commercial in confidence comms. We try to keep the discussions public so those that use the search functions (on the forum or Google) can pick up the content and benefit from prior posts.

By keeping it public you also benefit from the wider community knowledge base.

And, as volunteers, generally we can’t possibly entertain one on one enquiries as a matter of course although that’s up to the individual member.

2 Likes

One thing I would suggest; is that when asking for help with a project, describe some details of what the project actually is.

Based on your intial description, its clear that what you have said you want to do is not feasible within the constraints of TTN.

However its possible that if the forum had an understanding of the actual project, someone might suggest an alternative strategy.

1 Like

Thank you for answer my questions, I’ve already solve this problem. The last thing, do you know what would be the best application (or any) to take the data of a vector and plot it? I have seen several (Ubidots, Cayenne…), but I would like to know if anyone has tried one. Thanks in advance!

1 Like

What was the solution, the information might help others with the same problem ?

1 Like

That was only adapt the message-to-message interval to the array period, by this way no measure data was lost between package and package.

1 Like

I stayed with your answer, and I have a question about the Lora 2.4ghz. I’ve been seeing that there would be no maximum duty cycle, as you said, would this mean that if my airtime was 150ms (to give an example), my packet to packet time in The Things Stack would also be my airtime (150 ms)? Thanks in advance.

What is this?

Airtime is the amount of time your device is transmitting which on TTN the FUP says a maximum of 30 seconds per day.

You may wish to research the number of 2.4GHz gateways that are deployed on TTN, price/availability of them and price/availability of radios for end devices.

If you wish to take advantage of the “no duty cycle” limit, you’d have to setup your own private LoRaWAN network.

As with all these wonderfully academic topics, we can’t really provide a useful answer without knowing what it is you are capturing data from, what your idea data rate is, how far apart the device & the gateway is likely to be, what the backhaul is likely to be etc etc. You don’t have to give any commercial in-confidence details, just enough to give you a better steer.

In the meanwhile, you’ll be fishing around looking for a solution when you may need to be trying a totally different pond.

1 Like

I am referring to the time at TTN between one package and the next. As I explained, my idea was to monitor a square signal, so I would need a lower time between sending packets than the one I have right now, which would be 7 seconds, otherwise I would lose a lot of data from this signal that I am looking to plot. That’s why I asked, @LoRaTracker told me that thanks to the Lora 2.4ghz I could reduce the time between one packet and next, and that’s what I would like to ask, how long could be the minimum time between sending one packet and the next, without losing data between packets with my MKRWAN 1300 sensor (Arduino). I hope you understand me, thank you.

True there is no duty cycle, but there would still be fair useage limits to keep to.

TTI have been doing some work on 2.4Ghz LoRaWAN, see here;

But I dont recall seeing any updates on here or details of whether there is a TTN implementation.

1 Like