¶ LoRaWAN
¶ Packets
¶ Where can I find the payload specifications?
Right here: payloads-uplinks, payloads-configs, payloads-commands, always fresh and up-to-date. Just use browser's Print function to print the files or export to pdf.
¶ How can I conveniently decode payloads?
For FW 1.1.x use ULl20xx_1_1_x_decoder.html
¶ Where can I get decoder for e.g TTN or Chirpstack?
Glad you asked. https://github.com/nasys/nas-codecs
¶ How do I know which firmware version my device is running?
Please check the first packet (boot_packet) sent after LoRaWAN join. Its from fPort 99. Use UL20xx_1_1_x_decoder.html to conveniently decode it.
¶ How do I reboot/rejoin my UL20xx device over LoRaWAN?
Please send FE to fPort 51 to reboot. For further information, see here.
¶ What is the average LoRaWAN data consumption?
Notice: the payload lengths are typical values. Different versions of UL20xx or various Drivers have different capabilities.
| DALI | Metering | Status, bytes | Status interval, h | Usage, bytes | Usage interval, h | Uplinks in month | Total data, kB |
|---|---|---|---|---|---|---|---|
| - | - | 12+4* | 1 | 11 | 0.5 | 2232 | 28.2 |
| - | yes | 12+4 | 1 | 19 | 0.5 | 2232 | 40,1 |
| yes | yes | 12+4 | 1 | 19 | 0.5 | 2232 | 40,1 |
| with D4i | yes | 12+4 | 1 | 41 | 0.5 | 2232 | 72,9 |
| with D4i | yes | 12+4 | 12 | 41 | 4 | 248 | 8,6 |
* Status length contains a broadcast address and dimming level if no addressed drivers are connected. if one addressed driver is connected, then the broadcast address is not sent, thus it is still +4 bytes.
¶ Why is the usage_packet not reporting power usage data?
All Zhaga devices and some older classic controllers don't have a metering chip. Some drivers support reporting measurements through D4i, however, which can be retrieved through the usage_packet.
¶ Communication between my controller and gateway seems to fail even when I've brought them into the same room for testing
Since LoRaWAN devices are made for long-range communications, having them too close to each other may actually oversaturate the channel, the signal is essentially ‘too loud’ for the gateway to understand what is being sent. You can try moving the gateway or controller into another room to decrease signal strength slightly.
¶ My 1.1.X device joins but incoming data is all scrambled
If your device joins the LoRa network but the data is scrambled, it's likely due to an incorrect application key in your LoRaServer configuration.
- Ensure the application key in your LoRaServer configuration matches the device's key.
- Restart your device after correction the key.
¶ Joining
¶ Why does my UL20xx device not join, but keeps only blinking a green LED?
There are many possible reasons to consider. Is there a live gateway nearby? Is the UL20xx provisioned in the LoRaWAN server? Are all keys entered correctly? You can try deleting and re-adding (re-provisioning) the UL20xx.
¶ Why are my lamps turning off after connecting to the network, using controllers with the newest firmware?
Once the driver joins the network it’ll fetch the current time from the network server and starts using the default factory calendar config automatically. When installation takes place during daytime, it’ll turn the light off since the default configuration settings only turn the lights on when it's dark. The status packet contains a dimming source which explains the reasons the lamp dims, turns on or off.
¶ The node seems to be connected to the network, but I can't send downlink message to the node?
Your network server may not know that your UL20xx is a Class C device.
The procedure should be similar on all networks. To fix it in TTN please delete the device from TTN, do a fresh install and definitely choose LoRa 1.1 and 1.1 revision B from dropdown lists. Next please click “Show advanced activation” settings and choose "Class C continuous". Re-enter the JoinEUI/AppEUI, DevEUI, AppKey and NwkKey where necessary. If we haven't provided you with NwkKey, please use AppKey for that. Please do a power cycle to force rejoin.
¶ We are power-cycling the controllers every day and some devices are taking an unusually long time to join?
While we understand the reasoning behind wanting to do so, do take into consideration that this is non-optimal and should be avoided if possible. For further information, see this question.
¶ I'm provisioning my device, which Regional Parameter should I use?
Choose the latest RP00x. For example, our controllers use LoRaWAN version 1.1, but this doesn't mean you should use RP001 Specification version 1.1. It might seem a bit counterintuitive (it did to us), but as an example RP002 Specification 1.0.4 is the latest version at the time of writing, which should be used.
¶ My network server supports only LoRaWAN version 1.0.x, but the device uses LoRaWAN 1.1. How to configure device in network server?
Our devices support fallback from version 1.1 to 1.0.x. To configure device for LoRaWAN version 1.0.x use the included NwkKey in the AppKey field. If no NwkKey is on the label or provided to you via email the device is probably using LoRaWAN version 1.0.3 and therefore the AppKey is used.
¶ Multicast
¶ Can LoRaWAN 1.1 and 1.0 devices coexist in the same Multicast group?
TBD.
¶ Configuration
¶ How to reset all configurations?
Please see clear_config_packet.
¶ What is boot_delay?
The default boot delay is 15 seconds (the device waits 0-15 seconds before the join procedure starts), this helps to reduce radio packet collisions when multiple devices are powered up simultaneously.
This interval should be increased in case of larger and denser deployments (50+ devices nearby). See boot_delay_config_packet.
¶ Can the green status LED be turned off?
Yes. See led_config_packet.
¶ What is the difference between active_energy and load_side_energy in the usage packet??
active_energy and active_power are measured at power inputs (either DALI driver or UL20xx). load_side_energy and load_side_power exclude the controller's consumption for UL20xx and DALI Bus and AUX supply consumption for DALI driver.
¶ Is it possible to configure a profile during the production process to be able to use the nodes in "default mode" before commissioning?
Yes, it is possible for larger orders. For custom requests for your order please contact sales@nasys.no for options.
¶ How to set up a fixed switch ON or switch OFF time for the information panel/advertising board or Christmas lights for example?
By parsing the timed status_packets. When setting status_interval to e.g. 10 minutes then the indication is a maximum of 10 minutes lagging. With the firmware version starting from the 1.1.2 release the device will immediately report any change in the dimming level.
¶ Setting default_dim_level does not work?
default_dim_level is active only when device does not have valid time (LoRaWAN not joined and no retained time from RTC) or there is no configuration (the UL20xx comes with default calendar which is activated as soon as a valid time becomes available).
¶ My configured profile acts n hours early/late?
The UL20xx is not yet timezone-aware, it uses UTC time. This means your profiles also need to be configured relative to UTC, not local time.
So if you want your profile to do something at 20:00 in e.g. GMT+1 timezone, you should configure the time for 21:00UTC.
Timezone support is planned in a future firmware release.
¶ I'm receiving an ‘unsupported_header’ error on fPort 99
In most cases, this means you're attempting to use legacy packet designations, from a 1.0.x Payload Structures sheet, for example. Some packet designations were changed for the 1.1.x firmware versions, meaning you should refer to our new payload structures on this Documentation site for the new designations.
¶ I've set LumaLink advertising to be active, but the blue LED isn't flashing
If your device has an active Lux sensor, the blue LED is disabled so the LED doesn't pollute the ambient light detected by the Lux sensor.
¶ I've sent many configurations to my device, but they're not received by the controller
In some cases, queueing up many configurations may result in a sort of congestion, causing the message queue not to be sent. Using TTN (and possibly some other providers) there's an option to ‘Replace queue’ instead of the usual ‘Append to queue’. Replacing might help in some cases.
¶ DALI
¶ DALI Driver not recognised?
Each DALI driver must be addressed (secondary short address). Is the driver supplied? Are both DALI wires connected?
Since FW ver 1.1.9, the UL20xx addresses unaddressed single DALI driver automatically at boot. For earlier firmware versions, see the address_dali_driver command.
¶ Lamp failure is not forwarded by the UL20xx?
The lamp_failure bit is updated once every 5 minutes and only works on addressed DALI drivers.
¶ What does hardware_error bit mean (FW 1.0.x)?
It indicates an internal communication error with a metering chip or RTC (real-time clock). This may occur in EMI noisy environment.
¶ I'm getting a dali_connection_error bit in the status field when the driver is connected?
Is the driver supplied through the UL20xx's relay? When all dimming sources are 0%, the relay will turn off and the DALI driver becomes unreachable.
¶ Which DALI standards are implemented?
It is part 351 compliant and D4i metering (parts 251, 252, 253) compliant.
¶ Is UL20xx DALI master?
The UL20xx functions only as a DALI master and provides DALI bus supply. UL203x senses for DALI bus voltage and provides only if needed. DALI drivers are slave.
¶ Why are there are no energy registers in usage_packet?
UL202x and UL203x may have internal energy metering capability (in usage_packet its address is FF), don't confuse this with DALI energy registers.
1. Does your driver support D4i or SR registers?
2. Is your driver addressed (short address)? Our controller can address the driver.
¶ Time
¶ What happens after an unexpected supply power cycle?
UL20xx will continue to run pre-configured profiles/calendar etc.
The time is kept using an onboard RTC clock with a super-capacitor supply. The profile/configuration will continue immediately (before LoRaWAN joins). All configurations are persisted in a flash.
¶ How does UL20xx behave, if mains power is turned on only during the night?
UL20xx will work as expected. At power-on, all devices start joining at the same time, so the network will be congested and many of the packets are jammed by peers.
If power cycling can not be avoided configuring boot_delay_config_packet is recommended (sets maximum random delay before the join). The default value is 15 seconds, but e.g. 10 minutes is recommended, depending on the density of the installation.
¶ If the mains power is turned on only during the night, is the UL20xx time lost?
UL20xx has hardware RTC (real-time clock) running off a super-capacitor for a few days which will keep UL20xx time.
¶ How and when does the UL20xx synchronise time?
By requesting time daily from the LoRaWAN server using DeviceTimeReq request. For legacy reasons on FW 1.0.x, it is also possible to send time_config_packet, but this is discouraged.
DeviceTimeReq is sent with the first packet after joining (boot_packet) and then in 24h intervals. If RTC has retained time, the time request right after joining is postponed for 1 h.
¶ Why does DeviceTimeReq not seem to work?
Please double-check that the UL20xx has been provisioned to use LoRaMAC 1.0.3a or higher (earlier versions do not support DevicTimeReq). See provisioning for more details.
¶ Is it possible to set the time in profiles in local time?
LoRaMAC DeviceTimeReq is using GPS Time format (from time servers), so it is not aware of local time, summer times etc. We are planning on implementing this, however.
¶ How does the UL20xx's calendar know sunset times without setting GPS coordinates?
It doesn't. EU868 region's default coordinates are set to be in the middle of Europe for the device to behave somewhat sensibly in most places out of the box. Please use calendar_config_packet to set your actual coordinates.
¶ Is there workaround if we are struggling to synchronise time due to weak network?
Please see time_config_packet.
¶ How do I know which zenith angles to use when setting sunrise_steps and sunset_steps?
Below is a screenshot from timeanddate.com, showing twilight times for Nice, France, with added zenith angle ranges. As is natural, the actual times and durations of the different twilight designations vary greatly based on your location and the time of year. This means the best way to set dynamic, yet reliable timings is to use zenith angles. For more information on these different types of twilights and what they represent, see this article on timeanddate.com.
If you'd like to set your lights to 25% just between civil and nautical twilight, 50% at nautical twilight and 100% at astronomical twilight, for example, you'd set the zenith angles to 93°, 96° and 102° respectively.
¶ Firmware Upgrading
¶ How to perform firmware upgrades?
For regular updates see firmware dfu-guide
Update from 1.0.x to 1.1.x:
- join as LoRaWAN 1.0.3 device (if not joined already)
- follow the dfu-guide
- re-provision the device as LoRaWAN 1.1 device, if applicable. (use AppKey twice for AppKey and NwkKey, 1.0.x devices don't have separate NwkKey).
¶ Which hardware is eligible for FW 1.1.x upgrade?
All devices running FW 1.0.x.
¶ What has changed in FW 1.1.x?
DALI D4i energy registers, LoRaWAN 1.1, refactored astronomical calendar and profiles, new packet structures. See more on /lcu/fw-changelog.
¶ How long does DFU take?
Firmware flashing itself takes <20 sec in most cases. Sending the device to bootloader mode, and selecting the device, firmware etc takes more time.
¶ How far can one perform DFU?
It depends on several factors, but mostly on whether there are other metal objects around the device. We have successfully managed to update a fleet mounted on top of 8m high steel poles from ground level.
¶ Can I perform a firmware upgrade via LoRaWAN?
Upgrade via LoRaWAN is not supported due to LoRaWAN's very low data bandwidth.
¶ When updating firmware from 1.0.x to 1.1.x I noticed that I also had to change the LoRaWAN stack to 1.1 which requires additional NwkKey. How can I get that?
1.0.x has no NwkKey. In cases when you haven't been provided with NwkKey by NAS, please use AppKey for both NwkKey and AppKey.
¶ From where we can get the Firmware for an update?
Please contact sales@nasys.no to get the firmware file.
¶ I'm getting a ‘Can not create firmware’ error, what to do?
On some iOS devices, it is a known bug that selecting a file through nRF Toolbox might cause an error, even when the firmware selected is valid. If you're experiencing this issue, start the DFU process by navigating to the firmware file in your Files app, select Share and then choose nRF Toolbox. This will allow the nRF Toolbox app to read the DFU file.