Questions we actually get asked.

Sensor nodes where your instruments are, relay nodes to carry their traffic, and one gateway that has a connection to the outside world. The gateway is the only device that needs backhaul.

All three are the same hardware in different configurations, so a site is one part number to build, stock and repair.

No. Nodes carry SDI-12, RS-485, two analog inputs and a switched excitation channel, which covers most of what field stations already run. The point is to connect the probes you own rather than to sell you new ones.

The ports are Phoenix Contact headers, and more than 100 Phoenix Contact connector types fit them, so an existing cable usually needs the right plug rather than a new sensor.

A satellite link is priced per station, so the cost of instrumenting a site densely scales with the number of stations. Here the nodes relay to each other and share a single uplink, so adding another sensor costs a sensor.

Its neighbours notice the silence and reroute. Every node keeps a list of the other relays it has heard from, so it promotes one of them and re-registers without anyone visiting the site. What you lose is that node's own readings, not the rest of the network.

Every report carries diagnostics alongside the measurement: pack voltage and state of charge, internal temperature, per-port sensor fault flags, and signal quality for each hop. A node degrading is visible before it goes silent.

Not yet, and we would rather say so. The hardware has been validated in a climate chamber at DTU to -40°C, where over 98% of about 19,600 packets were acknowledged and the crystal clock held to 0.03 ppm.

There has been no field deployment. The first one is planned for summer 2027.

A fair question and we will not pretend it away. What we can say is that the hardware is built from widely available parts rather than anything exotic, and a deployment is a single part number. We are seven people at DTU Skylab, and the honest answer is that we are early. Ask us directly and we will tell you where we actually are.

Long enough that it is set by how often you report rather than by radio activity, because the nodes sleep between scheduled slots instead of listening.

Our design target for the V2 node is 2 to 5 years, depending on how often you report. It is modelled from component behaviour, not yet observed across a season in the field, and we will replace it with a measurement after the first deployment. Ask and we will share the model and its assumptions.

Our design target is 5 to 15 km per hop, and terrain decides where in that range a link lands. Obstructed mountain terrain behaves very differently from an open corridor. The figure is modelled, not measured in the field, so tell us about your site and we will work through it with you.

No. The nodes use the 868 MHz ETSI M-band, which is licence-free across the EU and Greenland. The one percent duty cycle limit is enforced in the firmware rather than left as something the operator has to remember.

Winter harvesting yield is effectively zero for months, so the node has to survive on its pack alone through that period. That is the case the design is sized around, and it is why the effort went into sleep current rather than into a bigger panel.

Not yet. The second hardware revision was ordered in September 2026 after a full test campaign on the first, and there is no product for sale.

If you are planning a deployment, that is exactly the conversation worth having now. Tell us about your site.

The intent is a serviced subscription rather than a box sale: you swap a failed node in the field and it gets repaired centrally. That is the model we are building toward, and the details are not fixed. If you have a view on what would work for a grant-funded programme, we would like to hear it.

Seven people, formed at DTU X-Tech in spring 2026 and now in the DTU Skylab Incubator. There is more on the about page.