I have CR1000 running OS32.05. I have a cellular modem attached to COM2 of the logger.
The cellular modem handles all its own PPP and acts as a serial server so the logger sees only serial Pakbus communications on Com2. The logger can also use Com2 to send AT commands to the modem (when there is no active remote connection) to check signal strength, send SMS etc.
The issue I have is that after Loggernet communicates to the logger (via the cellular network/serial server modem) the logger initiates a series of RING and HELLO messages 150 seconds after the communications are closed. The logger is trying to verify the Loggernet address (in my case 4055) as a neighbour.
I don't want this to happen.
Reading the Pakbus Networking guide, it appears that by setting the Verify Interval for Com2 to a large value (larger than the schedule collection interval in Loggernet), the logger will not initiate these Pakbus messages.
That doesn't seem to be what I see.
I have set the Verify Interval for Com2 to a non-zero value (65535) with no change
I have set the Beacon Interval for Com2 to 65535 to a non-zero value (65535) with no change.
I set both of these to 65535 at the same time with no change.
In all cases, I still get the logger initiating the RING and HELLO packets 150 seconds after Loggernet disconnects.
How can I disable the attempt by the logger to verify this neighbour?
Can I delete the Loggernet addresss from the CR1000's neighbour list after Loggernet connection is closed?
The logger monitors when a remote connection is active by using ComPorIsActive(Com2) so I can use this event if needed.
Is the state of the port (open Vs closed) relevant here? Does this somehow change the logic around neighbour verification?
I ask because the logger code controls the port - open when there is no active incoming connection and closed when there is an active incoming connection. This is done by monitoring the serial port (with the port open) while "waiting" for something to happen. The modem (seral server) sends a message to the serial port when an incoming connection is received, which triggers the code to close the port, so the OS can handle the Loggernet comms.
This all works fine.
The only outstanding issue I have is to stop the logger initiating the messages 150 seconds after the remote communication ends.
Thanks
Simon
Hi, Simon. I hope you are well and I hope I understand the problem correctly.
I believe that SeriaOpenFormat = 0 will be of use. This format allows you to receive printable ASCII characters (0 < char < 127) from the modem during AT coms. All characters > 127 are "gobbled up" by the PakBus communication stack as it searches for valid PakBus packets, framed by 0xBD. This allows you to engage in ASCII coms and PakBus on the same com port without having to open and close the port and/or switching between SerialOpenFormat's.
Closing the ComPort (SerialClose) should prevent all incoming communication.
There are two PakBus devices in the network. The first is the CR1000 and the second is LoggerNet. Both of these devices have settings for Beacon Interval and Verify Interval.
Beacon Interval: Specifies the time interval, in seconds, at which the device will broadcast a beacon message on the port. If the value is zero, the device will not broadcast any beacons.The CR1000 default is 0. The LoggerNet default is 1 minute.
Verify Interval: Specifies the time interval, in seconds, at which the device will verify a link established between itself and a neighbour. If this value is zero, the verification interval will be set to a value of 2.5 times the beacon interval. If neither beacon interval nor verify interval is specified, the default verification interval will be 5 minutes. The CR1000 default is 0. The LoggerNet default is 0.
Following the rules above that means that the CR1000 advertises a verify interval of 5 minutes (300 seconds) and LoggerNet advertises a verify interval of 2.5 minutes (150 seconds).
As noted above, both of the devices - LoggerNet and CR1000 - have verify interval settings. They advertise their verify interval to each other during a hello exchange. The smallest interval advertised determines the verify interval for the link. Using the values above, that means that the link will be verified every 150 seconds (150 seconds < 300 seconds).
You might try these different combos to see if you get a behavior closer to what you want.
a) Datalogger Beacon Interval = 0;
Datalogger Verify Interval = 65534;
LoggerNet Beacon Interval = 0;
LoggerNet Verify Interval = 18 hour;
b) Datalogger Beacon Interval = 0;
Datalogger Verify Interval = 5;
LoggerNet Beacon Interval = 0;
LoggerNet Verify Interval = 18 hour;
Hi Sam, Thanks for the info. I have discovered the advantages of the SerialOpenFormat = 0 when reproducing this code I refer to above on the CR300 as the way I'm controlling the serial port on the CR1000 doesn't work the same on CR300. I'm using SerialOpenFormat = 0 successfully on CR300. I might roll that over into the CR1000 code now. I also need to produce a CR1000x version of this code too, so II'd like to keep it consistent if I can.
As for the Hello exchange business, I didn't consider that the Loggernet Beacon interval would be playing a role here, but it makes sense that it would be.
I'll update that and try it out. <<Takes a break here>> I have now updated Loggernet settings and tested successfully.
The challenge I'll have in the final network is that the polling software isn't Loggernet - it is Hydrotel and I'm not sure whether we get to control the Beacon/Verify settings there.
Based on what the client has reported, they used to see the verifcation begin to occur after 5 minutes, so that makes me think that whatever the Hydrotel settings are, they were larger than the logger's settings (which were previously set as default).
The impact of these verifications being sent is limited to the modem serial buffer getting loaded with some bytes that it can't process.
This leads to the situation whereby the next AT command that is sent to the modem fails to execute, which isn't an enormous challenge - as long as the modem's serial buffer doesn't overflow - I'm not sure what would happen in that case.
I have developed some code to monitor the neighbour list on the com port of interest and to send a command to the modem to clear its buffer when I see a neighbour disappear from the list. That is working right now as a band-aid.
I think by updating the polling software settings (if possible) and using my band-aid code, the risk of problems will be minimized.
Thanks again Sam.