Introducing Congress - the LoRa-as-a-service...service!

What is it?

You probably wonder “what’s this Congress you are talking about?” just. Since the raven is our mascot we googled around a bit and settled on Congress as in “a congress of ravens”. It is - in short - a lora-as-a-service that we’ve built over the last year.

Where is it?

The console can be found at https://lora.engineering/ – register an account with Telenor CONNECT and it’s ready to use.

What does it cost?

Absolutely nothing, at least for now. We might charge for bigger projects later but right now we are just figuring out what to do with the service and as long as it is in open beta we won’t charge for it. It doesn’t come with any guarantees or promises though. We’ll keep it running for as long as we have to.

Right now there’s only one site running it in Ireland. If you run a gateway on another continent you might experience issues when using OTAA devices and acknowledging messages since the network latency makes it impossible to reach the receive window in time. If there’s demand for servers in the U.S. or in sia we can set up independent servers elsewhere in the world.

How do I get started?

There’s probably no coverage at your location right now but fortunately it is simple to get your own gateway up and running. Get a suitable piece of hardware, register it in the console and launch the packet forwarder. Point it to api.lora.telenor.io port 8000 and you are ready to go. The documentation site has more details on getting a gateway up and running.

There’s quite a few LoRa devices you can play with out there and as long as it supports LoRaWAN 1.0 or 1.1 on one of the supported bands it should work.

Features

  • Both OTAA (over-the-air-activated) and ABP (activation by personalization) devices are supported
  • Up- and downstream messages to devices
  • EU863-870 band (for now - more to come!)
  • Websocket outputs
  • MQTT outputs
  • AWS IoT outputs
  • User-defined tags on applications, devices and gateways
  • REST API to manage your devices
  • Copy and paste provisioning code for LMiC, MyNewt and LoPy devices.
  • Read-only/read-write tokens for API access

API

The API is relatively simple and the documentation can be found at https://docs.lora.engineering/.

What’s missing and what’s next?

Everything isn’t perfect (that’s the “beta” part of “open beta”) and we already have a substantial list of issues we’d like to improve and implement. This is just a few issues we might be looking into in the near future:

  • Support for more bands (US902-928, AU915-928, CN779-787, AS923 and KR920-923). Additional bands shold be relatively easy to set up. If someone is interested we’ll be happy to add more bands.
  • Custom packet forwarder. The default Semtech packet forwarder works for simple use cases but it is hard to tell what the latency is to the gateway which forces us to make assumptions with regard to round trip times and the frequencies must be configured on the gateway side which is both confusing, annoying and error prone.
  • Support for adaptive data rates. This is fairly simple to implement but we haven’t gottend around to it yet. Enabling ADR would also conserve battery power for the devices.
  • Frequency management. Right now the backend server is happily receiving data from devices without worrying about the frequencies they are using. Ideally the server should move devices over to additional frequencies when the join frequencies becomes crowded.
  • Outputs to Google Cloud IoT and Microsoft Azure IoT as well as AQMP and web hooks would be nice.

What are your long term plans?

To be perfectly honest: We don’t know. We might make a serious product out of it (but we’ll still keep it free for development) or we might just keep it for testing and development. If we decide to shut down the service we’ll open source everything so you (or someone else) can keep on using it.

Can I use it as part of my nuclear reactor monitoring system?

Probably not. At least let us know before you put it into production! We are running the server on a best-effort basis so the server might go down in the middle of the night without us noticing right away or we might drop a packet or two from the packet forwarder (hint: the packet forwarder uses UDP) and if you are using this to monitor your nuclear reactor that could be bad. Really bad.

Do you recommend any particular hardware for the devices?

Sure thing. We’ve got the EE-02 module right here. We’ve only tested it on the EU868 and US915 bands but it should work just fine on other bands as well.

Are you just making up questions as you are going along?

Yes. You can tell, can’t you? Now go play with it!