Our full technical support staff does not monitor this forum. If you need assistance from a member of our staff, please submit your question from the Ask a Question page.


Log in or register to post/reply in the forum.

CR1000 / RF407 Pakbus networking


jonny Apr 19, 2018 03:08 AM

We've got a project adding on a new datalogger to an existing site with the new logger being connected wirelessly to the existing logger. The "main" logger then has the IP link back to our loggernet server.

Our basic setup: 

[IPLink]--[CR1000(A)] -- <RF407>"""""""""(Radio Link)'''''''''''''''<RF407>--[CR1000(B)]

We were really after the configuration which would give us the most reliable configuration with a good amount of debugging info in case anything goes wrong. So we had it working with both radios set with these settings:

Active Interface: CS I/O, Protocol: Pakbus Node, Power Mode: 1Sec

We installed it on site recently but after working briefly(for a few hours) it now seems to have stopped. I was just wondering as there are quite a few modes what would be the best one to use in this case, as it's a little different to most of the examples? In Pakbus graph at the moment we can ping the RF407 attached to logger (A) but it's got a high latency 5000ms and every second try fails. We can't ping the other radio or logger.

Also, to get things working we needed to set the "Is router" tickboxes on the logger, but should this be done on both loggers in the network or just set in logger (A)?


jtrauntvein Apr 20, 2018 08:06 PM

My first suggestion is to model the network that you want with Network Planner and then look at the settings that it generates for you.  I suspect that the problem is occurring because of beacon or verification intervals settings.


Sam Apr 23, 2018 01:18 AM

When you set the RF407 to PakBus Node, you are making it a PakBus device / node on the network. Make sure that each of the RF407 radios has a unique PakBus address. (Also, the CR1000's must have unique Pakbus addresses).

Each of the CR1000's must be set as a PakBus router for you to communicate with both of the RF407 radios in Pakbus graph.

Only CR1000(A) must be set as a PakBus router for you to communicate through to CR1000(B).


jonny May 1, 2018 03:36 AM

Just a bit of an update we were back at site and found the radios (both ends) with TX and RX lights both flickering constantly. After giving the radios a reboot and after changing the beacon and verify intervals to 60 and 150 seconds (on the radios) respectively they linked back up.

After working for roughly a week though we've lost comms to the site again. The battery volts were good when contact was lost and we can't see anything else going wrong there. Through pakbus graph we can still ping and see the route to the local radio, but not the far end logger or radio. I can get through to the setting editor in the local radio and see it's RFSignal as -58 0. I believe the second number there should be the pakbus address but I'm not too sure it's the same as in device config as opposed to the setting editor.

The remote end is the same as well, except for the pakbus address. We're running the latest firmware v2 for both radios. If it makes a difference data is being sent roughly collected roughly every 10min. I have compared settings with what the network planner generates and it's pretty much equivalent except for we're using a pakbus node instead of the pakbus aware mode. We're just running out of ideas on why this keeps being so unreliable? It's at a very remote site and getting to it is reasonably difficult.

I've attached a copy of one of our radio configurations:

<?xml version="1.0"?>

<?xml-stylesheet type="text/xsl" href="file:///C:\Campbellsci\Lib\DevConfigLib\en\v2/summary.xsl"?>
<device-config device-type="67" major-version="0" minor-version="0" model-no="RF407 Series" serial-no="" timestamp="2018-05-01T14:42:47.881">
<setting id="85" name="Company">
<component name="Company" repeat-count="0">Campbell Scientific, Inc.&#10;</component>
</setting>
<setting id="86" name="Model">
<component name="Model" repeat-count="0">RF407 Series&#10;</component>
</setting>
<setting id="87" name="RFSignalLevel">
<component name="RFSignalLevel" repeat-count="0">-60 0&#10;</component>
</setting>
<setting id="88" name="BatteryVoltage">
<component name="BatteryVoltage" repeat-count="0">13325 mV&#10;</component>
</setting>
<setting id="89" name="NeighborsAllowed">
<component name="NeighborsAllowed" repeat-count="0">&#10;</component>
</setting>
<setting id="80" name="RF Hop Sequence">
<component name="RF Hop Sequence" repeat-count="0">0</component>
</setting>
<setting id="81" name="Network ID">
<component name="Network ID" repeat-count="0">1234</component>
</setting>
<setting id="82" name="Power Mode">
<component name="Power Mode" repeat-count="0">2</component>
</setting>
<setting id="83" name="RfPwrLvl407" />
<setting id="25" name="PakBus Address">
<component name="PakBus Address" repeat-count="0">170</component>
</setting>
<setting id="30" name="PakBus Beacon Interval">
<component name="PakBus Beacon Interval" repeat-count="0">60</component>
</setting>
<setting id="31" name="PakBus Verify Interval">
<component name="PakBus Verify Interval" repeat-count="0">150</component>
</setting>
<setting id="32" name="Central Router">
<component name="Central Router" repeat-count="0">0</component>
</setting>
<setting id="33" name="Neighbors Allowed" />
<setting id="70" name="Radio Configured As Router">
<component name="Radio Configured As Router" repeat-count="0">No&#10;</component>
</setting>
<setting id="71" name="Routes for Radio Configured as Router">
<component name="Routes for Radio Configured as Router" repeat-count="0">&#10;</component>
</setting>
<setting id="29" name="Operating System Version">
<component name="Operating System Version" repeat-count="0">2</component>
</setting>
<setting id="26" name="Radio Firmware Version">
<component name="Radio Firmware Version" repeat-count="0">32884</component>
</setting>
</device-config>


ariklee Jul 20, 2018 03:02 PM

Hi,

I am experiencing a similar issue with five CR300-RF407s in network with two CR6 and external RF407 radios. All radios are set to PakBus Aware, and two radios are routers. Communication has been off and on, but when we loose comm all it takes is a power cycle of the radio(s) and comm comes back online.

We lost communication with the CR6s last fall as winter was coming on and could not access the sites (very remote). I thought is was battery issues. Yesterday we visited the sites, and the CR6 had been collecting data all winter, so batteries were fine. One radio connected to a CR6 had both TX and RX lights on steady. The other radio connected to a CR6 had neither of the lights on.

Also, yesterday we added a "base station" site with consisted of new CR300-RF407, connected to an RV50, and used as a router. I had connection to the system for a couple hours (through the RV50), and could see loggers beyond. Then lost connection. I can connect to the RV50 through AceManager, but cannot ping or connect to the CR300-RF407 attached to it.

Two questions:

1. Does updating the OS in the CR300-RF407 also update the radio firmware to V2.0?

2. The new base station site is assigned Pakbus 1. My partner updated OS in the CR300-RF407 at the other sites, effectively resetting the Pakbus address at these sites to 1. Then Pakbus addresses were then changed back to their previous values. If they had been 1 momentarily (causing a situation where multiple devices had PB1), could this cause a lingering issue what we are seeing now (no comm) at all of the sites?

Thanks,

Eric


jonny Jul 23, 2018 02:05 AM

We never really got to the bottom of our issues. The radios have been up and running for a couple months now but they are still a bit of a worry. 

We tried quite a few different settings but it seemed it was quite easy to upset the radios with all the settings we tried. Things like getting table defs, reprogramming a logger or changing some of it's settings could get the radios into that fault state where the TX and RX lights are constantly flashing but they're not linked up. We did lower the maximum packet size from the 998 to 450 and maybe this has helped, we haven't had any issues since then but didn't have the time to try and break it. Once they're working they seem to be reliable but anything that causes a logger restart could cause the radios to go down.

Log in or register to post/reply in the forum.