There are plenty of professional users on the forum and LoRaWAN is being used on ships for asset tracking and maintenance prediction, those ships might get close to your isolated community. (Close in Lora terms might be tens of miles)
In Africa LoRaWAN is used in wildlife protection schemes, so very much out in the wild where people might cook on animal dung.
So keep in mind, even if the members of the community living remotely themselves don’t use Lora it doesn’t mean it can’t be interfering with other users.
The SX126x is newer and uses less energy. It would be the better choice.
I am aware of remote Polynesian & Caribbean islands, and yes
Where both Lora (vanilla and proprietary implementations), and LoRaWAN (and even space base services!) are deployed NOW, not even in the future for equally critical (more so?) applications where they have sparce water (shipped by tankers/in tanks as not enough local rainfall or natural storage) or need to monitor critical pharma products and food stuffs and so anyone with a presumptive, and dare I say blaze, attitude to their own deployments being the only ones or only ones of importance run real risk of disrupting other users. As suggested as an absolute minimum follow legal requirements and where possible decimate actual usage data rates. (If 1% allowed assume 0.1%, if 0.1% allowed assume 0.01% and you likely won’t go wrong )
This is the most publicized use case, we do use it for other critical case as well
Monitoring several water revivors and supply systems in rural area, that are critical to communities that live on the bread line. We have two choices, ether we do it manually or use LoRaWAN, if we waist air time we will need to go back to manually.
You are right, sorry. I was beginning to get a little prickled
Yes, sorry perhaps I should have been a little more clear that I have no intention of breaking the legal bounds. my original statement was a rough goal that I would work back from. If I took Europe for an example and the top end of my original statement and use the LoRaWAN protocol, 64 bits every second then yes that would be more than a 1% duty cycle. I have no intention of doing that. 64 bits can only be sent at DR5 every 2 seconds at 1% Duty if they are clumped together into 64 byte packets. This is assuming that band P is left alone which allows for up to 10% and is usually reserved for downlinks which i’m not sure how that applies in the context of node to node. BUT I did state 1-5 seconds and approximately 64 bits not precisely So the idea is well within legal scope, but i should perhaps have assumed I wouldnt get the benefit of the doubt. I would also add that I would reduce the requirements as needed to keep things legal and even further to keep things fair
BUT the “legal scope” isn’t really the question here. The real question here is more of a “fair use” question which is undefined if one isn’t going to use the TTN network. Now the fair part is a valid question which does actually bring me to some LoRaWAN specific questions on thoughts about how to reduce the impacts on others of heavier LoRa use:
having 90 nodes using near to 100% of the air time on one channel would presumably be a terrible idea for anyone else around even if it was legal at Duty < 1% per node. But where does it become too much traffic for other LoRaWAN devices to operate? 20 - 30 -50%? I know there wont be a hard answer without specific context but if anyone has any real world experience on this I would be interested to hear it
I will have control over the time intervals, would evenly spread messages be less or more disruptive than several seconds of solid communications followed by silence in case someone else wants to send a message with long dwell times. I assume random would be worse case and become inefficient with collisions
credit to LoRa — LoRa documentation
three of the channels bands chosen are fixed and presumably others tend continue the frequency spacing pattern with 200Khz gaps. now would it be a terrible idea (if the WAN part was not used in the project) to choose frequency bands in between ie. 867.2, 867.4 to avoid overlap with what presumably will be the most common real estate for LoRa devices. OR would that actually be worse because going in the gap would interfere with both the neighboring bands? would reducing the bandwidth help that?
If I have come across that way it was not intentional. The comments on this thread have been from a singular perspective which is pushing a global policy on what is a commons for each community and how those communities should have access to their own commons. what technology these people get access to is being decided by… well… us. Their voice is notably absent from the conversation and I don’t think that is trivial
well put scheepers
I do care quite a lot actually about effecting others. Otherwise i would have used the calculator, concluded I could stay in legal limits and cracked on, but that didn’t feel very enlightened so I stared tying to figure out ways to reduce the traffic and keep space for others, my first thought was to try and cut the 12+ bytes of overhead added the WAN but that i didn’t really need. I have had many thoughts since. Sorry If i seemed stubborn but this is quite an important cause to me and the reasoning has to be sound not based on assumptions and how its done elsewhere. Im hoping this can be achieved without anyone’s toes getting stood on, I’m going to explore what a system that does not cross that line would look like/ be capable of
Your question should be how often do I need to do a measurement, often do the variables change?
How often do I need to update the central database?
What processing can I do on the local node?
If something critical occurs how fast do I need to know this?
How can I encode the message to take up less air time?
(These are some of the questions I will as myself first)
LoRa or LoRaWAN are about how little air time/ battery can I use.
Given some of the observations made on LoRa/LW, channels, data rates etc, maybe you would benefit from sharing the data sensing & bit rate calculations to run it past some experienced sanity filters. No point getting in to the weeds with LoRa/LW if it transpires it just won’t fit anyway.
If you aren’t using LoRaWAN you could well use that band. And because in LoRaWAN the gateway transmissions use an inverted channel interference should be minimal as long as you don’t start using inverted transmissions. Even in that band keeping usage well below 1% would be advisable to avoid collisions.
There are several studies performed by researchers out on the net. However those are largely based on randomized timing. In general frequencies used over 20% (iirc) become unusable because of collisions.
The LoRaWAN frequencies are chosen to have no overlap given the bandwidth used. Any frequency in between will overlap with two LoRaWAN channels.
Reducing the bandwidth will increase your time on air. Going the other way (increase bandwidth) would reduce it at the cost of colliding with more LoRaWAN channels. I’m not sure anyone actually investigated the impact of such a choice on LoRaWAN networks.
Yes those were my first questions and ones I have been working on, but the LoRaWAN website did not seem like the appropriate place for that conversation as the LoRaWAN site doesn’t even extend to LoRa (I shouldn’t technically be taking up the TTN forum airspace as it is, again very grateful to the time I have been given) grid monitoring, load profiles, bit mapping ect… would be even more of a stretch
This is the TTN forum hosted by TTI - it may be one of the important places to discuss LW, but it’s not THE LoRaWAN website - that could have been the Semtech forum - not closed - or the LoRaWAN Alliance which has no forum …
If it is related to LoRaWAN in general, that’s all fine - that includes the in’s & out’s of applications, payloads, related techniques, power, RF etc.
What’s not fine is questions only about point to point OR related to other LoRaWAN offerings.
Happily and thanks
Each node will be measuring the power going to 5 separate house holds. That requires 1 voltage measurement and 5 separate current measurements. The measurements will be done with 10bit resolution and the power consumed will be calculated locally on the node at high frequency so that transience can be properly captured. Occasionally that absolute power consumed value in Wh will be transmitted. 16 bits ~3min intervals is my current thinking, justified bellow. The Current and voltage will be transmitted at 8 bit by using mapping to keep the resolution only where it is needed
on the face of it that would need:
48 bits + 8-9 for device ID as frequent as possible without breaking the airwaves. (lets say 5-10 seconds for now. This data can be clumped and sent less frequently in larger data packets to reduce the effect of overhead from preamble ect.
16 bit every 3 minute for Wh consumption.
the less frequent the Wh updates, the longer someone can draw free power and the more they could spoof the system with small payments which requires higher minimum payments and for obvious reasons, that needs to be as low as possible. the other way would be to transmit and store the balance details on the meter themselves but 1. I would rather not broadcast balance info and 2. I would rather a system that fails closed if communications break down, systems have errors ect… a grid that looses power if something happens to an antenna on a tropical island does not seem like a great plan. once every 3 minutes seemed to be a good compromise. Wh could be 16 bit
The 10 bit measurements I am going to reduce to 8 bit by mapping so as only to keep the resolution at the low end where needed on the Amps and at the high end for voltage. It is hard to get into the justification of frequency as this data will be used primarily for diagnosing problems remotely. I have been on the end of supporting complex systems before and one problem is, you don’t know what the problem will be when you are designing the thing and therefore data is one of those things you cant have too much of when you are trying to muddle through what actually began a sequence of events, too many times I have been staring at 30+ data points all landing on the same exact time interval, but which was the culprit? then you end up spending weeks trying to recreate the intermittent problem. That said, this will have to be reduced until there is enough airspace for other LoRa/LW devices to function
Now that is a cool concept. I tried googling “lora gateway inverted channel” to dig deeper but am only getting generic gateway information posts. Any tips on what to search to find out more? Is this switching to down chirps?
Great rule of thumb thanks. Ill of course dig deeper on this as well. I am interested if this could be much higher if say 15% of that traffic was “yielding” ie, did not attempt to re transmit if corrupted or channel busy and also regimented to ensure at least no internal collisions.
On this topic, I suspect the only way is to test but that is not possible without making a lot of noise by design. Do you think it would be possible to create a shielded test environment perhaps with an earthed metal box? that way I could break the law in an ethical way during testing, using one node to simulate many and monitor the effects on a LoRaWAN node and gateway also placed in the box. Or would that be too leaky/ expensive to gain appropriate shielding (i’m lacking a feel for how good LoRa is at penetrating)
Yes, That idea does pivot on LoRaWAN tending to use 125kHz and not 250 kHz… I haven’t read the nitty gritty of LW yet, I know it self adjusts Spreading Factor (and bandwidth?). Would it be smart enough to auto adjust away from 250kHz if it had better connection at 125kHz? Just trying to establish if the theory has any legs
This is way way in to the weeds of LoRaWAN and is totally transparent to the user and probably 95% of implementers wouldn’t know it happens. The Semtech website will have papers on this, but along with your ideas about changing the bandwidth and trying to create an RF test environment are a bit early in the knowledge acquisition process - like figuring out the best compounds of rubber to make your tyres on your unicycle when you have still yet to ride without stabilisers. The end effect is you don’t ever get to ride a decent bike because you’re too bogged down in the details.
Given that there is currently a roll out of 150,000 meters in a central part of the UK using LoRaWAN as an example, you can be assured that almost all the parts are there to move data and from reading your prior post I suspect that some refinement of the payload will go along way to make it be a better fit for off the shelf technology which protects such a project as someone else can pick it up if you are doing something else.
The majority of power monitoring accumulates usage data in to total consumption since last “reset” so that if any packets are lost, the overall use is still known even if how it was used over a period of time may not be apparent.
The mechanics of messing with mains power to steal small chunks - like having a single light on but then bypassing the meter for the duration of boiling some water - are way way beyond the vast majority of people and are stupid easy to detect. As well as running a meter upstream of the distribution point and see how the totals compare, the profiling of a normal household is easy to compare to to one that is more erratic and then some actions could be taken, which may well include more frequent uplinks for that meter. Power use tends to be stepped - a household runs at say 500W background use, steps up to 3kW while using a kettle (500+2500) and then back to 500W. In these data scenarios I can send a new value with a start time, using the difference between times & power to make the numbers smaller. Unless a five year old is flicking a switch on & off, most of the time the use is pretty stable.
If you read my answer to another typical application issue here you will see that you can also code in overlapping data or a replay. In this situation you could store a lot of instantaneous readings on the device that can be recalled if an anomaly is detected. However I wonder where this paranoia comes from - providing power to a community that may be withdrawn if they collectively allow some of their members to steal it should suffice rather than have a massively over engineered / complicated solution put in place. If a simple system is deployed and the meters at the branches to the spurs identify any misuse, it then becomes worth extending the system to capture such data.
Haha yes, you are tempting me to dig my old unicycle out.Tyre’s are probably bust due to the cheap rubber though. I agree with your statement but it is such an apt metaphor that I might add that although there is skill transfer from bi to uni, if the tool for the job you really need is a unicycle then that is actually the cheaper and faster place to start, not to mention the unlearning that often has to happen (Having said that, it did take a long time to regrow that part of my chin…). have you seen "Smarter every day"s videos on learning to ride an inverted bike? entertainingly at the end of it all he lost the ability to ride a normal bike
Jokes aside, the reason I am getting so ahead of my self is because I am in the field now but will be in my lab two weeks from now for a two month block. Im ordering the bits I need in a possibly vain attempt to avoid halting the learning curve while I wait for a slow boat from china to deliver a bit I need (and because I work more efficiently when I have plans to work towards and test)
Yeah that was my strategy too. the current and voltage measurements are about catching the shape for diagnosis ect… but it is okay for them to fall through. then at a much slower frequency report a shape agnostic aggregate like Wh
Totally agree with this, if there is a standard way with none breaking compromises then I will take it. LoRaWAN may well be the way to go yet although there is no way around the existence of many nodes in one place and I do wonder, even if it fits it would be worth exploring ways to negate the effect on others. I suspect this predicament is not unique where there is a desire for a single user to use many LoRa nodes without the need to strictly follow LW protocol. It might open up opportunists to step aside and leave more room for future LW
Yes, I had been thinking about overlapping data packets with time intervals, triggered by change events. Encouraginf to know its worked well elsewhere. I was thinking about combing this with some transition types or “shapes” eg linear rise, step change, exponential curve ect… to catch stuff like slow ramps from charging. That or deltas with fixed time intervals. It is hard to gauge which would result in less bits. I was mulling over how this would respond to stuff like induction cookers which will look very much like a 5 year old with a switch. they use crude on off control with 1/2 to 5 second periods due to the difficulties of controlling a ZVS without messing with the resonant functionality (yes induction cookers will hopefully be present but don’t ask, that is a whole other thing).
You know the area well! yes although unless in America the background is more like 100-200. at least in the UK solar installs I have done and have my fingers in the data. And I expect where this system is deployed (by the research on similar projects too) the load for most houses will be 0-50W nearly all the time, only some households will have a large load occasionally plugged in. so resolving low levels and slight changes becomes more important than normal. Real data to test this against is thin on the ground sadly. I am in the process of trying to get some but most the people who have access to it are the people who also want to sell me their system, I haven’t quite worked up to pretending to be a potential customer yet. was shown a demo once but fake data
Agreed, It is probably better to work backwards and add on the extra data if needed. The original of more frequent messages is the simpler solution though compared to abuse detection and data frequency adjustments. I also will likely attach the relay open or close command to this Wh message which means the intervals will also increase the amount of time it takes for the power to come back on after the balance has been increased from 0
Most of the good stuff is available in the EU or US quite readily - in fact if you have to get it from a long distance you run the risk of support issues. But why buy questionable stuff from China - the IoT industry has lots and lots and lots of stuff from mainstream distributors that is fully documented.
Apart from the reinvention of the wheel and ignoring the combined efforts of years of experience in the development of a wide area low power long range radio network, how would it impact others where there is only just power being provided?
Easy to detect / infer, stupid easy to aggregate.
I could have added or removed zeros, I’ve no idea what loads would be in use on your desert island.
You really really need to do two things:
Go up to a house, see what they’ve got, ask to look at the labels, write them down - figure out some very rough usage.
Build something, anything, that measures mains power and transmits the data, even if only 100m.
True, (Im UK, ahh the days of EU single market… still pretty good though!) and I would always buy organic local PCBs if I can. Just assuming I can get the bits I need in a week often leads to me paying over the odds for something. Plus I am excited, LoRa is a cool tool to add to ones belt! you must agree to that otherwise you wouldn’t be on this forum
well this was a point I was trying to make earlier to great derision, some of which valid. ultimately there is going to be a trade off between minimising air time and development time, developing ever more complicated data compaction methods with more complicated code signal processing (and therefore likely less stable code) running on distributed nodes. Finding a space where airtime is less impactful might allow for a happier medium to be struck. The alterations to standard might be very minor like selecting a different frequency. Anyway, you are right in that this is very far ahead, there are alot of problems to solve in-between
Way ahead of you on 1. we have census data, have talked to locals, have talked to more affluent cultural parallels, looked at similar projects etc… . I have a good idea of what to expect, depressingly little for the first few years sadly, but it grows with time and beginning that process is important in and of it’s self.
yep as soon as I physically can. I have some unwitting test subjects lined up back home I plan to install V0 on for stress testing
Thanks for all the advice, If I receive any more I should probably be paying someone. If it is of interest I’ll post back on here once there is actual progress, or maybe a new thread if there is a more “show and tell” topic. Or for help when nothing works I am talking to the charity about making the meter open source
We don’t do alterations to the standard nor do we feel the need to stress test a solution that is designed to support 10’s of thousands of devices with two or three gateways.
But we particularly don’t plan either until we’ve run LW for a year or so to know the basics properly.
The ratio of “my special system” and “project failure” keeps me in business, think A Team, when it’s all gone wrong, who do you call?
right… so you make a circuit + microcotroller code with + receiver stack + database + remote access, get it all to work on your desk for five minutes, then order a few hundred to be installed in the wilds when you might not even be present? you must be close to an all knowing god If you don’t mind, this mere mortal might stick to his primitive ways
So you do stress test and the presumably make a system very close to what you were running. always be an expert first is not a solution. don’t do something unless you have been doing it for a year? bit of a catch 22 there. I’m not arrogant, I’ll be bringing people on board as needed. but you shouldn’t mange a project you don’t understand. a quirk of mine
Any use of the phrase “stress test” on TTN gets the response of “please don’t” - it implies lots of unnecessary activity on a system provided for community applications that is graciously funded by TTI - they can’t just whack another cluster on because someone wants to find out if the global community of LW has been hallucinating.
Pretty much, as that’s what the clients pay me to do. Although for the last minute of the five I’d probably decide what font to use on the dashboard.
For varying values of stress test, just not one relating to TTN’s infrastructure:
If I design a PCB with an MCU and a radio on it, something I am in the habit of doing, then I run several for a while on a variety of cycles with varying power sources at different ranges. This checks for the reliability of the device. Banging away at uplinks doesn’t really prove much and can lead to power issues as you push the battery harder than it would be in real life.
If I buy a ready made board that has been around for a while, there is usually a body of evidence that shows it will work - or a raft of posts across the internet telling you how bad it is, or in reality, how inexperienced the user was. So overall, no stress test needed. Part of what I offer rather requires me to own one of pretty much every mainstream LW capable board - mostly I have two or more.
I have stress tested simultaneous joins a few times by accident - 24 devices turned on simultaneously with an issue in the ST random number implementation which meant they all tried to join at the same time. But for normal uplinks-every-15-minutes I’d need to get 7201 devices together to see what happens in person. I’m happy to use maths to figure that out.
The item you quoted referred to some idea you have about changing the frequency with an implication of your own customisations for reasons not at all clear. Unless you’ve used LW for a while, you won’t be able to make adjustments because you won’t know it well enough to know how it will benefit or impact the system.
Fundamentally LW, an accredited specification, handles thousands of devices and has many many products available that you can just add your sensor readings & construct your optimised payload. Just getting there will be an adventure, so talking about changing from the standard and stress testing is premature & for TTN, more than very worrying.
)
I am talking to the charity about making the meter open source
If you don’t mind, this mere mortal might stick to his primitive ways