Imagine your network as a Venn diagram where one set is LoraWan and the other is MQTT.
Elements in the sets should know only about their set(s).
So nodes using LoraWan (are in the LoraWan set) do not have to bother with MQTT or with the server. They just send/receive data to/from the Gateway. The Gateway is the end of their world.
The Gateway is in the ...
In a typical LoRaWAN network, gateways are dumb devices, as explained by the LoRa Alliance:
LoRaWAN network architecture is typically laid out in a star-of-stars topology in which gateways is a transparent bridge relaying messages between end-devices and a central network server in the backend.
So, a gateway only needs to be configured to connect to some ...
These are mainly very general answers that apply to all receiver/transmitters not just the LoRa gateway.
As a rule you should not run transmitters with out an antenna attached (or a dummy load) as the transmit energy is effectively reflected by the open socket and can damage the equipment. You may be OK to run the gateway without the expansion card if there ...
Yes, using LoRa radios to receive messages is possible. For the Arduino platform, the LMIC library can be used. See my code for mobile node with gps and gateway. The gateway publishes data to a service called PubNub, which has a free tier that probably is sufficient for your needs.
It should be fairly easy to modify the gateway code to send data to your own ...
The problem is essentially one of receivers and of power.
A "find my keys" type of beacon needs to be small enough to attach to your keychain and you probably don't want to have to regularly recharge the beacon (you wouldn't lose your keys if they're always in their charger) so that requires either:
a passive technology without a battery.
an active ...
Your challenge is handling the throughput demands with channel contention. Your devices are all close enough that you need to assume they are all potential interferers to each other so you will need to use a protocol that is robust to this - probably using some sort of coordination between devices to ensure they all take a fair slice of the channel.
Indeed, the whole point of "The Things Network" (TTN) is that multiple LoRa gateways are used to transfer messages between LoRa radio signals and the Internet based routing.
And these don't even have to be gateways owned by you - by registering your device on TTN you have access to all gateways in the public system, and by making your gateway part of TTN, ...
It seems that a range of at least 440 km is possible with the LoRa protocol (i.e. there is no time-of-flight assumption as in GSM).
The correct way to answer this question is by looking at the link budget for your transmit/receive arrangement. Although the basic calculations are simple, knowing the right way to do the calculation is not so simple.
Just to clarify from what I undestand when researching these modules:
RFM69x - Packet Radio (not LoRa)
RFM96x - LoRa Radio (or RFM95 / RFM97 - thanks Chris)
If you're trying to use an RF69x for LoRa, that's your issue
A quick google search should show you how to get LoRaWan up and running if you have the correct radio module (RFM9xx).
Hope this helps.
This is an unusual use-case where the data throughput which you require is really low - range and low power are the driving factors. This points in the direction of a low data-rate, narrow band protocol (or maybe one using a spreading code, such as GPS).
Looking for long-range through walls, etc. implies a low RF frequency too, 433 MHz would probably be ...
There doesn't appear to be a route for private individuals to get on the scheme, however, I have a company and live in Cambridge.
I can submit an application to http://www.connectingcambridgeshire.co.uk/smartcamb/ and should get on the LoRa network.
I am back working in the automotive sector again but spent a few months last year working on IoT ...
How big is a LoRa packet including PHY headers
I assume you mean MAC header? After some LoRa chip has demodulated the LoRa radio signals for you, it will give you the LoRa PHY payload. For a LoRaWAN uplink such PHY payload holds a MAC header, MAC payload and MIC.
For 1.0.x the rule of thumb seems to be that a LoRaWAN packet is at least 13 bytes larger than ...
Using the information in this answer: https://iot.stackexchange.com/a/2934/746
At (a worst case) max useable payload of 51bytes it will take 41,120 packets to send a single image (assuming no need for re-transmits).
I do not think this will be practical.
First, your question is unanswerable by the way as no one could tell what will work in an unknown environment. For example if there is a huge hill between the two modules, or a big city then it won't work. But if your module is attached to a ballon which has an altitude of 38 km, then you are possibly good.
While the balloon was at an altitude of 38.772 ...
The data sheet is not too forthcoming on their expectation for connecting an antenna (other than suggesting that a matching network is mandatory if you run high power). However, from the photos in the linked article, it's clear that what was used in this example was a 50 ohm coax to SMA 'pigtail'. You can get a short coax pre-connected to an SMA (with maybe ...
I would recommend some sort of mesh network, as obviously plain old WiFi or BT won't cover those distances. Zigbee is as good a candidate as any.
For hardware, AdaFruit does some good wearables, although if everyone has a smartphone, you might as well use those.
And, if you can figure out how to power it by battery, take a look at my answer to this ...
I would like to say that Yes, Bluetooth is a good candidate for indoor positioning.
Depending on how good positioning you want, of course.
If you have Bluetooth beacons scattered over your house it will probably be as simple as cell positioning - the beacon that last saw your key chain will be in the same room as the key chain. With one beacon per room, it ...
LMiC does not tell your code when transmission has started, but you could enable debug logging.
When you're transmitting well below duty cycle limitations, then LMiC will often send almost immediately. It might postpone things:
When using OTAA and the node has not joined yet, it will first try to join when the first packet is scheduled.
When duty cycle ...
I figured it out.
Turns out there was a bug in the raspi_lora library I used for my python code.
It is so that, if you are not specifically sending to the device address or have receive_all=True, it will do nothing with the messages.
If you plan to use the raspi_lora library you should replace line 268 in the lora.py file with
if (self._this_address != ...
As is often the case, it depends. There are many factors to consider, and a lot of options available to cover the many different use cases around.
DigiKey suggest that you can expect the following ranges for common IoT protocols in an unobstructed environment with little interference:
5 GHz Wi-Fi: 50 m
ZigBee/RF4CE: 100 m
Bluetooth low energy: 100 m
One Access Point for 250m2 and 3 floors, seems to stretch WiFi a bit.
It depends on the material in the building, surrounding interference and antenna.
To give a answer, one should do a survey and measurements on site.
A Guesstimate would be probably not.
can't I have "something" that receives the data and sends them over ip-based networks?
Yes you can and that's called a gateway.
These services like Things Network and Loriot.io provide software for the gateways, cloud servers (a backend) and API's. You don't need to ...
On this site http://www.scoop.it/t/the-french-wireless-connection/p/4055120530/2015/11/12/lorawan-class-c-and-multicast there is link to presentation about a street lightning solution made with lorawan and they say (direct quote):
Because the downlink traffic is more significant and because of the restrictions imposed by different telecommunications ...
What I found remarkable is that while screen can get human readable characters, the
MQTT-SN bridge just seems to get garbage.
This turned out to be the important part of tracking down the problem. GNU screen set the baud rate, but mqtt-sn-serial-bridge wasn't doing so. That turns out to be because
$ ./mqtt-sn-serial-bridge -?
Formally, you should indeed have a matched antenna when operating a radio transmitter, and antenna matching is indeed frequency dependent.
That said, (permissible unlicensed) LoRa RF power levels are relatively low, and the potentially lasting issue with mismatched antennas is from the reflection of transmit power back into the transmitter. The lower the ...
Try a Yagi antenna. Both receiver and transmitter will need an antenna, and they must be aligned with each other (direct line of sight). Just a few degrees of inaccuracy will cause bad reception. There are various DIY yagi antenna guides online, and open source yagi calculator programs that will compute the required dimensions for a 868MHz antenna and balun. ...
A Yagi (and most TV) antennas are VERY directional, they achieve their good range by making sure they direct all energy in one direction. You would only be able to communicate with devices that are on the straight line your antenna is pointing in.
This wouldn't really be all that useful.
You need to look for a omnidirectional antenna to give the best ...
The sx1276-series chips don't support spreading factors outside of SF6-SF12 (per sx1276/77/78/79 datasheet). The new sx1262-series chips support SF5 (per sx1261/2 datasheet).
With lower spreading factors at some point it's not spread spectrum anymore and probably best to switch to FSK modulation.
Higher spreading factors put more stringent requirements on ...
Yes it's free.
The idea is similar to the original Internet model, if you set up a gateway you allow others to use it as well and in return you can use other peoples gateways, that way the overall coverage grows and everybody benefits.
You don't need to buy a gateway from TTN, you can use any number of gateways*, but I think TTN are now asking that you use ...
I think your best bet at these distances is a GSM modem with a SIM card and a data plan with the cheapest available operator. You can connect the GSM modem to whatever device is taking pictures via a SPI or UART or USB and send your pictures by email, SMS, or MMS message, or even upload them directly to a FTP site. This is a cost effective solution that ...