Local Lora communication

Is there any application where Lora is used for LOCAL communication ONLY between a client device mounting some sensors and a server which locally translates the signals coming from the client on the Lora frequency to WIFI so that they could be read for example by a smartphone/a computer connected to the same LAN as the Lora Server?
In short: Is there any application where Lora is used only Locally exploiting its long range capabilities?
thanks

Lots of people are using LoRa outdside of TTN.

But how would this be a question for a TTN forum ?

It’s possible, either with simple LoRa schemes or with a LoRaWAN server running on the gateway; quite a few gateway manufacturers offer such a standalone option.

Generally however it is unwise.

Additional, phones often are not actually connected to the wifi network, but rather on a mobile network which is effectively foreign.

Routing things through the cloud is general the sensible course of action - the exception being isolated parts of the world with no affordable Internet.

But again, that’s not TTN and so not a topic for the TTN forums.

There was a very interesting session in the Things Conference last year about 2.4GHz LoRa and had an example of it’s use on ships. Here’s a link 2.4 GHz Lora - The Things Industries. I think in the conference session they explained their reasoning.

I run a few sensors on a farm where there is no mobile coverage. The distances are mostly less than 1km, but just a bit too far to do WiFi cheaply, and I wanted battery operation. TTN seemed ideal to me even for my tiny local application. The TTN community have already done all the hard lifting.

Now my little corner the country shows up on the TTN map. I’ve watched the number of gateways in the country grow over the last two years. There are now 3 more in my region, a few more and it might be worth starting a local TTN community, and if any of the neighbouring farms want to run non-commercial sensors they are quite welcome to connect via my gateways. :slight_smile:

1 Like

thanks a lot
yes I knew the subject wouldn’t have much to do with TTN however I was hoping for some suggestions
Hope the Things conf may help however it is of no help saying

“Lots of people are using LoRa outdside of TTN.”

without any useful link

You know, every time I try to approach IoT I find a kind of refusal to adapt to an apprentice language

Thanks anyway
I shall look for other forums, difficult to find which

Maybe because it’s not an apprentice topic?

Googling for “lora to lora communication using arduino” gives me pages and pages of results for tutorials and code and the like so there is no shortage of resources out there, taking one platform as an example. There are also forums for almost every hardware vendor where you can discuss implementation details - so one approach would be to look at different hardware offerings, pick a couple of vendors that seem a good fit and then browse their forums to see what discussions & support is like.

1 Like

Sorry if its not very helpful but GIYF if you want to search for the alternatives. This is the TTN forum focussed on LoRaWAN vs LoRa-LoRa comms (though it often poos up in various threads, and things like the Radiohead library get ref’s etc. - use search!). By analogy I would not expect to go to Amazon’s AWS support forums and expect a great response on how to implement a Microsoft Azure instance or use Googles Cloud platform, etc. :wink:

There are plenty of demos for how to use Radio Head or some more board specific code to toss packets with fixed frequency and air settings between node boards.

The problem is that this is very far from having a useful, robust (or in many cases, legal) system.

LoRaWAN has a lot of design engineering centered on how to get from raw packets to actual usability. It happens to assume the capabilities of a multi-channel concentrator card at the infrastructure end - not only because that makes it a lot easier to use the allowed radio spectrum, but because yes, it’s a spec authored by the company that sells the silicon.

At times I’ve toyed with the idea of designing something that could work with cheap node radios in the base role. But the reality is that what’s expensive in IoT is not the hardware, but rather the people. Gear is cheap, it’s supporting users, performing installations, etc which is expensive. By the time you get a gateway installed on a site and provisioned with a way to send its data somewhere, the cost difference between a gateway-grade concentrator radio and a cheap node radio is only a small part of the total cost of the system. So the also substantial investment in developing such a low performance system that wouldn’t really save much money in use, doesn’t happen.

1 Like

I think I found something resembles what I am looking for, it is the
https://www.meshtastic.org/ network, working to implement LoRa local communication without any infrastructure
I think it is a very promising new view open to many different applications/markets as very clearly explained in their site

Welcome in the world of at least one new protocol a year because the old one doesn’t fit use case X or Y or Z.

2 Likes

More specifically it’s a spec authored by an industry wide consortium of users, system manufacturers, software and network engineers and the company that sells the silicon amongst a great many others several of whom initially came together to work on LoRa-LoRa based communications back in 2013 & 2014 looking to solve many of the implementation and usage problems such instantiations thow up …and ended up engineering LoRaWAN :slight_smile: There FTFY :wink:

Lol, we know who actually wrote it by whose technology it happens to match and utterly rely upon

1 Like

Maybe, looks rather like a duplication of Flarm for a very niche set of outdoor applications with no end-point for the data.

I’d stick with the RadioHead library.

We’re not keen on posting across different forums - as this isn’t really a TTN application, can you continue over on the RAK forum rather than have several of us suffer from deja vu. Thanks.

1 Like