I would like to create a point-to-point connection between a LoRa temperature sensor and a M5 Stack (ESP32) with LoRa module. However, I am a beginner with LoRa, so I have a few questions:
Are all packets send with LoRa (not LoRaWAN) encrypted? Or does it depend on the producer of the LoRa sensor?
Can the content of the packet received by the M5 Stack be viewed? (If I understand correctly, with the LoRaWAN the content can only be viewed after it is on the server).
Can I send measured temperatures from multiple LoRa sensors to one M5 Stack? If yes, how could I distinguish from which sensor the packet has been sent?
Any help would be appreciated!
LoRa means only the RF modulation. All crypto happens in higher layers, i.e. the protocol stack – one possible option for this is LoRaWAN. LoRaWAN uses AES-128 encryption in two layers, Network and Application. You gave no information about the kind of "LoRa temperature sensor" you have, so it is not possible to make a statement about that, other than that it is not LoRaWAN. So this fully depends on the sensor's firmware. There are alternative protocol stacks to LoRaWAN, DASH7 for example. You also might want to have a look at this Stack Overflow article
This too depends on the used protocol stack. With LoRaWAN, you need a gateway to receive the node's LoRa telegrams which are then forwarded to the LoRaWAN cloud (TTN/TTS, for example). Your application can get them from there via Internet. If there's already a TTN gateway in reach, your nodes would automatically use that.
You can actually use the M5 with its WLAN capability to act as a message consumer for multiple nodes by subscribing to the cloud via MQTT, for example – using LoRaWAN. Using LoRa without LoRaWAN, this again depends on the alternative protocol stack you are using here. Of course this requires a working WLAN in reach.
If you are trying to use plain LoRa, which is possible, it is purely your task to implement all the requirements for managing the communication between all involved nodes; it is also your responsibility to ensure that the legal obligations are met.
I would strongly recommend using LoRaWAN and TTN/TTS as it is the de-facto standard for LoRa communications and offers a complete ecosystem that can be used readily without great effort/cost.
Related
What is the best way to provide bidirecational communication using CoreBluetooth framework?
I want to use BLE stack protocal as tcp-similar(only as a way for sending data) and then add upper layes: as tls, http, grpc etc.
We have 2 ways(I guess):
Via characteristics (but here we have restriction in 526 bytes strings and I'm not sure at all that we have complete bidirectional communication here)
As example I have doubt about possibility to set communication via characteristics as simple tcp exchange.
Via L2CAP channels(in my mind it's just a 2 output/input streams for bidirectional communication) that complelty suits to tcp-similar approach.
Which way is the best and why? Maybe examples are present anywhere?
Using "write without response" + "notifications" is almost the same in terms of performance compared to l2cap coc. In the end it is just a different header if you look at the raw BLE packets over the air that will be the difference (a few bytes might differ in the overhead, but nothing of importance if you have the LE Data Length extension enabled). One difference though is that you have the flow control mechanism for l2cap coc that you don't have for gatt.
My suggestion is to try both and pick the API that you like the most.
I have been looking into LoRaWAN for a low cost waterproof asset tracker I am looking at building.
AFAIK, the primary benefits of LoraWAN over say LTE-M or cellular are: no connectivity costs and potentially lower power consumption.
What I'm wondering is: why can't we use our own cellphones as the "base station" that the IOT device talks with? We can do this with bluetooth and WiFi, why not cell? Is it the LTE protocol that prevents it? Physics? What am I missing?
There's quite a few architectural reasons why Peer-to-Peer LTE isn't feasible, but the largest is probably the fact that in LTE the uplink and downlink use different modulation techniques.
In the downlink (the connection from the Base stations (eNodeBs) to the User Equipment (our mobile phones)) Orthogonal Frequency Division Multiplex (OFDMA) is used, this means the phone listens out onto the RF interface for the OFDMA signal.
This works well, OFDMA is a great way of encoding the data onto the air interface, but it has a very high peak-to-average-power ratio, this means if the UEs used OFDMA in the Uplink (From the UE to the eNodeB) they'd have awful battery life.
Instead in the Uplink LTE uses Single Carrier Frequency Division Multiple Access (SC-FDMA), which is much more power efficient and allows you talk all day, so the eNodeBs listen on their RF interface for the SC-FDMA modulated traffic.
This means our UEs (Mobile phones) use one type of modulation to send and a different modulation scheme to receive, so they can't talk directly to one another as they can't send OFDMA modulated data, only receive & visa-versa.
Some more reading on OFDMA & SC-FDMA.
The LTE relay interface inducted as part of Release 10 allows the deployment of relay nodes (a kind of low cost eNB) that are fixed and that use in-band LTE to extend the coverage of standard eNodeBs by one hop, improve signal quality and to increase the network capacity. Relays can be placed such that it converts the long single hop into two shorter hops.
However the approach of using UE seems have many challenges as it can make UE to get bit loaded with more functional changes across layers(MAC, PHY, RRC, NAS) as it has to take additional functionalities from Relay nodes/eNB as well ranging from lower layer signalling, co-ordination, mobility to forwarding. Also, there might be additional power consumption and change in antenna to support the same which all will add to more cost of UE.
I have a doubt about the IoT Protocol Stack .
Searching between papers on google scholar or IEEE about IoT , i find the actual "IoT Protocol Stack" :
IoT Stack
I think it is uncorrect .
The doubt is about the transport layer and application layer.
1) why there is only CoAP on the application layer if there are many others Application Layer Protocol for the IoT , such as : MQTT, XMPP ,AMQP , WebSockets and so on?
2) Why they provide only UDP at the Transport layer if in the upper layer ( Application) there are some important protocol in the environment of the IoT , for example MQTT, that run over TCP ?
The term "IoT" is used with various meanings by different interest groups; so is therefore the term "IoT stack".
What the linked image depicts is the IETF IoT Stack, which is the IETF's idea of what IoT devices should use to deserve that name. CoAP is the application protocol specified by IETF (and used by various others like OMA LwM2M, OCF or Thread), and is in my experience the best suited protocol as it allows full operation on tiny devices (technically: Class 0 according to RFC 7228 – good luck implementing XMPP, WebSockets or similar on those) while still being powerful enough to express all the concepts from the HTTP web.
The image depicting only UDP is probably due to the focus on IoT devices: While CoAP can be transmitted over several transport layers (including TCP and WebSockets, but also SMS in a draft version), those transports are rather used indirectly (eg. by a browser application that uses a gateway to talk to UDP connected devices), the expected scenario for the devices themselves is using CoAP over UDP on a 6LoWPAN network. That doesn't rule out other deployment scenarios (eg. LwM2M uses CoAP over cellular networks a lot, in UDP and TCP transports), but is better seen as typical example for the smallest of devices.
I'm trying to implementing tree topology with Cooja/contiky. Finding through examples i've not been able to find an a good example to find what i need.
In short :
I'd need to implementing a topology of this type(picture here under) with cooja end contiky, is there someone that could give me some advice?
Thanks in advance
I don't really use Contiki Operating System, I have only ever used TinyOS but a network topology such as the one you have should be easily achievable.
For TinyOS, the mote-to-mote radio tutorial HERE will show you how to two different sensor nodes can communicate with each other (a gateway is basically just a sensor node connected to a PC) and the mote-to-PC communication tutorial HERE will show you how a gateway node can forward information from itself to the PC it is connected to. When the network is running you basically have a Java application listening to USB port and receiving packets from gateway node. Once the packet has been received on the Java application then you can send it to an external network server.
It may sound difficult if you have never developed on TinyOS but what you want to do is very common and so there will be complete programs in the tutorial section of a typical TinyOS distribution showing you how to achieve most of the things you need you need to achieve. There should also be similar examples in Contiki.
Just asking one silly question, hope someone can answer this.
I'm bit confused regarding MQTT broker. Basically, the confusion is, there are so many things being used for data storing, transfer and processing (like Flume, HDInsight, Spark etc). So, when and why I need to use one MQTT broker?
If I would like to use Windows 10 IoT application with HiveMQ, from where can I get the details? how to use it? How I get benefit out of this MQTT broker? Can I not send data from my IoT application directly using Azure or HDFS? So, how MQTT broker fits into it or helping me to achieve something?
I'm new to all these and tried to find some tutorials, however, I'm not getting anything proper. Please explain it in more details or give some tutorials for this?
MQTT is a client-server protocol for pub-sub based transport that has a comparatively small overhead, and thus applicable to mobile and IoT applications (unlike Flume, etc.). The MQTT broker is basically a server that handles messaging to/from MQTT clients and among them. The functionality pretty much stops at the transport layer, even though various MQTT add-ons exist.
If you are looking to implement a solution that would reliably transfer data from your IoT devices to the back-end system for processing, I would suggest you take a look into Kaa open-source IoT platform. It goes much further than MQTT by providing not only the transport layer, suitable for low-power IoT devices, but also a solid chunk of the application level logic (including the object bindings for your application-level data structures, temporary data persistence, etc.).
Here is a link to a webinar that explains how to build a scalable IoT analytics system with Kaa and Spark in less than an hour.
This is an architectural choice. IoT applications are possible without MQTT but there are some advantages when using MQTT. If you are completely new to MQTT, take a look at this in-depth MQTT series: http://forkbomb-blog.de/2015/all-you-need-to-know-about-mqtt
Basically the main architectural advantage is publish / subscribe designed for low-latency, high throughput (mobile) communication with minimal protocol overhead (which is important if bandwidth is at a premium). You can completely decouple consumers and producers.
HDFS is the (distributed) Hadoop file system and is the foundation for Map / Reduce processing. It is not comparable to a MQTT broker. The MQTT broker could write to the HDFS, though (in case of HiveMQ with a custom plugin).
Basically MQTT is a protocol while the products you are mentioning are, well, products which solve completely different problems:
Flume is basically used for log aggregation at scale. You won't use MQTT for that, at least there is not too much advantage because this is typically done in backend applications.
Spark and Hadoop shine at Big Data crunching. They are a framework and not a ready to use solution. They are not really comparable to MQTT. Often MQTT brokers like HiveMQ are used in conjunction with these, Spark / Hadoop for data processing and HiveMQ for communication.
I hope this helps you getting started. Best would be to read about typical use cases of all these technologies, this is a bit too broad for a single SO answer.
MQTT is a data transport, so the usual thing I have to compare it with is HTTP. HTTP has two important characteristics, a) It goes from one point to another, b) It is request/response, so only one end can start a data transfer. MQTT connects many end points to many end points, and either end can start a data transfer. So, if you have just one device and only one service or person that will ever access it, and only by polling, then HTTP is great. MQTT means many devices can post data to many services or people, AND the other way around. Your question assumes that your data is always going to land up in some sort of data store, but many interactions are about events and responding to them immediately, like ringing a doorbell, or lowering the landing gear. In these cases you will often want to both record the data, and have an immediate action occur, like your phone making a doorbell noise.
Finally, you send data to MQTT semantically, rather than by IP address.
This means that your services subscribes to /mikeshouse/doorbell rather than polling 192.168.22.4, which is a huge gain once you have a number of devices.