How many nodes can send packets to a dragino gateway at same time?

Hello all,
My question may be very basic. I have a single channel Dragino gateway. I need to send GPS data from a LoRa end device(TTGO esp32) to the gateway. How many end devices can send their data at same time? How can I calculate it? Suppose one complete packet from a single end node has 64 bits. If I use an 8 channel gateway how this going to improve. I am planning to have at-least 200 GPS end devices, which all will be sending the Location Information in every 20 seconds. How can I handle this situation.? Please help

Thanks in advance

melvin

Not even remotely, with any sort of gateway.

What you are describing is simply not a lora application, nevermind a lorawan or TTN one.

You’ll have to find some other sort of solution elsewhere.

1 Like

You may need to reconsider your plans, if you send data that often then you will be breaking the TTN fair access limit of 30 seconds air time per day per device and possibley the legal limit on duty cycle too.

TTN is not really a suitable system for sending such very regular updates.

1 Like

> I have a single channel Dragino gateway. I need to send GPS data from a LoRa end device(TTGO esp32) to the gateway. How many end devices can send their data at same time?

All 200+ could send their data at once, but I suspect you meant how many devices can send at the same time and the packet is reliably received, the answer there is one.

> Suppose one complete packet from a single end node has 64 bits.

A typical GPS location packet will be circa 24 bytes, or 192 bits.

> If I use an 8 channel gateway how this going to improve

In theory you can recieve packets from 8 trackers at once.

> How can I calculate it?

The LoRa Calculator (a software tool provided by Semtech) will calculate the on-air time of a packet for you, that is the starting point.

My question may be very basic. I have a single channel Dragino LoRa phy layer to SPI/I2C/IP/USB/etc. “< delete as appropriate >” bridging device.

There FTFY! :smiling_imp:

Irrespective of end node duty cycle etc. (Clearly a fail as well called out above) IMHO such GW’s should not be encouraged on the network as they confuse and cause problems for other users in range, degrade network performance/cause ‘failures’, and can cost real money to diagnose and fix/avoid/mitigate presence of. There is simply no excuse to use single (or even dual) channel devices when there are now so many ‘micro’ GWs available at relatively low cost that are LoRaWAN compliant (single/dual channel devices NC by definition) inc the TTN/TTI TTIG, and micro GW’s from others such as Dragino (if you want to stay with them) e.g. LPS8 LPS8 Indoor LoRaWAN Gateway , RAK RAK7258 - micro indoor gateway, etc. and many more coming every month e.g. posted to forum just today Product Announcements - #194 by monicalaw07

/Rant off :wink:

Hi @melvinpmanuel, as per the other posts, you cannot do this with TTN and you cannot do this with LoRaWAN in many radio jusrisdictions.

You will need to use:

  • Plain LoRa (no …WAN, no TTN).
  • Use a frequency band where you can use polite-access/listen-before-talk (LBT) rather than using a duty cycle limited (e.g. 1% in EU) frequency band. Configure the end-devices (transmitters) to use LBT.
  • Configure the end-devices (transmitters) and the hub (receiver) to use 125KHz and SF7.
  • Configure the end-devices to randomise when they send so they don’t all transmit at the same time.
  • The hub (receiver) tracking software will need to be tolerant to loss.

A custom LoRa transmit of say 12 bytes (4 bytes header plus the 64 bits you require) at SF7 will require about 50ms.

200 devices TXing for 50ms is 10 secs of radio airtime every 20 seconds of clock time.

My finger in the air estimate is that you will lose about 50% of the traffic.

Lotsa luck.

1 Like

This is probably not going to be a fit for LoRa at all.

But if one were going to try it, it would probably make more sense to get a bunch of node-class radios that could receive at SF7 (or even SF5) at 500 KHz bandwidth, and use that rather than a traditional concentrator card which can’t support multiple wide/fast channels.

Or more use a traditional concentrator card to let nodes join up and be told about where the fast channels are currently located in time and frequency.

I suspect the asker is going to have to do a lot of learning about non-LoRa technologies to realistically solve their problem.

Thank you all for your comments and advice. My application is to develop a child tracker using LoRa modules for a school. So, as you mentioned, I don’t really depend on TTN. I have to create a private network using my end devices and gateways. So as per the discussions, If I can use 8 channel gateway(as a receiver at school office), and by randomizing the transmission period I can hardly manage the situation right? Do you have any other thoughts on implementing this?

Thanks for your time and support
Melvin

Thank you very much Tim for your advice. The hub(receiver) you mentioned can be a LoRa gateway right? Or do you have any other device as a hub?
Another question is that, can I use LBT for LoRa transmission ?

Thanks in advance

Melvin

And this is a support forum for TTN applications.

Ignoring the technology, the consequences for an application that is tracking children, which is relied on as a ‘child tracker’ and then fails (for whatever reason) could be very serious indeed.

A job perhaps for a very experienced, and well insured, electronics design engineer with particular knowledge of LoRa and GPS ?

Hi @melvinpmanuel, I would use a normal device module for this, not a concentrator card. I built a much smaller (5 devices, each transmitting once per 2 minutes) system like your plan as an experiment for possible industrial use.

I used RAK811 wisnodes in P2P mode for the transmitting devices and for the receiving hub device. I used 869.85MHz in EU as this is not an EU LoRaWAN channel but is available in the EU for LBT use.

On the hub/receiver RAK811 in P2P mode you simply run the at+rxc=1 command and you will get a running list of all the transmitted packets.

The system worked very well. Your problem is not tech but scale. You need to reduce the number of devices or reduce the rate of TX.

Now I think that the moderators should close this topic as this is a LoRaWAN TTN forum.