by Robert Hyatt | Updated: 12/20/2023 | Comments: 1
In this blog article, I’ll share with you the next five tips (6 through 10) that you can use to help troubleshoot your radio frequency (RF) networks. This is the second article in our three-part series. If you missed my first article or want to review it again, please read Tips to Troubleshoot and Optimize Large RF Networks: Part 1.
The best practice is to use neighbor lists instead of beaconing in most radios. Beaconing is a common form of initiating a hello exchange between PakBus devices. It establishes two devices as PakBus neighbors, enabling them to communicate with one another. A beacon happens at a specific time interval, such as every 60 seconds, to keep the communications path available between two neighbor devices. If every device that is connected to a radio is beaconing at the same time on a large radio network, it can create unnecessary congestion between devices. The best practice is to turn off beaconing for devices that don’t need it. If two devices are communicating with one another, only one needs to have a neighbor list or beacon for the other to communicate with it.
In practice, if each station can communicate directly with the base (centralized) station data logger, then only the base station data logger needs to beacon. In this situation, setting the beacon interval for the base station to one hour should be sufficient. If other leaf data loggers must communicate through another data logger to reach the base station, they should use a neighbor list to communicate with the data logger (neighbor) next to them instead of beaconing.
To turn the beacon setting off and use a neighbor list instead, use the Device Configuration Utility.
Next, set up a neighbor list. The allowed neighbor list is set up on the same tab on the right.
When data collection for every station is scheduled to take place at the same time with large radio networks, bandwidth limitations could keep multiple stations from communicating simultaneously. To avoid this, stagger the data collection among stations.
Use the LoggerNet Setup > Schedule > Time field to stagger the data collection. For example, setting the Time to 12:03:00 AM will cause LoggerNet to initiate communications to this specific station three minutes after the hour. By setting the next data logger to six minutes after the hour, the two are likely to have successful data collection. The actual Time you use may be different. Ensure there is enough time to get through the entire network data collection schedule before the first station is contacted again.
Stagger callback times by using TimeIntoInterval() to trigger SendData() instructions. For more information, check out our How to Use Callback Capability So Your Data Logger Initiates Data Retrieval blog article.
Another alternative is to aggregate data from all stations into one base data logger. Use GetVariables() or GetDataRecord() in the base data logger to pull values from each of the remote stations. Then use LoggerNet to collect data from the base data logger. This reduces radio network congestion because the base data logger instructions trigger one at a time. When the first instruction ends, the second begins, and so on. This reduces radio congestion because all the stations are not trying to send data at the same time.
Reduce the data logger PakBus packet size to less than the radio packet size. PakBus packets larger than the radio packet size are split up, which creates more radio traffic and increases the number of packets that must be retransmitted if a packet is lost. The default RF407-series radio packet size is 256 bytes. Because the 256-byte packet needs to include space for packet header information—imagine putting an envelope inside another envelope to send—200 bytes is a safe size for the data logger PakBus packets that will go inside the radio packets. The default RF451/RF452 packet size is 234 bytes.
Use the Device Configuration Utility to change the PakBus packet size in your data logger. Change the Max Packet Size on the Settings Editor > Advanced tab.
To change the setting in LoggerNet, select your data logger on the Setup screen. On the Hardware tab, set the Maximum Packet Size to 200.
Use directional (Yagi) antennas where possible. Generally, base stations use omni-directional antennas because they communicate with stations in multiple directions. Other stations that are only communicating with a base station or with a single neighbor can use directional antennas. Using a directional antenna has two advantages. First, the directional antenna power is focused, allowing it to go greater distances. Second, limiting the direction the antenna transmits helps reduce interference elsewhere.
If another radio network of the same type is nearby (such as another RF407-series radio network), consider using different Radio Network IDs and RF Hop Sequences. This will prevent the two networks from joining and minimize interference. In RF451/452 radios, the RF Hop Sequence is called the Frequency Key.
For RF407-series radios, these settings are found on the Device Configuration Utility > Main tab.
For RF450/451/452 radios, these settings are found on the Device Configuration Utility > Deployment tab.
I hope you found these tips helpful. If you have any questions or comments, please post them below. Remember to look for the next blog article in this series for more tips to troubleshoot and optimize your large RF networks.
Comments
kcopeland | 11/10/2016 at 02:32 PM
This is a good function! If I understand correctly, this does not help if your program has a compilation error. We've recently run into a problem with functions specific to OS29 are being sent to remote loggers with OS27.04 and the onboard compiler fails and our port controlled modem does not turn back on. We need a way to run a program when compile fails.
sonoautomated | 11/11/2016 at 03:49 PM
Mr. Copeland, That is indeed another exception, thanks for that input. I will submit this to engineering to see what can be done. If something does come about, you can be sure it will be on a new OS that you will need to upload. :) --Cheers my friend.
thinkitcodeit | 11/17/2016 at 02:30 AM
You could implement a default.cr1 (or cr# depending on the logger type) which restores communications. In the event of a program failing to compile or run and in the event after a power cycle there is no running program then the datalogger will automatically run this default program for you. It is a great way to put some basic comms startup code in that is tried and tested to ensure you get access back.
luisfgranada | 06/07/2018 at 06:56 AM
Hello, I have a problem when using this instruction. The program is the following:
Public NumFiles
Public Files(10) As String
Const MeasurementProgram = "CPU:Template.CR1"
Dim i
BeginProg
Scan (1,Sec,3,0)
NumFiles = FileList("CPU",Files())
For i = 1 To NumFiles
If StrComp(Files(i),MeasurementProgram) = 0 Then
RunProgram (MeasurementProgram,4)
EndIf
Next i
NextScan
EndProg
What I do is to look in the memory "CPU" for a particular program. In the example (CPU:Template.CR1). If it founds it, then try to run it. The problem is that if the program is not in the memory the instruction RunProgram should not run (beacause is in the IF loop) but it does. I have tested the loop and is fine. Could you help?
Thanks
sonoautomated | 06/07/2018 at 08:45 AM
Dear Luisfgranada,
On a logger I just wiped clean with the latest OS, I was not able to replicate your problem with my Test.CR1 program.
But then I decided to upload a program named “Template.cr1”, the RunProgram instruction in my Test.CR1 program would look for it, and as expected, it found it. So rather than deleting the Template.CR1, I decided to hide it using the FileManage instruction. So at this point, the File Control Dialog Box no longer had a file called Template.cr1 listed, but when I ran my Test.cr1, program it still found the file called Template.CR1 and began running it instead; As it should have.
Is it possible that you have a hidden program that you can’t see? This may be the reason the RunProgram instruction is finding this file you think does not exist. If this is the case, you have at least two options. 1- You may use the FileManage instruction to delete that hidden file. 2- You may upload the lasted OS to the logger. Before updating your logger with the latest OS, please remember to download any data and programs you might need, and maybe do a full logger backup. Backing up your logger is always a clever idea and can be done from Device Configuration Utility.
I hope this has been helpful. Please let me know if you have any more questions.
Please log in or register to comment.