Hi, I’m using a node that produces 7 bytes every 2 seconds, concatenating many measurements and
send them every minute will be 1 packet of 217 byte/min, According to the TTN air time calculator, I’m
Ok with the 1% Duty cycle restriction but I’m not ok with the TTN access policy, (using SF7-125KHz).
**Does that means generally I can send my LoRaWAN packet using LoRaWAN technology but not
TTN web-server? and if I want to send my packet through TTN what should I consider?**
This is pushing the limits of LoRaWAN - particularly as you would need the device(s) to be close to the gateway to ensure they run at DR7.
This does mean you can, in theory, run this as a private network, but no, you can’t use TTN to do it. You could use a paid TTI server or you could setup you own LoRaWAN server.
However I’d look first to checking other options with the core design. What is the data, can you send deltas (changes) or binary flags, how compressible is the payload, either. as a whole or for each 7 byte segment, either using a known scheme or a custom one?
Or as you have to use a shorter range, would the device be close enough to use a 2,4GHz ISM radio like the NRF24L01
If you can give us more detail, we may be able to suggest a solution rather than just say that you can’t use TTN for this.
Thank you for your reply, I’m studying the possibility of using LoRaWAN to link an air quality station.
The Station contains PM sensors (PM10 & PM2.5) which produce 20bits/s and DHT11 which
produces 2 bytes every 2 seconds, a profile of all the data contained in the packet is:
ID (2-bytes),
PM2.5:(2-bytes),
PM10:(2-bytes),
TEMP:(1-byte),
HUM:(1-byte),
RTC:(4-byte)
I made the assumption of the 217 bytes only based on the PM+DHT11 sensors (without other data)
as a starting point for the analysis to find out the possibility, if LoRaWAN bit-Rate capable to handle
those data and what is its maximum capability.
the maximum distance for a node would be around 600 meters from the Gateway, I think my situation
is only suitable with DR5 (maybe DR6 also).
Suggestions for using other technologies are also welcome.
And
I would be very very surprised if the air quality significantly changes every 2 seconds. There will be different values due to the way the sensors work, but in general you should be averaging a number of measurements any way and possibly even ignore outliers.
My station using PM2.5 and PM10 sensors and BME280 for humidity, temperature and air pressure sends one averaged data sample every 5 minutes (and sleeps4 1/2 minute in between taking samples) at SF7 which works fine, even for the government agency collecting data from amateur observers.
ID is probably redundant - LoRaWAN payload meta-data includes the device id & a counter, RTC is almost certainly redundant, it grabs the time every 2 sends - you can make a reasonable assumption that your sample period is working and the network will timestamp the uplink for you.
As @kersing says, 2 second intervals is pretty meaningless for something like an air mass, so with averaging & smoothing, you can reduce your payload & transmission cycle a significant amount. And as some of the figures are reasonably unlikely to change over the space of say, samples every 1 minute, you can use flags to indicate a repetition of data.
For instance. Header byte as bits, each bit corresponds to a sensor, so you can have 8 sensors. If the bit is 1, it means it’s changed and will appear in the stream. If it’s 0, it hasn’t changed so won’t be in the following stream. So at worst, we add one byte to each reading set but at best, the one byte of 0 tells us that nothing has changed from the last reading.
You can also bit-pack the two PM sensors in to three bytes.
Thank you for that information, I forget to mention that the system is designed with considering to put a GPS in the future and there will be movable nodes(attached to some bus) I’m not sure if LoRaWAN can support that, but probably this is the reason for extracting the sensor’s data per seconds.
Bus as in vehicle transport?
Even for a vehicle, every few seconds is still a bit over the top, pointless when stationary and subject to all sorts of metrological conditions (like the wind) and if the vehicle is moving you’ll be limited on the data rate due to path fade issues.
Log data to an SD Card, transmit summary & alarm data when stationary and this does have potential.
Even when moving the measurements will not vary much from sample to sample. However as a result of moving you will run into situations where DR5 won’t work and lower data rates will get you into issues not only with the TTN fair access policy but also with the legal limits.
Logging data in some way and uploading in bulk using something like WiFi or 3G sounds like a better solution.
Thank you so much for those suggestions.