Once you have found the great idea of the year and you want to start implementing your first prototype it is time to choose the right technology. Some would say you should not choose at this step and implement both at end but in my point of view it looks like and economical mistake to do this way. Prototype is to demonstrate and final product. It can request another technology, for sure. But in my point of view the best is to take the right one at the beginning. For most LoRa and Sigfox are both equivalent or for some others one is over the other one, best depends who you ask. In my point of view, if I consider my 2-3 years sigfox experience and my starting experience on LoRa with 1 year background research on it, there is no magic answer. Context of your idea is the keypoint then you have some technical elements to take into account to finalize your decision.
This post will try to illustrate where each of the technology is the best and give you some decision keypoints.
Object localization and mobility
Sound like one of the most important parameter to consider : where your object will be deployed. In case your object is subject to be deployed in many countries, in case your object is supposed to be in mobility and go outside the big cities, in case your object is supposed to move more than 60 km around, you need to have a public network to support your communications.
As of today, the only one, really existing network for IoT is owned by SigFox and its affiliated. LoRa exists in some cities in test, will be deployed in France in 17 cities according to Orange at SiDo 2016, but the list is really short, the planning is not yet given and the commercial conditions still unknown. That said, I do not trust public announcement and looking for facts. LoRa operators in France have all rejected in different way my requests for experiment so I assume nothing is really dry for being used. What is valid for France sounds not so different in other countries.
Sigfox is far away from competitors having a nice European network coming in the USA, Australia and many more soon when the LoRa roaming standard is not yet published and implemented in the network stack.
By-the-way, you can tell me things are going to change during time you need to develop your product and this will be true… or not. Announcement has been made more than a year ago and the deployment is still pending. I do not know how many time you will need to have a global coverage working seamless between operators. Considering LTE-M arriving everywhere in the world in the next 1-3 year, I do not see why operators should accelerate LoRa. LTE-M will have expensive modem for a couple of year but price will decrease and as certifications are much more simple on LTE-M than on LoRa/SigFox you will save time & money that way.
Half Public Network
You can have object to deploy in many places, when these objects are not moving you can take benefit of a public network. This public network can be extended fo your own usage by adding gateways / basestations rented from the public operators. This is true for SigFox and LoRa ; It seems, according to the different discussions I had it sounds more easy to do with LoRa operators than with Sigfox. For sure you have many more chance to have to manage this extension in a LoRa usecase. This way you have to support cost of basestation renting + cost per device to use the public network. It is not the most efficient solution if you have to install/power and pay many network extension. The positive point is you do not have to manage the network backend and operate it. In a such situation you must make many TCO projection and make a good per device deal with your operator.
For object you all have in a given area you can cover with 1-10 gateway it is really interesting to consider private network. Private network is not possible with SigFox but can be done with LoRa. The advantage of this mode is to change your cost price from device based to gateway one. The cost for a gateway is about 1k€ but don’t forget to consider the installation and operation costs. This type of deployment is good for industrial parc, farming but also for city applications as you can cover average city with only 1-4 gateways.
Concerning objects in movement, Doppler effect is affecting SigFox device more than LoRa one. I made a lot of test with SigFox in movement and it worked well (like in this post). In fact if the antenna is moving straight it works well. It start to be a problem when the antenna is turning around (like if you put it on the harm of a runner). So SigFox in movement is not a big issue but a thing to take into account during design. You could prefer LoRa for such application, it would make sense, as soon as you have a network coverage.
When making objects for IoT, communication is the purpose. Low power networks are based on public frequencies and subject to communication restriction. For this reason you have to consider these restriction before starting to design and make sure what you are looking for will be possible. Basically the restriction is to use the shared media less than 1% of time per hour. In SigFox case as everything is defined and not configurable it means 140 message a day. This is not fully true as in SigFox you can change the message size from 12 bytes to 8,6 or 4 bytes. So basically you should be able to transmit about 250-300 message a day with 4 bytes but this is not allowed by SigFox (I hope it will become possible later). So you should have in mind if your system need less than 6 messages per hour SigFox will be ok if more is needed, Sigfox won’t be the solution.
For more message per hour LoRa may help you. The 1% duty cycle rule still valid but the technology have many more lever. The first one is the transmission speed. SigFox is 100bits/s when LoRa offers from 300bits/s to 6000bits/s in the standard transmission mode. This impacts the distance your message will reach, so it is related to the type of network you are connected to and also if you are mobile or not mobile and looking for best radio conditions. So basically for a radio quality not so far from SigFox you can expect 2x message per day. The second lever is the message repetition : SigFox messages are repeated 3 times on different frequencies to avoid collisions so 1 message count for 3. LoRa does not have this function so you can expect to transmis 3x messages based on this. Then you can choose to transfert messages the size you want and as said if you transfer 6 bytes messages you can be about 2x the number of messages. Mixing all of this you can transfert +12x message a day compared to a SigFox network. It can become +240x if you have a 6000b/s communication. Instead of having a limit of 1 message per 10 minutes you have something like 1 message per 50s to 1 message per 3 seconds. Limitation has been broken !
The main problem is we are talking theoretically because your message is never sure to be received and faster you are, less repetition you do, less chance you have to success in your communication. More over, as the number of channel on LoRa is really low, you have many chance to have different devices emitting in the same period of time making communication unsuccessful. In your LoRa design you will have to manage re-emission if your message is important. LoRa allows acknowledgment to manage re-emission in an efficient way. So in your design you need to consider variable number of re-transmission as part of your duty-cycle equation.
LoRa implements duty-cycle after each transmission in most of the firmware, so it means once you have transmitted a frame you need to wait for the next 99% of time before sending a second message. As a consequence if you need to transmit the message again because it has not been ack you will have to wait. Depends on your time in the air, it can reach a minute. As a consequence the time to delivery you message can grow really larger than SigFox. SigFox ensure about 99.9..9% of messages received thanks to the repetition schema in the 7 seconds of transmission duration. With LoRa if you need 3 transmissions it will be slower, even at 6000bps ( about 10s ) and really slower at 300bps ( up to 3 minutes ). 3 transmission is a worst case but possible case. This point have to be taken into account if you have a time delivery critical application. For exemple alarm system have a risk to be unplug by intruder before the transmission completion if a 3 minute delay is reached. Eventually, the way your device is managing the duty-cycle could be redesigned to manage a such case by adding some work of engineering.
Both technologies are offering some security functions : Sigfox is using encryption mechanism for authenticating tye device but is not encrypting communications. So you have to do it at firmware level. LoRa is encrypting data at 3 level. Sigfox is based on a network authentification plus a frequency hopping algorithm and sequence number avoiding a third party device to emit with original device identity. LoRa is using 3 different keys to encrypt at device, application and network level. This ensure, when you have multiple network, public and private, operating the same frequencies to not process data from other one. That is for the ability of a third party to listen on your device data.
The other side of security is for an attacker to switch off you device communications. For a such attack, as you can’t avoid a device to transmit, the more easy is to avoid reception (only reception can be noised with a strong emitter near the receiver). For network like GPRS needing a two-side communication, if you generate noise near the object you can stop any communications by canceling network orders reception to the device. In networks like SigFox or LoRa the device is able to emit without any network authorization, the only way to cancel communication would be to generate noise at every network antenna… so forget it ! SigFox and LoRa are not fully equivalent on this point as LoRaWAN requires the object to receive the network channel configuration in the connect sequence. Once it received these information it can communicate on its own. The connection sequence is initiated on the first communication and we can assume it has already be done when the attacker start is attack when the device is not mobile. When a device is mobile, we can assume it will have to reconnect when changing from a cell to another, in this scenario we can cancel later communication of the object ; for this reason valuable goods tracking is not a good application for LoRaWan.
868MHz is generally a mess for antenna design and this is a recurrent discussion we have with device designer about the good deal between antenna size and radio performance. LoRa and SigFox have the same frequency and the same problem to manage. We also have to consider different frequencies in the different part of the world making a worldwide operating device a big challenge. The main difference between technologies is SigFox is open to many chip provider when LoRa chip are delivered by Semtech and Licensed (actually one Chinese provider) I won’t argue on this as actually the consequences are not totally clear and it is not making a big difference. SigFox offer a lot of hardware solutions but at end, actually, not all of them are ready for industrialization and CE certifications. The LoRa module have to integrate the LoRaWan stack. Actually this one is still in progress and we have seen many firmware updates on the existing modules in the past year. We know we will have some more in the current year to support roaming as an exemple. It means you have to consider LoRaWAN stack upgrade in your device design.
The second point to take into consideration is configuration : SigFox is really a plug & play technology, you have no device configuration to perform : just kick a message and it works. On LoRa you must set all the encryption key. As one of them is related to the network, you will have to change it depends on the network operator you choose. In some cases it is not a problem but in most of the case you must design a way to configure your device on site. It means BLE or Wifi or USB connectivity to allow the end user to make this final configuration. This is an hardware complexity to consider it also impacts the industrial process. For private network, I assume you can simplify this step.
Following hardware design, your system have to be certified for reason that sounds different. You firstly have to use a SigFox / LoRaWAN certified chip or module, usually this certification is managed by the module/chip provider and make sense to certificate the devices will use the right communication protocol. Then you have a device certification. Concerning SigFox, my point of view is they don’t want to have bad communication on the network quality as they are just starting. So they require a device qualification depending on the radio quality. It costs about 2.5K€ and is done really fast, nothing is really blocking at this point, you can choose to have a U2 device (with a poor radio quality). LoRa have its own certification managed by the LoRa Alliance. This sounds in my point of view like a good way to make money at LoRa alliance level. I do not know the price yet and required time. I just know they are making the certification through specialists usually considered as expensive but I may wrong. The surprise of last week was to discover that operators like Orange also want to do another certification. This one sounds free but takes time and gives me a bad feeling like « we do not trust you » As your device could be deployed on many country and different public networks, does it mean one certification per operators ? how many will be free vs billable ? In my point of view all of this make no sense. If you create a GPRS device no-one will ask you for a certification ! your module is certified it is good enough … It should be the same for IoT network : if your device quality is bad, you will be the first impacted, not the network operators : they will just no receive your messages, not more.
Then your object must be certified for CEM, this is valid and equivalent whatever the technology is.
Firmware and Software Design
This is were the difference start to be huge between technologies. SigFox is a plug & play solution and regarding my experience your code between your prototype and your final product is not really different, for sure you add a lot of extra functions in the final product but the radio part is globally unchanged. SigFox implementation is fast as you have no setup, no parameters, just a transmit function including a potential callback function for downling. Concerning LoRa, you can design a prototype as fast as with SigFox, you just don’t care about settings, connection failure/success aven duty-cycle. But, as soon as you start thinking about production, connection/disconnection, duty-cycle management, link quality vs speed are not mandatory anymore. Your firmware will be more and more complicated and testability will start to be complex. I do not say impossible, I just think you will need many more time and you have many more chance to make a malfunctioning device on LoRaWan. You also have to manage encryption key setup, you have to manage communication parameters coming from the WAN and you are not managing (what about your message frequency and duty-cycle management if you plan to have SF7 and your network operator in an area only accept SF12?). It is actually hard to say exactly how difficult it will be to manage as we have no public offer available and I can just think about hypothesis and risk management. But my opinion is SigFox is like an apple product : it is closed but play&play when LoRa is like Androïd : you have many way to tune it and at this point it start to be a mess, you may have access to a functionality but as it is buggy until the next release you will have to find another way…
GPRS was really simple : based on TCP/IP you had a direct connection from the device to your own backend. IoT world is really different : to limit the amount of data to transmit and simplify the communication protocol, the communication have to pass through an operator backend before reaching your own backend. On the software side, the mechanism are similar : data are received by the network operator. This one stores the data on its cloud and propose some callback solution to transfer them to your own backend. For SigFox, the backend they are proposing is a global one. Whatever the country your object is, the way you gather the data is exactly the same. For having deployed objects in different European countries, this is a really killing feature in my point of view. Considering LoRaWan is really different : if you do not manage your own network, you will have to manage the different backend of your different network provider. Each of them will have it’s own API to manage device and gather data. At end you will have to implement all this complexity in your own backend or pay a future third party to manage this complexity for you. Eventually you will have to follow backend upgrade of the different operators to stay compatible. For managing private LoRa network you will have to build you own backend, or to let some company manage it for you. Another solution to take a look to in TheThingsNetwork a kind of open-source global LoRa network.
When you are managing a large number of devices the device location is an important information. GPS solution is costly in term of price and energy consumption. IoT network are proposing some help for this feature. SigFox is actually providing a 1° latitude/longitude location. This not sufficient in most of the case but it still a valid information you are getting for free. LoRa network are actually looking for a really better information with current technology standard developments (kerlink as an example is working on this capacity). Based on propagation time of LoRa messages it will allow to have a precision near a GPS for « free » Actually this solution does not exist yet and I hope SigFox will also work on it as it is really promising. For sure it looks like a killer feature for the one providing it first.
To conclude my feeling is SigFox is the best solution for public network when LoRaWan is a really great solution every-time you will operate your own private network (eventually you can delegate it, even to a public operator, but I mean you are controlling and limiting the extension of this network). Sigfox is simple when LoRaWan is customizable. SigFox exists when LoRaWan is a promise for futur.
I’ve tried to summarized most a the question related to my previous paragraph and give you an estimate of the complexity of your project depends on the technology you can use. I hope this grid will help you.
This post is subject to future modifications and precision as my experience on LoRaWAN is still limited and my knowledge about LTE-M is really limited.
SigFox LoRa Future-LTE-M My object is deployed in many countries Easy Complex Easy My object is moving more than 60km around Easy Complex Easy My object is moving less than 60km around Easy Average Easy My object is not moving, > 100 same area Easy Easy Easy My object is not moving < 10 same area Easy Expensive/Easy* Easy My object is not moving > 1000 same area Expensive Easy Expensive My object is communicating less than 6 time per hour Easy Easy Easy up to 1 time per min Impossible Easy Easy more than 1 time per min Impossible Complex Easy My object message are time is critical Easy Complex Easy My object com. have to be secured Easy Easy when At risk not moving My Object have to be plug & play Easy Average As GPRS Firmware Prototyping Complexity Easy Easy Unknown Firmware Production Complexity Easy Average-Complex Unknown Backend Prototyping Complexity Easy Average Unknown Backend Production Complexity Easy Complex Unknown Device Certification process SigFox LoRaAlliance None +Operators Part of communication chip in Object price 2$-10$ 2$-10$ 10$-20$ My object can be deployed since 2014 2016/17 2017/18
Great article! Thank you
“That said, I do not trust public announcement and looking for facts.”
“Considering LTE-M arriving everywhere in the world in the next 1-3 year […]”
Isn’t that a big of a contradiction? Various IoT-flavored technologies have been announced by the 3GPP, with huge promises (low power, low cost, simple stack) but there is very little to show.
The stacks are complex, the modems have high peak current, the frequency plan is a mess making antenna design quite a headache and everything is encumbered by tons of patents. Let’s see what the 3GPP can *really* offer before comparing it with the real LPWAN technologies that are available.
SigFox transmit all data ‘in clear’ with a cryptographic signature (http://www.01net.com/actualites/objets-connectes-le-reseau-francais-sigfox-une-passoire-en-matiere-de-securite-957875.html)
LoRaWAN has mandatory data encryption and cryptographic signature.
To get a security equivalent of LoRaWAN on a SigFox device, you have to implement data encryption yourself. Perfectly doable, but crypto is hard and it’s really easy to make a small mistake and end up with very weak security. On the other hand, you can adjust the crypto level to you requirement.
Ease of implementation :
For a fair comparison, you should compare modules that are comparable.
All SigFox modules that I know of have the stack totally integrated in the module, making them very easy to use. Similar modules exist for LoRaWAN, for example modules by Nemeus : they’re already qualified for several operators, all the default parameters are set to work out of the box, and they use simple AT commands.
Thank you for your comment !
Not a contradiction : LoRAWan is a dedicated network for operators and we are waiting for the first city opening since a year. Concerning LTE-M it will be a feature included is the standard 5G deployment at no over cost. So it will be.
I’m fair comparing module to module. Even with AT command on LoRa you have to manage connection, key configuration, roaming constraints… That is my point.
Hi Paul, great and comprehensive article.
A few comment though:
– LTE-M does not have the same market positioning as LoRa/Sigfox. LTE-M aims to a 1Mbs data rate and a few weeks battery life.
-Sigfox data rate is 100 bps (except in the US where for regulation reasons, they have to go up to 600 bps in order to respect the 400ms max time-on-air limitation which greatly impacts the coverage)
-LoRa can to message repeat the same way as Sigfox (it’s in the standard) although it is not frequently used.
– Every LoRa is pre-provisioned with 3 default frequency channels so it can communicate even it has not received any channel configuration.
– “When a device is mobile, we can assume it will have to reconnect when changing from a cell to another, in this scenario we can cancel later communication of the object ; for this reason valuable goods tracking is not a good application for LoRaWan.” LoRaWAN is great for asset tracking as there is no dedicated connection between base stations and devices. Devices multicast….
As for you conclusion I don’t completely agree and most of the Telco operators don’t seem to agree as well because of the huge number of telcos currently testing or deploying LoRa….
Thank for completing my post. I will make some fix. Bandwidth is not a problem but a solution reducing consumption time. So LTE-M in my point of view will be a nice IoT solution but we need to wait for later implementation. The current LTE-M Cat0 is 1Mb/s but the next version will be 200kbps with a reduced power consumption.
LoRa allows repetition but most of LoRaWan firmware does not implement it. As i said it is not impossible but extra work. The 3 default frequency are i mutch as i know connection frequencies and in the LoRaWan stack I was able to use it was not possible to transmit data when connect failed.
You right a large number of telco are testing : and my purpose is when will they end test and make a public offer ? This will help to clarify all these points by practice.
Paul, I agree that operators could go a bit quicker. However, Bouygues and Orange networks will be commercially available this year: Bouygues probably in a couple of months, Orange at end 2016….and this only in France. There are also networks on Belgium, Netherlands ans Switzerland that are very close to public availability.
Thanks Paul ! Great article as always.
By the way, what do you think about this ? http://forum.thethingsnetwork.org/t/universal-lora-wan-gateway-limitations-because-physics/1749
Did you experience something like that with your equipment ?
The claims are quite huge and they come from the guys at TTN themselves.. quite weird.
Thank you for the link. I was aware about this problem and it sounds logical when you compare the number of available channel between technologies. I choose to not notice it as actually 1000 messages a minute means thousands of devices in the same area and today in 2016 we are far away this density. So it could be a later problem if …
By-the-way … thank you
Thank you for taking the time to put something out there. The hardest thing to do is create something and put the words down. Anyone can be a critic, but few are bold enough to create.
Full disclosure: I represent everynet, a LoRaWAN networking company. We provide a comprehensive LoRaWAN network management platform, network server, and very low cost, carrier-grade base stations. We also have an interoperability lab where we test anyone’s LoRaWAN end device against various gateways to make sure they are fully operable and compliant. We have existing production LoRaWAN networks with MNOs and governmental/quasi-governmental customers (ie municipalities utilities, smart cities, etc) around the globe.
You raise good points. From an everynet position, we don’t necessarily agree with all of them, however, it appears to us you have gone to great lengths to be fair and research the two different approaches. Unfortunately we realize not all information is easy to find or publicly available yet. We all have a lot of work to do to educate the market. The points you raise are exactly the topics that need to be discussed.
First, we would like to invite you to use one of our customer’s public network that has been established just for the testing purpose you describe. Additionally, I would like to put you in touch with some technical resources via private email and you can see for yourself if perhaps some points should be modified.
We appreciate you taking the time to educate the market from an independent perspective. It helps everyone that wants to see LPWA technologies expand the reach of IoT connectivity.
would be a pleasure to test a public LoRaWAN network 😉
– from my experience:
Lora is much less semsible to the fact that the object is moving while it’s virtually impossible to get message on a car or train….
Settings : if you get a preconfigured module (just like Sigfox), it requires no configuration….
The “my object is deployed in many country” : both approach are today complex.There is much more country with LoRa enabled networks than Sigfox ones, but roaming is not yet put in place…
You right, it is a point I should add. BUT practically I’m using SigFox in cars (so they are moving) and it works well. So in fact the problem with sigfox is more related to the movement of the antenna, when it is rolling around the object you have a problem. There are solution to wait for no movement before sending working well.
But you right, in a such situation LoRa is working better (if you have a network available … that seems not easy when you are in movement …) So I don’t know what is the worst actually.
According to your IP you are representing a SigFox competitor …
By-the-way : I don’t know what is your experience but I’m having 3 sigfox + 1 LoRa device in my car, and all are working well. You can also check my post on this topic with all my results at different speed. I also did test on train and it worked well (at least in Clermont-Paris train)
Setting : sure if someone do the job for you you won’t have to do it … at the end you pay for it.
Much more country ? … you mean ? I would really appreciate to have link giving country list with coverage map (this is not a question for bashing anyone, it is just because I was not able to find any map of any country offering LoRaWan and I would be please to get some)
Regarding TDOA location this is not linked to Kerlink but it’s a standard LoRa development.
Objenious in France will be one of the first to deploy this feature allowing object location without GPS….
Thank you for the precision.
Very Good Article Paul have you looked at www . ingenu . com and studied the RPMA IoT solution, I would like to hear your opinion ? If you give me your email address I can give you information that is public available about the system.
Not sure about your background but there are some really weird sentences in your article? Anyway for clarity I have been inside Sigfox for a couple of years and now am with Semtech and board member of the LoRa Alliance.
Your article is a little outdated as today there are country wide roll outs done and announced (NL, Korea) and there are approximately 5 times more LoRa gateways installed globally. True not each operator, a carrier or encumbant, has gone public yet but if you come to the Open House meetings of the Alliance you can meet most of them.
Besides the technical differentiation, yes you need a LoRa training :), I believe the differences in businessmodel and industry backup will determine the success on the longer run. Sigfox has been rolling out for 3 years now and still only has a couple of million in revenue from connectivity. Marketing messages of 7M registered objects are tricky, there is only a fraction of that actually deployed and live. However the lack of success is not only driven by limitations in ability to service the needs of a wide variety use cases (very limited downlink, issues in motion, payload limitations, no geolocation embedded, no security embedded etc) but merely by lack of coverage even if claims are made countries are covered, in France it was even recently published launching customers like Maaf and Clearchannel have cancelled their sigfox plans. In short, and our operators have validated that, 1.500 gateways in France does not get you proper indoor coverage.
The biggest risk for sigofx however is on the fund raising side, and some shareholders already have made their minds up by rolling out LoRa. There are very few bigger companies rolling out sigfox to date and most so called SNO’s are to an extend start ups or enthusiast entrepreneurs. As a result sigfox is forced to roll out the network themself (failing revenue share model and your point about hosting everything in France) which is killing them from a cash burn perspective. If you check the financials you will see they will need to raise capital early 2017 (or try an IPO as they mention themselves) and it remains unclear if the street wants to put in more cash, there is virtually no sign of any return in the foreseeable future.
With the industry back up of Cisco, Samsung, Orange, ST Micro Electronics, Microchip, KPN, SK Telecom, Sagemcom, etc etc LoRa and the LoRa Alliance’s eco system has invested over 1.5B already and this is even doubled in the next twelve months, I simply do not see how this can be achieved with sigfox on a pre money valuation of 150M (last round) and extremely disappointing revenues of a couple of million derrived from subscribers in 2015.
My crystal ball shows a rather exiting LPWAN future where open networks will be rolled out by carriers, encumbants and enterprises required a closed network based on (open) standards, keeping also NB IoT in mind for the licensed band players, rather than prorietary solutions where you can only buy the gateways in Labege, host your data outside your country and share the majority of your revenue.
Time will tell, and if you want to jump ship at some point let me know…
Hi Jaap, nice to read you and contribute to my blog. It is always good to have some news from LoRa land because factual communication is rare mostly about available public offer. I would be really happy to have documentation about the public offer you announced here NL and Korean and mostly about all the other you seems to indicate but not list. To be honest I would be happy to have more training about LoRaWan so do not hesitate to invite me to free training, more I will know and less you will found my post weird. But you know, instead on working on slide, my own approach to learn is to make. That is why I’m experimenting LoRa and what I know is LoRa gateway coverage is about 5 time less than Sigfox, which means 5 time more antennas to cover the same country size. So even if your numbers are active public lora gateway (which I do not really trust) it means an equivalent coverage compared to Sigfox.
Personally I do not care who will win in the SigFox vs LoRa match as I have no share in any of these company. What tells my crystal ball is in any case LoRa will be killed, in my opinion not by SigFox but LTE-M because operators won’t have any interest to maintain 2 equivalent technology once the second one will be deployed and modem will be at an accessible price. Sigfox will survive if they reach a critical mass before this date (something about 2022) or eventually will pivot to a global operator based on a mix of technologies. You and me may wrong or right. I can give you a rendez-vous on this blog in 5 years to discuss why we where both wrong in our crystal ball analysis.
Very well written, balanced article and beautifully answered Mr. Jaap. I enjoyed reading every bit of it.
Your blog really helped me in understanding concepts of lora. Sir i am working on concept of many sensor connected to microcontroller then sending those sensor reading via RN2483 module. i have problem in establishing connection to gateway can u please suggest me basic things that i need to send commands from RN2483 like configuration
Try “RN2483” on search box, you may find what you are looking for
Thanks for the great article, it helped me with the choice I had to make between both technologies.
I had a question about the antennas. Did you tried, ath this moment, some more designs on PCB’s or on more compact antenna’s? And because of the time between publishing the article and today, do you have some more reflections on one of the technologies?
I asked this because I’m working out a project for high school.
Thanks in advance!
Hello, I did not try PCB antenna because iteration to make them working are longer and more costly they are also usually taking more space on the PCB, that said it do not means we should not use them, just means I’m not familiar with. Concerning technology choice it is more related to project context and the use of public vs private network or the need of high or low transmission frequency.
Its a great article. It helped me to understand technical aspects and comparison between Sigfox and LoRa. further more I would like to know difference in terms of Radio Resource Management of Sigfox and LoRa.