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
Noted, thanks for the clarification 
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
Thank you, these are good insights
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.