BAsed on suggestions from a previous forum discussion I am trying to change my NL100 to PAKBUS from TCPser.
The system uses loggernet 3.4 to connect via Ethernet to the NL100, from there the RS-232 is connected to a freewave radio. On the other end are a several loggers connected to individual freewaves.
I followed the setup instructions from the NL100 manual but am not able to connect to any loggers, the status monitor does show me connecting to the PAKBUS Port. Any ideas, if the following setup correct?
Thanks
These are the settings I used:
TLINK: disabled
RS485: disabled
CS I/O: disabled
RS232: PAKBUS
bps: 9600
beacon: 0
verify: 0
RS232 neighbor: 0
Ehternet: Enabled
etc. etc.
PAKBUS address 4093
Clock: 0
Routers: 0
PakBus/TCP server: enabled
port number: 6785
PakBus/TCP client: disabled
Modbus/tcp : diabled
telnet ip 23
password: *********
Devconfig code: 0
OK, so I have been able to connect to stations that I put in my neighbor list. the manual states that having a neighbor list of 0 will allow the NL100 to connect to whatever PAKBUS loggers it sees. This was not the case for me.
However when I telnet in I am not able to enter more than 5 or so PAKBUS addresses and I have about 23 to enter. Any ideas on this. I am going to try putting in a range of addresses, say 1-2000 and see if that works.
Well, that didn't work, the NL100 froze up. I'll try entering them manually from device config.
Oh well, It's not frozen anymore but I had to set the neighbor list back to 0. Any ideas here folks?
If you Telnet into the NL100 and enter the "t" command it will list its routing table. Are there any neighbors listed? Probably not. My guess (need more details for more than a guess) is that neither the dataloggers or the NL100 are set to beacon so the NL100 functioning as a PakBus router never learns about its neighbors.
Additional observations:
I'm wondering why you don't have the Freewave and NL100 RS232 port set to 115k instead of 9600 bps.
I'm also wondering why you used PakBus address 4093 for the PakBus address of the NL100. That's the address our PC400 software uses by default.
Skip the neighbor list for now and see if a 60 second beacon from the NL100 gets your stations into the NL100s routing table.
Hi, thanks for the response.
I did change the NL100 PAKBUS ID to 678 (the default)
the "t" only lists loggernet (4094) and one station ID (1)
I have the port set to 9600 b/c all of our loggers are CR10X-PB.
I changed the beaconing back to 60 seconds as well.
I need to wait until the remote station's radios are powered on at the top of the hour and see how that goes.
OK, I see progress now.
data was collected from at least half of the sites this hour. Let's give it a few hours and see what happens.
Thanks
> I have the port set to 9600 b/c all of our loggers are CR10X-PB.
The FreeWave radio baud rates only apply to the physical serial connection at the radio, and have no relationship to or effect on the rate at the base radio. I.e., the radio's transport protocol completely buffers the communications. So, if desired, the base radio can be set to talk to the NL100 at 115K regardless of settings at the other end.
I don't have anything to offer on the problem, though, as we haven't used FreeWaves in the "multi-point" mode.
If the remote radios are only being powered up once an hour there are going to be some issues to deal with.
With a beacon interval of 60 and verify interval of 0 in the NL100, the verify interval will actually be 2.5 times the beacon interval. That means the NL100 will drop the remote dataloggers from its routing table within 150 seconds after the station's radio has been turned off. When the radios are turned back on the attached dataloggers need to be rediscovered by the NL100 via the beacon interval and that may take a minute or more. In that kind of a scenario you better not try to contact the dataloggers until they've had plenty of time to be rediscovered by the NL100.
Without using a neighbor list, keeping the beacon interval at 60 and setting a verify interval of 3660 seconds (61 minutes) in the NL100 is probably best. With 3660 seconds for a verify interval the stations will not be dropped from the NL100s routing table unless 61 minutes have gone by without them being heard from. Alternatively if you specified all of the stations addresses in the NL100s neighbor list you could set the beacon interval to zero (nothing needs to be discovered) and the verify interval to 3660.
Cool,
I noticed that after collecting from all of the stations (whoopee!) the "t" command only showed one station. So what you mention must have occurred.
I'm not sure the best way to input all of the addresses, there are 22 spread from 1 to 1050, as I wasn't able to insert them all via device config or telnet. I'll just change the verify signal like you mentioned.
Another interesting thing is that I have these stations setup on a schedule (to allow all of their downloads to occur via the old method without them trying to compete). Well all of the stations downloaded in the first 5 minutes rather than spread out over the schedule (with about 3 stations every 5 minutes). Now it gets to their time in the schedule and is trying to get data it already has.
BNZLTER said:
Another interesting thing is that I have these stations setup on a schedule (to allow all of their downloads to occur via the old method without them trying to compete). Well all of the stations downloaded in the first 5 minutes rather than spread out over the schedule (with about 3 stations every 5 minutes). Now it gets to their time in the schedule and is trying to get data it already has.
I'm not sure I understand. What's the "old method"? What's the base time, collection interval, primary retry interval, number of primary retries, and secondary retry interval for one of your stations.
In my Ethernet to Freewave radio network I've offset the base time for each of my stations by 10 seconds in order to minimize RF collisions. However, the Freewave radios are good enough at handling collision that they could all be scheduled for the same base time and data would be collected just fine.
So, the "old method" was using the RS232 port setup in TCPSer mode. We ran into problems recently with our connection to several stations that were all coming through one repeater. Therefore I decided it was a good time to try changing our NL100 to PakBus.
I'm e-mailing you a table of our setup.
Relevant previous discussions:
http://www.campbellsci.com/forum/messages.cfm?threadid=D5DE7BD1-DE22-D4C5-794CBA4D7CE8633E
http://www.campbellsci.com/forum/messages.cfm?threadid=732194DD-0666-52B0-269F343452D88E3A