Best Practices for Deploying the VoBo HL-1/GP-1 at Scale

HL-1 Use Case (3)

The VoBo is a LoRaWAN endpoint which bridges wired transmitters to a LoRaWAN network. The VoBo is sensor agnostic, able to read multiple input communication protocols, and therefore must be configured for the transmitter(s) it is reading. Because of the wide range of transmitters and their applications, we offer the following guide to the best practices for deploying VoBo products.

LoRaWAN Operation

Join Behavior: The CycleSubBands parameter determines if the VoBo will attempt to connect on subsequent frequency sub-bands (FSB) if it is unable to join on the channel set by the FreqSubBand parameter. The default setting for the parameter CycleSubBands=true, but we recommend that this parameter is set to false, turning this feature off if there is no possibility that the network FSB will be changed. The network gateways will be set to one FSB, determine the FSB in use and set the FreqSubBand parameter to the FSB number. The VoBo will only try to join on that FSB. Allowing it to cycle through FSBs will not improve its ability to join the network.

Analog Transmitters

Analog Units: The analog channels have the option to report in ADC counts or Engineering Units. Engineering Units is recommended because no post-processing is needed and the channel, value, and units are delivered in the payload, set EngUnitsEnable=true. When Engineering Units is enabled, each analog and digital input channel has a configuration parameter which enables the data to be transmitted. Only the channels which are being used should be enabled to transmit, so only the necessary payloads are sent.

Power For Multiple 4-20mA: When multiple 4-20mA sensors require power from the VoBo, the voltage setting must consider the current required to reach the full scale of the sensor(s). Refer to the chart of maximum output current for each voltage setting, the table is available in the VoBo GP-1 or HL-1 Installation Manuals. Since most 4-20mA sensors have a range of voltage they will operate at, reducing the voltage to allow more current may be necessary. Rule of thumb is to set the voltage at the midpoint of the range or slightly higher when possible, multiple sensors may require the voltage to be set lower in the range.

Power Time: The power time is the amount of time the power is applied to the sensor to take the measurement. This setting has a direct effect on battery life so the least amount of time to get a good measurement is desired. When testing, set the power time longer than expected to confirm everything is working and re-test at shorter time settings to find the optimal power time. Use the battery calculator to estimate battery life.

Modbus RTU Slave Devices

The VoBo provides a powerful means of collecting data from Modbus RTU enabled slave devices. Modbus slave device manufacturers are not standardized in how registers are organized on these devices and the data represented in the registers can be in various formats, some common types being unsigned integer, signed integer, 32-bit floating point (FP32), and hexadecimal. To further complicate things, there is no industry standardization of number type and register byte/word order from device to device. A strategy for Modbus payloads will account for the variability between devices and deliver payloads which can be decoded in a consistent manner.

Modbus Group Strategy

The following are recommendations for organizing Modbus groups.

  • Each group should be a single, complete data point, do not string multiple data points together in the same group. Multiple data points in a single group can make validating data and troubleshooting more difficult.
  • Single data points which are contained in multiple registers, 32-bit floating point are common and should be in a single group. When testing or troubleshooting to confirm the byte/word order is correct, the two registers must be in the same group. When connected locally with a configuration cable, the serial monitor can display the value of the two FP32 registers, confirming the register addresses and byte/word order is correct. The VoBo group configuration can byteswap and/or word-swap the registers to produce the correct value. When the correct value is seen in the serial monitor, it is straight forward combining the registers after the received payload is decoded.
  • Due to the different number types used by manufacturers (16-bit signed and unsigned, FP32, hexadecimal, etc), a strategy which assigns specific number types to a specific range of Modbus groups can be implemented. Modbus Generic Payloads (MbPayloadType=1) should be used with this strategy because the group and register number is contained in the payload and used to identify the number type of the data, and the type of post-processing needed to translate it correctly.
    • An example group strategy could be to always allocate 16-bit registers with unsigned integers to Groups 1 to 15 and allocate FP32 registers to Groups 16 to 30. The remaining Groups 31 to 41 could be used for other number types which may require decoding specific to the device. When the payload is received, the group number in the payload is used to direct the type of post-processing applied to that group data.

Determine Modbus Byte/Word Order for FP32 Data

With the Modbus slave device connected to the VoBo, and the VoBo connected locally to a computer through the configuration cable, use a terminal emulator such as Putty to view the operation of the VoBo and results of the Modbus device read.

  • In this example, the real value of the data point is known to be 146.
  • The VoBo is set to use Group 16 to read two 16-bit holding registers, 6406 and 6407, which
  • combined form a FP32 number.
  • As a starting point, no byte or word swap is applied to the Group configuration.
  • The result shown in the serial monitor is:
  • The value of 0.000 is not the correct value so the byte/word order will need to be swapped.
  • Re-configure Group 16 on the VoBo to perform a word swap by enabling the word swap parameter for the group. The result shown in the serial monitor is:.
  • The value of 146.000 shown in the serial menu is correct so the byte/word order for the registers is correct.
  • Note: The value of the FP32 number shown in the serial monitor is for testing and troubleshooting purposes, the VoBo transmits the individual registers in the payloads so the FP32 value must be constructed after the payload is received

Reconstruct Modbus Payload for FP32 Numbers

  • The VoBo’s Modbus payloads received at the LoRaWAN Network Server contain the register data and must be combined to generate an FP32 value.
  • If the serial monitor is correctly displaying the value of the Modbus Group, the combination of the registers to generate the correct value is known.
  • The below example is a decoded payload of the same data in the above example, as it is seen in an LNS.
  • Modbus Generic payload was selected so the group and register information is included in the payload.
  • In this case, the registers of interest are Group 11 registers 1 and 2.
  • To combine these registers, the Volley Boast decoder download has a utility function which can be inserted into the post-processing data stream.
  • The utility is the modbusToFloat_AB_CD_to_ABCD and will produce the correct value of 146.000.
  • The decoder utility functions can be found in the VoBo Payload Decoder download which is available at the Volley Boast Customer Portal. https://portal.volleyboast.com/CustomerLogin

Key Takeaway: Ensure that the value of FP32 register groups are correctly displaying the value in the serial monitor during initial setup so construction of the payload FP32 registers is straightforward.

Other Modbus Recommendations

Group Delay: Some Modbus slave devices require a short delay between read or write functions from the VoBo. We recommend that each Modbus group is configured with a 50msec group delay, MbGrpDelayG(x)=50 to start. If no delay is needed, the short delay will not adversely affect operation.

Payload Efficiency vs. Information: The two options for Modbus payload structures are Standard and Generic. The Standard payload is the most efficient, requiring the least number of payloads but having no reference to the source, requiring more diligence in post-processing mapping. The generic payload includes the group and register information but usually requires more payloads. Since it takes battery energy to transmit payloads, on applications where the fewest payloads and/or battery life is critical, Standard payloads are a better choice, otherwise Generic payloads are recommended.

Decoder: If the Volley Boast Payload Decoder is being used in post-processing, it is recommended that it is installed intact, without modification. The Volley Boast decoder is backward compatible with older firmware versions, and if installed intact, can be replaced more easily with new versions as they become available.

Modbus Register Map: When configuring the Modbus Groups, it is important to have a mapping of the group and register to the description of the data so that it can be correctly managed in postprocessing.

Configuration

The most efficient way to locally configure one or many VoBos is through the VoBoConfig Tool. Through the VoBoConfig Tool, a set of configuration parameters, developed for a specific application, can be saved in a CSV file for re-use. The saved configuration parameters can be easily transferred to other VoBos with the tool. The VoBoConfig Tool is a download available in the Downloads section of the Volley Boast Customer Portal.

The VoBoConfig Tool provides the user with two methods to configure a VoBo,

  1. Transferring CSV configuration files between the VoBo and a local computer.
  2. A GUI interface which can recover a configuration from a VoBo or start from default settings, make changes in the GUI, and send the updated parameters to the VoBo.

A Quick Start Guide for the tool is available in the Volley Boast Customer Portal.