How to test applications and devices?

How to get started
1

Good Morning

Another newbie question here: What is the recommended practice to test a new application and new devices?

  • For applications, is there a “test” TTN where I can register my application under test and inject messages from simulated sensors? I know about the “simulate uplink” feature in the TTN console, but this one seems to work on the “production” network, and appears rather inflexible. I’m looking for a place to hook up simulated devices that I can control myself via code – e.g., from within some CI pipeline. The goal would be to simulate all sorts of valid and invalid device data my application has to deal with, and also simulate metadata like spreading factor and RSSI that my application might want to respond to. Does this sound reasonable, or am I misunderstanding how TTN application development works? I’m coming from enterprise applications, where things might be a little different.
  • For devices, is there a “test” network where I can register a device without the actual LoRa transmission; e.g., tunnel the LoRa message through TCP/IP or even some HTTP layer, so that I can do quick iterations developing the device software without polluting the scarce spectrum, and without being restricted by the production network’s duty cycle and FUP? Or am I misunderstanding how to best develop devices?

Thanks very much!
Uli

1 Like
2

No

No

Yes

TTN server side infrastructure is provided free of charge by TTI and the majority of gateways are provided by companies & individuals to support this.

Duplicating such infrastructure for testing purposes would be far too onerous to even contemplate.

But with the benefit of your own gateway and setup either a TTN instance or Chirpstack, you can create your own environment for testing.

A device/node/mote shouldn’t have too much going on - so the code base is simple, reliable and conducive to low power. If a sensor sends a 99 instead of the 42, that’s your server application problem - if the sensor does this regularly such that you have to code for it on the device to reset the sensor, find a better sensor. You’ll never debug all potential field glitches before deployment.

Much of the device testing can be done right up to the transmission and instead appear as a debug string. The LoRa MAC software & radio is somewhat of a closed box that most don’t want to mess with.

And for the application, you can simulate the output from TTN via a few lines of Python as MQTT or HTTP integrations.