Hi,
We have recently migrated our network of AWS sites to RF500M modems from the now legacy RF95A's.
The datalogger programs on all sites have been suitably adjusted to include SendData instructions. This works fine, and data is arriving at the RF base for collection by LoggerNet.
Our problem appears to be that the data sent from the dataloggers always arrives one interval late. For example, if the loggers are collecting data into a 10 minute table, and the RF base is on a 10 minute collection interval, the data will not be collected by LoggerNet until the next 10 minute interval. This still happens with suitable RF poll offset (1-2 minutes) and computer offset (3-4 minutes).
We'd ideally like to see the data arriving within the few minutes defined in the computer offset. i.e.:
0 minutes: datalogger calls CallTable()
0 minutes: datalogger calls SendData()
0 minutes: LoggerNet initiates RFBase-TD polling interval
1 minute: LoggerNet RF poll begins
~3 minutes: LoggerNet Computer offset begins -> data arrives.
But we're not seeing the data till the next interval - ~13 minutes after it's written to the data tables in the logger.
Are we missing something integral? does the datalogger need a few seconds to prepare the data in the table for SendData() to be effective? (as in, is the data not being sent in that first call, but is being sent 10 minutes later?)
I guess what we'd really like to know is, where is the delay happening? Is there any way that we can trace what's happening with the table entries? where they're being held up?
We observe this on direct stations (those that are able to be reached directly from the RFBase), as well as those using another RF500M site as a relay.
Cheers,
Mike.
I should add - we understand that the purpose of the RF poll offset is to account for minor variations in logger clocks, so that the poll is not started before a logger calls CallTable()/SendData() at the appropriate interval.
With this in mind, we still see the delay when the logger clocks are within 2-3 seconds of the clock on the LoggerNet PC. (i.e. well within the 1 minute we have set as the RF poll offset)
* Last updated by: mjb on 5/16/2011 @ 3:45 PM *
Mike,
After quickly scanning your posts, I think this is an implementation issue. It would be good to have a copy of your program and network map.
Here are some common pointers
----------------------------------------------------
Put the SendData instruction after the CallTable instruction. For example:
Public batt_volt
DataTable (Test,1,1000)
DataInterval (0,15,Sec,10)
Sample (1,batt_volt,FP2)
EndTable
BeginProg
Scan (1,Sec,0,0)
Battery (batt_volt)
CallTable Test
SendData (ComSDC7,0,4094,Test)
NextScan
EndProg
----------------------------------------------------
A common single site setup is
+ ComPort
-- RFBase-TD
---- RFRemote-PB
------ CR1000
Starting with the default settings, change the following
+ ComPort
-- ComPort Connection
+ RFBase-TD
-- Polling Interval = 1 to 20 minutes
-- RF Poll Offset = 10 s (depends on allowed station clock deviation)
-- Computer Offset = 20 s (RF Poll Offset + about 1 second per station in the network)
-- Enable Automated Clock check every 12 hours - allow 1s clock deviation
+ RFRemote-PB
-- Update Address
+ CR1000
-- Update PakBus Address
-- Enable Scheduled Collection
-- Collection Interval = 3 * RFBase polling interval
-- Number of primary retries = 0
-- Disable Secondary retries
-- Enable Reschedule on Data
-- Enable One Way Data Hole Collection
-- Enable Automated Clock check every 12 hours - allow 10s clock deviation
Sam,
Many thanks for your reply.
After quickly scanning your posts, I think this is an
implementation issue. It would be good to have a copy of
your program and network map.
Happy to perhaps provide those if we can discuss in email, have you got an address I can contact you on?
Unfortunately, I don't think it's an implementation issue, as we have exactly as you described (well, the program is a lot longer, and the RF500M network's a bit bigger).
Put the SendData instruction after the CallTable instruction.
Check. We are doing this.
A common single site setup is
*nod*
Starting with the default settings, change the following
Right, all followed with comments on variations:
+ RFBase-TD
-- Polling Interval = 1 to 20 minutes
-- RF Poll Offset = 10 s (depends on allowed station clock deviation)
-- Computer Offset = 20 s (RF Poll Offset + about 1 second per station in the network)
We currently have set:
polling: 5min
RF offset: 30sec
Computer offset: 1 min.
-- Enable Automated Clock check every 12 hours - allow 1s clock deviation
Aha, it hadn't registered to me that the RFBase-TD has a clock check. Is this to check the clock in the base itself? I've just rushed away to check the clock on the RFBase-TD in case that was the cause of the delay, but the check (which took a little while - what is it checking? the RFBase-TD is only on the serial port, it felt like an RF delay?) came back with both the station and loggernet in sync.
+ CR1000
-- ...
-- Enable Scheduled Collection
-- Collection Interval = 3 * RFBase polling interval
-- ...
-- Enable Reschedule on Data
We don't have scheduled collection enabled currently, as we are relying on the one-way data to deliver the data to us. Our observation is that scheduled collection over an RF500M network is like watching paint dry. Horrifically slow, and at times quite unreliable.
My understanding of the "Enable Reschedule on Data" is that the stations will not have collection performed unless one-way data has not been received for 3 * RFBase polling interval as you suggest?
-- Enable Automated Clock check every 12 hours - allow 10s clock deviation
Not currently enabled, but we'll enable it and all of your other suggested differences now to see if it helps.
* Last updated by: mjb on 5/23/2011 @ 9:11 PM *
Correct the RFBase keeps an internal clock.
This is an important concept because it is the RFBase that drives the RF polling - NOT LoggerNet.
If fact, once everything is setup and going you could unplug the serial cable to the RFbase and see that it continues to poll, receive, and buffer up data. Plug the cable back in and LoggerNet will suck up the data that was collected by the base. The RF500M has a small amount of memory / buffer so that it does not have to be in contact with LoggerNet at all times.
It is a good idea to check and set the logger clocks regularly. This way the clocks in the network are synced and data flows when you expect it to.
Though errors in absolute time will not prevent data flow and collection, timestamped data will seem to lag when the logger clock and the RFBase clock drift apart.
--
Your understanding of Reschedule on Data is correct. It's a last ditch effort for SendData networks. "You don't want to send me your data? We'll I'll try and ask for it to see if that works until MJB gets back to diagnose what's going on."
Yeah, I already had the impression and understanding that the RFBase drove the polling, but it totally hadn't occured to me it had a clock.
What clock was being checked when I clicked "Check Station Clock" in LoggerNet setup for the RFBase? the time came back as identical to LoggerNet, which would indicate that that clock was not the cause of the delay we are seeing?
Do all the RF500M's have clocks? (I guess that question seems odd - but since the RFBase is an RF500M, I assume the others in the network have clocks too). When they're connected to dataloggers, what keeps them in sync? the datalogger? or the clock sync from LoggerNet?
It is a good idea to check and set the logger clocks regularly. This way the clocks in the network are synced and data flows when you expect it to.
Right, with the RF poll offset we had, we were attempting to compensate for the up to 10 seconds drift we see on our loggers - and if the RFBase had the same time as LoggerNet as indicated above, then this should mean that the data polled for would be up to date.
Does the data from a logger that's a couple of hops away from the RFBase get back to LoggerNet all within a single polling interval? or does it take a couple of polls? My understanding is that it should come all the way back to the RFBase/LoggerNet in a single poll.
This segues nicely into the idea of the broadcasts that are sent defining the RF500M network. What sends this? LoggerNet via the RFBase, or the RFBase itself after LoggerNet has told it the topology? How often does this happen? Can it be forced? Recently we had an odd issue where 3 or 4 stations being repeated by an RF500M set up specifically as a data repeater were being very very difficult to reach. After we changed the topology to repeat via a weather station's RF500M on the same mountain, communication was restored. Several hours later, after moving the topology back to the data repeater worked fine, and communication was still working well.
This leads on to more interesting behaviour we have seen - we have a site that is currently not where it's supposed to be (for maintenance), and just happens to be about 40 metres from the RFBase (rather than 100km, and via a data repeater). Yet no matter what we do, we cannot communicate with the RF500M at all from the RFBase, although it was fine when it was still on the mountain (and in fact, we can't communicate with the duplicate "spare" station either, which is in the same location, but it has only just had its RF500M installed).
I apologise in advance for all the curly questions, but it helps immensely to have a good solid understanding of how the network works, and what effects certain actions will have.
"What clock was being checked when I clicked "Check Station Clock" in LoggerNet setup for the RFBase?"
The clock held by the base RF modem.
"and if the RFBase had the same time as LoggerNet as indicated above, then this should mean that the data polled for would be up to date."
The base does not ask the remotes for data from a particular time. It simply tells the network "Hey remote modems, send me what you have buffered up". It is up to the logger to make sure that data is put in the buffer before the poll occurs. If the logger clock is behind, it will push the data into the modem seconds/minutes (depending on clock drift severity) after the poll has occurred.
"My understanding is that it should come all the way back to the RFBase/LoggerNet in a single poll."
Correct. If the poll is successful (success is most commonly a function of RF path/signal strength). Local areas polled by repeaters upstream are polled in anticipation of being polled.
"This segues nicely ... "
LoggerNet sends the network map to the base. The base then tells the repeaters the portions of the network map that they need to know. This is done when LoggerNet pushes the map (Setup->Apply) or when the remotes request it (generally after a power cycle and a poll). The base says "Hey it's time". The remote says "Time for what? I don't know what's going on. Can you tell me?" The communication path is forced / set by the network map in Setup. The problem you described could be due to any number of factors - including RF interference on the mountain. Too often users jump to the conclusion that there is something wrong with the hardware. Too little are interference and small fade margins considered.
"This leads on to more interesting"
Make sure that the network map properly represents the new locations/configurations. Remember that when stations are really close to each other you need to dial back the ERP. Generally this is done with in-line RF attenuators. Too much power and you can swamp the radio receivers unless they automatically desensitize. The TD-RF check is your friend and should be the first test to perform. If a station has missed several polls it will be blacklisted. If it isn't responding then trying to talk to it is a waste of bandwidth so communications is blocked. The station has to successfully respond to a polling sequence before it is whitelisted again.
sutley [a-/t-] campbellsci dot com