Hi, Apologies if this is in the wrong category, Mods please feel free to move if so. My Lora knowledge is very small and hence I’m not sure where to start looking for an answer.
We have some Bluetooth sensors that we use to detect nearby devices and at the moment they transmit the data collected via WiFi back to GW’s. The data collected is device ID, Date, Time and Device ID. We use these in conjunction with trails we create to log interactions at each locations etc, the devices run our own app which also updates the end users on hints, locations on the trail etc.
As some of our locations can be quite rural we are looking into the possibility of using Lora to transmit the data back to our cloud server rather than deploying a WiFi base station with cellular connectivity.
The data we get doesn’t have to be real time as it not used until the following day but if hourly transmissions are possible that would be great.
I understand there is a limitation on how often / how much ?? data can be transmitted via Lora during a 24 hour period ?? sorry… trying to make the most of what I’ve been reading.
Is this correct, can someone advise a newbie on what those limits are. Do you think we could use Lora to transmit our data?. if its a non starter i’ll move on but if its possible happy to put the time into learning more. FYI, if we do go ahead we will host out own private Things Enterprise servers at AWS.
Its possible and can be done within limitations, there are projects that use people mobile phone wifi or BT MAC capture for e.g. people counters (search forum for PAX Counter), and where such data is either simply counted locally at the node & then binned or send (within limits) for onward processing. 2 big things to worry about are 1) depending on where in the world how you treat this data may be limited by privacy legislation (so e.g. PAX counters have had to adapt to law changes and general public privacy concerns over time). 2) the volume of data that is sent, and how often. TTN has a FUP limit of 30sec uplink airtime per node per day (there is an even stricter limit on downinks but that would not be used in your use case in general). Given you want to capture/report BT MACs for later use the volume of messages/users may be a constraint given you will need to uplink the MAC - dont use ASCII characters - use HEX/Binary messages as more efficient, you may need to fine a viable encoding scheme to compress the data some how to keep under message size and on air time limits. You shoudl also de-dupe the data to avoid resending same MAC info if lingering near a node such that it is captured more than once for same visit. Distance will also be a factor as message length will vary as shorter range (SF7) can be larger whilst keeping shorter on air time, but distant nodes will potentially use higher SFs - up to SF12, by which time the number of messages per hour, or maybe hours per message is greatly constrained and payload size is deminished. Suggest you look at the LoRa fundamentals Video by Johan Stokking on TTN YouTube channel and also read the LoRaWAN/TTI/TTN documentation (linked form website) and think hard on specifics & practicalities of use case before starting down a path that may prove limiting.
Thanks @Jeff-UK , that’s perfect and just what i needed. the 30 second upload rule is what we have to aim for then but knowing that gives us something to work to. Re you #1 note, I’m happy that’s covered as its a condition of using our app and we get authorisation from the end user to do so. In additional all MAC’s are masked so we never get to see them. I did look at the Pax Counter as an off the shelf app to start from but as it just gives numbers its no good to us as we need the MAC to track user usage and map out how many people can find / visit the waypoints alone the trail.
As we have the system already running we have the data so will get to work as the #1 priority to calculate a days worth of data size and look into options to streamline that and possibly compress it.
Just out of interest, as Lora ( presumably ) will be slower to transmit data than WiFi is there a guideline to use of time to transmit 1k of data, we can then use that as part of our calculations. Thanks.
The problem from privacy POV isn’t your users, as you say you get their agreement…the problem is the capture and use of all the others you acquire accidentally … you need to treat with kid gloves if not to end up wearing a nice pair of matching silver bracelets
Sorry, one more question, if we run a private server ( things enterprise ) are we still limited to the Fair Useage Policy as its not a public connection.
Bits or bytes?. Think on …max payload at SF12 is approx 50 bytes and that is a lot of air time… a GPS tracker will typically spit out 24-28bytesndepending on what extra info in payload…temp, Vbatt etc. and will be on air for aro 1.4-1.7 sec…a and you only get 30 for the day! Use case may require high GW density to give conf you can get SF for nodes down to SF7-9, for reasonable data throughput. We tend not to think in terms of how much data can we push through or how long to uplink a particular amount of data rather we think in terms of how many (few) messages are practical and how small can they be and also consider what happens in your application if messages are lost and unrecoverable… does application break?
No…FUP applies to TTS(CE) aka TTN, not private instance…but there legal DC limits still apply and the socially responsible consideration is to remember just ‘cause something is legal and permitted doesn’t mean you should push the limits. You are still using a precious sparse communal resource (RF spectrum), that may be congested and where your messages have to fight with other users. Further as you would be on LoRaWAN even if on private NS instance any receiving gw will have no way of knowing and on detecting a valid LoRa message preamble will start to allocate its limited resources to processing your message…only once data gets to the NS of foreign network (inc TTN) will the message be dropped…hence FUP should be considered a good citizen guide also…your excess may be killing another’s opportunity to use legitimately deployed gw resources… Sadly we see all too many private or single gw+NS deployments where the users/owners forget this consideration … and of course we are now seeing proliferation of e.g. Helium (for crypto mining vs genuine coverage), though fortunately that network isn’t seeing too much traffic as yet, so congestion generally not yet an issue
No, however LoRaWAN as used by TTN uses a frequency range which has legal limits (max 1% transmission). And as you are using long range transmission technology you need to play nice with other users if the same frequencies because others within 15k potentially receive your transmissions.
Unlike WiFi where in a few hundred meters no significant signal remains here transmissions span multiple kilometers.
You need to add up the number of bytes and a rough idea of how many of them will be - my gut feeling is that this could be a big NO as realistically in a rural / remote location you may be some distance and require more airtime with some bigger payloads.
You can do the math far faster than we can, so this bit is entirely in your hands.
And then there is the whole privacy issue with the Device IDs whatever they are.
We are volunteers, this will not influence our technical input.
is greatly constrained and payload size is deminished. Suggest you look at the LoRa fundamentals Video by Johan Stokking on TTN YouTube channel and also read the LoRaWAN/TTI/TTN documentation (linked form website) and think hard on specifics & practicalities of use case before starting down a path that may prove limiting.
… and of course we are now seeing proliferation of e.g. Helium (for crypto mining vs genuine coverage), though fortunately that network isn’t seeing too much traffic as yet, so congestion generally not yet an issue