I am working on a smart energy metering project for a charity tackling on energy poverty. I am an engineer jack of all trades dunce of many and LoRa is something I have been aware of but until now never tinkered with.
I am about to try and race through that learning curve but I was hoping someone more knowledgeable might point me in the right direction hardware/ strategy wise so I am less likely to spend time learning the nuances of a chip that I would never use.
I need to avoid LoRaWAN as the grid needs to keep operating with or without internet and it would be preferable to avoid the extra communication overhead, complexity and points of failure that it introduces
End Goal:
50-100 nodes transmitting ~64bits worth of data / second (cold be reduced to every 5 seconds and could be accumulated and sent every 10-20 seconds) to a central hub up to ~2Km away. I plan to have the meters mounted at the top of the transmission poles for tampering and signal reasons.
Deployment: pacific Island nations. in the future west Africa - Im aware that this might require a second version for frequency band reasons.
So far I am leaning towards:
SX1262 or SX127x Family + RP2040
But there are many choices and I am still at the learning point where the spec sheets are partially Chinese to me. Iâm not sure of the most important specs for my purposes. There are also many other manufacturers.
I know this isnât exactly the first time this particular wheel has been created. Sparkmeter.io being one example but we would like to avoid hardware vendor lock in and subscription fees that usually come with these systems not to mention the inability to change, develop or fix the design. I have seen plenty of open source projects in this area but most dont have the same cost restraints. In the end the chip will have to be integrated into the meters PCB. Chips are currently ~$3 on JLCPCB library so hopefully a ~$5 cost added to the PCB once peripherals are added (+antenna obviously)
The chip staying in production for the forseable future would also be a big plus.
So what would you recommend as a starting point hardware wise in 2024 to someone who has not had their eye on this market space?
any rabbit holes you would avoid?
any tips on the most important features for reliability and range would also be appreciated (Or if practically there isnât much difference?!)
Also if you have any learning resources you like, that would lead me to having a less than skin deep understanding that would be fantastic!
Note: wrt legal duty cycle (vs say TTN FUP) 'just cause you can, does not mean you should!". If every one started pumping data to the max legal limit the precious RF spectrum would quickly become usable, esp when dealing with a Long Range technology where signals go a long way taking spectrum from all and where dealing with many rapidly Txing devices.
The calculator includes LoRaWAN overhead, and whilst I recognse your desire:
The fact is that with anything other than a simple P2P implementation as a system scales you will need to consider (and add) how you manage and implement your own (proprietary) protocol and associated overhead. Fact is LoRaWAN has been carefully crafted and optimised over >10 years to handle just such a situation - why try to re-invent the wheel?
As for rabbit hole - the internet is littered with many and you also need to avoid bear traps, minefields and other hazards!
Whilst laudable aims and purpose you need to finsh research, step back and take good look at what you are trying to do and also ask - why? (e.g. are you really after near real time consumption info? Are you trying to monitor power condition? Why does aggregate data not work - most metering applications are sample per day, industrial and some high reaction/tariff switching consumer metering applications are maybe 1/2hr billing (probalbly then few times per day switching), more info would help but as state we are
âfocussed on TTN & TTI users (paid for by the later organisation) and utilising LoRaWAN - we dont do generic LoRa only, sorry!â
First of all this is a LoRaWAN network provider sponsored forum so if you donât want to use LoRaWAN you should look elsewhere.
Having said so, the RP modules and SX1261/2 combination should work. How long they will be available is crystal ball territory for us, you will need to consult the manufacturers for their plans.
While implementing your solution keep in mind you will need encryption for security, duplicate detection to avoid replay attacks, collision avoidance to make sure all transmissions reach the destination or allow for missing transmissions (which you should do anyway as there is no guaranteed delivery when using RF), oh and donât forget about implementing some kind of CRC to detect reception errors.
What Iâm saying is implementing this is far from trivial (but doable given sufficient time and effort). LoRaWAN handles most of this for you (and you could look at a local deployed network server like Chirpstack which is out of scope for this forum), but it wonât be a good match for the update frequency you want. Once every 5 minutes or once a day is more the frequency for LoRaWAN.
What are the consequences of project failure? Can the charity afford to commission a system from someone that not only doesnât know how to do it yet but thinks he can learn it at a pace - a mission impossible if you consider that you donât know what you donât know so ârace throughâ could be 6 days, 6 weeks or 6 months.
You are now in an unenviable position - should we assist someone with a charitable project that may not be able to delivery a robust solution in a timely fashion or should we assist someone because it is a charitable project?
Whereas the charity using a commercial offering knows that there is a fully formed solution with a reasonable likelihood of long term support.
Ahhh, sorry I thought as it was part of the LoRaWAN stack this community was the right place even if it did not share the whole stack. Point taken! and thank you for taking the time to reply that you have
I have done a reasonable amount of reading and with using multiple channels this should be able to stay within legal limits. That said, I agree 'just cause you can, does not mean you should!" I would not be considering this for somewhere like Europe as yes, this will create a large amount of LoRa noise and be pretty antisocial to the growing community around this tech. But this is going to get deployed in isolated island communities where mostly people donât have light bulbs so the odds of being a problem for others is extremely low. If it does, I will be exalted at the economic growth this would imply and personally go out there to replace the meters with standard GSM tech which I can now likely connect to the available mobile towers
Because of a lack of wisdom and naive belief that life is better when you have a simple wheel that is the right size for your bike and if it needs tweaking you donât have to wait 10 years with your fingers crossed that your wheel supplier will care enough to fix your issue on wheel2.0. There is alot that loRaWan forces you to implement like MTTQ broker ect⊠which then comes with a whole bunch of packages maintained by other people and pretty soon you end up on the update hamster wheel trying to keep everything compatible and secure
LoRaWAN Iâm sure is a neat implementation of whats necessary for a general purpose potentially sensitive data transfer that is exposed to the internet and is geared towards a certain use case. 64bits/second does become a problem when you slap LoRaWAN on top but not if you keep it simple, accept faulty data and use a few other tricks. like making the symbols for numbers go 0, 64, 2, 63, ect⊠or something like that so if the frequency shift is slightly miss measured it will be obvious
This is a good question, and I think a combination of yes and no. on one hand all we need are power usage ± 5 mins but also user usage profiles, the causes of load spikes, grid balancing ect⊠and unfortunatly there is the world of fund raising. the more granular our data the more solid our impact reports can be, the better we can fund to install further systems. Not a huge fan of that side of things, you get a lot of âcertified carbon creditâ stuff which to be honest i am quite dubious about at the best of times and mostly this is about improving people living standards and health but this is the game one has to play⊠so the ability to roughly differentiate the loads is useful in short
Thankyou for taking the time to reply. I realize now this probably wasnât the ideal place for this question, I should have thought it through better but this was just the first place I thought of when I was wondering where I would find people who would know there stuff on this topic to steer me straight
Look donât worry about charitable obligations, there are millions of causes we donât engage in every day, this is just one more that has no more urgency than the rest. you all have a particular skillset that is usful right now in this conversation, any help is positive, walking away only puts me in the same position I was before so no harm done )
I have some professional integrity⊠I am doing this work at a very low rate and trying to explore alternatives to the standard commercial approach. you pay for that support, quite dearly in my experience, not sure I want to deploy a system where the lights go out if no one pays the software subscription that month? this is not a profit driven model which is what usually supports that approach
This a a complex problem and there has been a lot of research, conversation, and thought into the implementation, reality on the ground and social impact of this project which I have left out because as you say this is a LoRaWAN forum and the document covering that stuff is nearing 100 pages
Thankyou Kersing, that is useful to hear
Not enough, hence my post. My plan is to test the limits of the tech and if it looks promising, bring on board someone who has the knowledge if needed
Thankyou again for your time and sorry if you feel I wasted yours
Your stated transmission requirements are pushing the limit and wonât scale. However in testing you might not discover this and only run into issues during deployment. Seriously consider scaling back the frequency of updates required or you will run into issues. And if you scale back the frequency LoRaWAN might very well be the well tested and battle proven solution to your problem. (Hint, there are some gateway vendors that embed the LoRaWAN Network Server on the gateway. Add a small computer and a switch and you have a standalone implementation that should solve the external dependencies. However as mentioned, not a topic for this forum)
Should you need (paid for) consulting, there are a number of knowledgeable professionals on this forum that can help you.
We are used to getting the most out of the payload sizes and of how data varies across sensors.
TTN is free for such applications. For those that have read the docs and taken baby steps to consolidate their learning the community is here to help.
The volunteers answering here are giving back and are happy to help. Some also do pro-bono projects.
Not so special that there are already power metering & monitoring solutions using LoRaWAN in Guatemala.
The linked calculator above rather removes the need for you to test the limits - something you canât do on TTN because of the FUP.
You are rushing, making early choices & assumptions - read the Learn section before you do anything else to fill in the basics and perhaps crunch some numbers using the calculator.
Yeah, I agree that the stated requirements will likely cause problems. Most likely they will need to be scaled back. That can be seen if i just use the standard calculator. The bit rate could be dropped drastically if the functionality of grid monitoring, system design data and maintenance is left in the pipe dream draw. Which if necessary, they will be. If they can be kept, they would add a lot of value though, hence exploring this as an alternative.
yep I know and stated from the outset, this isnt an original problem. LoRaWAN and possibly even TTN (although not for offline operation) can solve the problem of collecting meter readings. meter readings however isnât the only problem to be solved in microgrids, Iâm hoping to get a few birds with the same stone.
I am very happy that communities, people and projects like this exist.
I did take a few wobbling toddler stumbles before i posted believe it or not. I understand the TTN use limits and could see that the technical requirements of this project would be an abuse of this free resource, hence not for one second suggesting to use it in this way. I was trying to find another way that didnât compromise the technical goal or LoRaWAN servers. A local offline node to node custom network with timed message transmission based on device number did not seem too far fetched an idea. A lot of the libraries and ground work is already there, some data formatting, check sums maybe encryption doesnt feel so intimidating to me. But then I am more familiar with embedded systems than networking and software so this could very well be a case of hammers seeing nails
Well part of the limits are how minimally can I package the data for the required resolution and how much overhead is there in things like the preamble and waiting for channel to be clear. what sort of spread factor will I need to go up to for a given range/ obstruction ect⊠Its not obvious to me how to get the calculator to consider these factors and seems like first hand tinkering might be necessary to get a feel
Huh very interesting⊠I remember reading something about that but I didnât quite get the implication at the time
Thankyou, I may well peruse this, If you donât mind I might PM you about it after a bit more research
That is good to hear. Got to love people sometimes
I would certainly advise to get some hands on experience. Datasheets and the learn section can only teach you so much, it canât beat hard gained real life experience.
Start out with two devices doing point to point, one logging the signal strength, received data etc and the other one sending gps data and take that second one for a walk. Then plot the results on google maps and check if it matches your expectations. Try with different spreading factors to get a feel for what might work in the target environment.
We do live in isolated communities far for EU, you are causing as much a problem in the isolated communities were we live as in the EU. By no means do we have the right to missuses any recourse in any part of the world.
Clearly key to you project is a practical test of what data rates you get in a typical situation.
You say distances are up to 2km and in some environments you could end up needing to use long range (slow) LoRa settings. In some other environments you might be able to use short range (fast) LoRa settings.
The difference in air time between the typical slow LoRa settings and the fast ones is 22:1, so major differences in air time and legal duty cycle restrictions.
hmmm Most people use a blink sketch. I like the idea of GPS, real world confirmable and a better real life case of changing data and uncertainty. Thankyou for the suggestion, I will use that
Right⊠well you are typing that from your electrically powered smart device connected to the internet and you have enough afluance to be messing around with LoRa, I doubt you are living on a dollar a day and cooking with animal dung. Correct me if I am wrong but I donât think you need to worry about this coming anywhere near you. I will be making every effort to stay within reasonable bounds and keep the frequency usable just in-case the signal reaches some near by community who want to measure the wind speed without going outside, but it does not seem unreasonable to use up more bandwidth than the average hobbyist. Location and context are a thing, people who pretend otherwise tend to cause more harm than good. This is why every community develops itâs own communal resource rules, there is no one rule for all
Yes, This is what I need to explore, in real world situations what data rates are reasonable without clogging up the airways at what distances and how much of effect do different obstacles have, tree vs building ect⊠perhaps further out meters will have to send a reduced data like one 32 bit int every 10 mins and only meters with a fast connection (or a couple of well placed ones) give granular data, apply some creative data extrapolation from there. several hubs is another option⊠Other systems I have seen use mesh networks with messages being repeated but that to me seems like it would scale terribly with close proximity nodes and add up to a huge amount of total airtime per messge
I wont feel like I know anything until I have gone through this process.
Thanks again for the advice. and taking the time even though this wasnt the correct place to post
So I am taking away SX126X and SX127X are still good and relevant in 2024, both worth testing
Explore required spread factors, bandwidth and antenna setups using a gps module
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.
