Network coverage for Weather Stations

IMHO a question of type chicken&egg:

  1. nodes can only be linked if active Gateways in range
  2. providing a Gateway to the public is more appealing if other nodes are using it, besides your own.
  3. Most device-users not unwilling, but preferring ‘simple’ interface.
    Therefore a node should ideally be plug&play.

Meteostations in the countryside being obvious candidates, trying to promote LoraWAN in that context, but 3rd aspect usually inhibiting.
Looking at the TTNmapper-maps for my neighbourhood (= Hengelo-North), see several Gateways in this suburb, none in other parts of Hengelo, nor in the countryside,
and in those maps nodes mostly appearing on roads and on the highways, probably from vehicles.
Same for adjacent villages/towns/cities:
only Enschede and Oldenzaal seem more active.
Enschede obviously due to the presence of the TechnicalUniversity
(but last TTN-meet is ages ago).
Oldenzaal active possibly due to a Gateway nicely located in the City-Center.
One of the most favorably located Gateways in Hengelo (high in a high IT-building close to the junction A35&A1) has stopped last year:
an IT-company switching off a data-gateway to me is a doubtful sign …

That is to be expected as the only nodes shown would be tracker nodes and those usually move around. Tracking a static node is not very useful. You could acquire one and walk around you town, that is something a lot of people did in the early days of TTN. (Yes, guilty as well)

It might be as simple as the hardware failing and no budget/use-case to replace it. I’ve had several gateways fail by now and I’m not replacing all of them because of the effort involved. (Replacement hardware is sitting in the attic so that isn’t the issue for me)

I’m still looking at the how’s of LW for PWS, you are preaching to the choir here but fundamentally, LW is not a retail / domestic / non-technical system. It was never intended to be and there is no funding available for anyone to turn it in to such a thing.

The very best that can occur is for each use case a step by step setup guide is created for the diligent & methodical to use.

It is deeply unlikely to become something that turns up in the post, you switch it on et voila, instant LW.

Others will help you out, but you need to lead the charge on this, frequent musings about how wonderful it would be to have it plug & play is likely to put people off.

Jac,

Agreed, but (as other indicator) looking at the througput of my own Gateway (central in a suburb) almost no traffic visible other than my own nodes.
That IT-company with stopped gateway is usually rather keen at advertising it’s presence & capabilities …

As stated in earlier message an aspect either attracting or offending users is the simplicity of interface.
Example of very favorite meteo-setup-interface is Meteobridge, which provides a meteostation with very easy interface to outside world.
That device is preprogrammed at one side for many types of weatherstations, and on the other side provides a big catalogue of preprogrammed interfaces for data-destinations:
if somebody could provide a compatible LoraWAN-Node, it might be the long range communication channel many people are looking for.
Although meteo-novices probably will not have the required budget,
do not underestimate the funds spent by ‘serious’ meteo-people!
On the other hand, the cost of a NBIOT-configuration as explained in this description (as alternative for LoraWAN at this description), probably is exceeding the acceptance-threshold.

The one mounted on top of the school where I teach (in Veenendaal) has seen 100k uplinks in 6 days - one nearby from the Waterschap saw 360k in 13 days. Maybe 5k of those is from Waterschap + ‘my’ boxes, but there are many many people active around here apparently.

I could, but I don’t have the domain knowledge of a dedicated-Metro so until someone says what’s needed in detail it’s all on pause.

How much is “required budget”? How do you know they probably won’t have it, whilst they binge on their Just-Eat deliveries and admire their new shiny Android phone (as per potential client last week trying to haggle on price).

As soon as you stop being vague, the sooner we can move forward.

Examples of ‘usual’ ROM-budgets for meteo setups:

  • ‘novice’ will seldomly spent more than Euro400 for a whole setup, and usually will try to settle for less.
  • ‘serious’ meteo-setup e.g. with devices from Davis will be approaching or exceeding Euro1000~1500, with Euro200~500 as addition for a single Meteobridge (=MB), depending on MB-configuration. MB is ‘bridge’ to internet via Ethernet-LAN and/or via WLAN.

Extension January23, 2025:
For communication ranges towards internet beyond coverage of a compatible (3G/4G)-Mifi-router, the Meteobridge is offered in NBIOT-version.
However, a setup with dual MeteobridgePro as described for NBIOT-configuration will escessively raise the budget mentioned above, and seems only affordable for professional meteo-application.
=> chance for LoraWAN as alternative means for non-professional or semi-professional longer range communication-tunnel, if cost of an MB-interface-Node < Euro100?
With that MB-interface-Node acting as entry for ‘transparant tunnel’ over LoraWAN to the internet-end,
with required payload-formatter and payload-decoder provided by ‘volunteer’-activity.
[That Euro100 is guesstimate in relation to cost of a good Mifi-router incl. linked provider-subscription.]

Why no integration of Meteobridge inside a LoraWAN-Node?
Replication by outsiders of the contents of Meteobridge probably hell of job, because all those peculiar links to weatherstations and to data-destinations, besides all other functions.
Therefore better not to be touched, and to be accepted as black box …

In the provinces Gelderland and Utrecht are serious ideas to extend the network significantly, and use it for monitoring water, climate, environment etcetera. Initiated by the governments to accelerate their own initiatives and initiatives of other parties.

1 Like

If Waterschappen [= Waterboards] would take such initiative, probably meteo-amateurs in those regions will be glad to join, because it will generate ‘volume of comparable applications’ and it mutually improves coverage of the sensor networks.
In some areas cooperation already applies:
HetWeerActueel over internet reads stations from Scheldestromen en from WRIJ.
From own experience (as moderator of that forum) know that the interfacing always is a ‘challenging’ aspect.

They already are.

But they don’t have the domain knowledge of PWS which no one seems to be able to supply to the technical experts. And I don’t think they are up for writing end-user docs either. Until they occur, you can not make progress, regardless of the number of posts you make.

For me Scheldestromen and Rijn&IJssel are Waterboards in the Netherlands which are well aware what they require and they well define their requirements.
Rijn&IJssel develops & monitors a network of > 400 raingauges with very clever software.
Reading his message also Vallei&Veluwe might move along that path.

  • As usual - ‘individual’ persons within those organisations with practical knowledge & vision of PWS-application are in the lead.
    But you are correct:
    it is a different world from meteo and relative to networking, very application-based,
    and obviously a ‘culturally useful’ interface translation must be made.
    In direct contact with those persons trying to contribute to that translation for mutual benefit,
    but 3 waterboards reacting out of the group of 21 is a very small base.
    Same is applicable for agricultural application and similar:
    those users see a long range network as a handy tool and are not interested in the technical details. Proposal to them must be very simple …

Whilst the opener was related to general TTN in NL network coverage, this aspect of discussion was dwarfing the original topic so it’s been moved.

@Toulon7559, this is the second time I’ve split the thread on your behalf. As you are a forum moderator you will know that this sort of admin isn’t a good use of our time.

Documenting your aspirations are fine but without any tangible requirements this isn’t likely to go anywhere anytime soon.

It’s a case of ‘ever thus’… often a few early movers need to get going with an application or use case, document requirements and objectives (per Nick’s repeat suggestion!), then try a few approaches to see what works and what is practical (people are often suprised to find that original requirements lacked ambition and even more can be done once network/application solution in place), then - most importantly - document or otherwise demonstrate what has been done/achieved and start to roll out/offer to others with use case studies, TTN Forum Labs (remember those) that others might follow and lobby for others to adopt/adapt as appropriate. Domain knowledge (inherent or acquired via the practical implementation process) and the sharing of that helps smooth the path for followers and ideally moves the process to a ‘cookie-cutter’ like process speeding and easing other deployments.

So 3 out of 21(*) is a good starting point; JFDI then publish and replicate! :slight_smile: If the other waterbaords see the value (they wont know if you dont tell them!) they will surely follow… :wink:

(*) Remember that is just in .NL - there are others around the world using LoRaWAN/TTN/TTI for these kind of applications so the potential pool and the established knowledge base likely must larger than you anticipate.

Watching this thread/discussion I am reminded of early experiments with LoRa (proprietary/simple P2P/simple star-net deployments) in the the 1st 1-3 years after launch (i.e. long before LoRaWAN became a thing) looking at e.g. Vinyard monitoring…that evolved in 2015-2018 to be a ‘thing’ for larger scale LoRaWAN deployments and now there are dozens… hundreds… of plantings across many many Vinyards and grower groups across the world. It just needed a few early adopters and advocates calling this out and showing what could be done… :+1: (Some even went on to form specific companies servicing the sector)

Initiatives with potential pop up from a variety of corners:
Example is Behoud de parel, linked to Samenmeten
Difficulty is how to ‘join’ them with other similar activities, to create ‘volume/body’.