We are installing a network of seven CR1000 in mountainous country and the customer wants two seperate radio frequencies for redundancy.
Because of the terrain, we opted for Maxon VHF radios as line of sight is not even remotely possible.
The have been having real problems with communications being lacklustre to say the least even though we are only about 10km between stations.
Today we found a work around, we turned off one of the radio frequencies and communications are reasonably solid.
Question is can the CR1000 handle two communications devices trying to connect to different comm ports at the same time?
The following comments are based on the assumption that you are using LoggerNet for datalogger communications. In order to support two different bases, I assume that you had to create two different serial port objects and associated PakBus port objects in LoggerNet's network map. By default, both of these ports are assigned a PakBus address of 4094. I believe that this is causing the problem that you are encountering. Basically, the CR1000 is recognising neighbouring PakBus connections on two separate ports and, depending on how communication is being driven on these ports, is switching between these two in a rather unpredictable manner.
The solution to this problem is to change the PakBus address of one or both of the PakBus port objects in LoggerNet's network map. This can be done in LoggerNet's "Setup Screen" using the "LoggerNet PakBus Settings" dialog which can be accessed using the "Options" menu of the setup screen.
Regards,
Jon Trauntvein
Jon
Thanks for the prompt reply, but maybe I should have explained myself a little better.
We are using the control ports (C5 to C8) as two com ports that each have one maxon radio (with modem) attached. Each radio is on a separate frequency transmitting the same data for redundancy sake.
The trail starts high up, each of two sites close together with separate sensors and one radio each (separate frequencies).
Downstream there is one more site with two radios, one each frequency and another set of sensors.
There are two repeaters (east and west) each with two radios (two frequencies).
One alarm site (two radios, two etc.) and a command post (two radios, two etc.) with a network connection (NL115) and onward to LoggerNet.
The problem seems to be that the CR1000 does not know which radio to answer (in reality it could be getting the same data on different ports at the same time).
Back in the days when CR10Xs ruled supreme there was a wee box called and SDS-115??? that would connect two devices to the one CSIO port, giving preference to whichever device connected first.
We have already got rid of "beaconing", reduced "verify" to ten minutes, dropped packet size to 64 bytes (and matched that within the Maxon radio). Four of the sites can only be reached by helicopter, so dropping in to change things is rather difficult.
Anything else that you can think of that I could try?
Cheers
Grant
The logger can cope with multiple devices connecting via different serial ports with one big proviso.
This is that every device has a distinct Pakbus address. In your system is it possible that one logger could try to talk to another logger via the two radio interfaces at exactly the same time (or with overlapping comms sessions)?
If so that could be the problem as the logger will get pretty confused as to which is the correct route to respond on (this is the same problem as Jon refers to above - but between loggers rather than logger to Loggernet).
Unlike Loggernet there is no option I can currently think of to make the one logger have two different Pakbus addresses dependent on the comms path.
The immediate solution that comes to mind is to make sure that the two comms paths are only used at different times.
Is that an option for the alarm function?
Andrew
I think that is what is happening.
What delay would be required between between the comport commands? It is only a ten character string we are sending.
We could handle the beacon interval via programming (currently set in logger settings via DevConfig) and delay one comport via either a delay command or issue at a different point in the program.
We have been told we have as little as 7 minutes to sound the alarm, so can't contemplate our navels too long!
Would one of those new fandangled RF500s on each radio fix the issue?
Thanks
Grant
First: re the RF500s, these could be used in this instance as addressing in an RF500 network is controlled primarily by the RF modem address not the logger PB address. You can have two RF500s connected to one logger (via the CS I/O port), so you can setup a working system that avoids clashes.
There are a few issues with the RF500s though. First you need one for every radio in the system and secondly they may not be compatible with the radios you have. They will only work with a limited number of analog radios OR some, but not all, RS232 output radios. You'd need to contact CS (Logan) to get a definitive answer on compatibility.
The most efficient way of using the RF500s is to use the Senddata command, but the messages do not go back off to the LN PC immediately (and this assumes you are sending alarms back to LN). A lower level polling scheme is used to get that data buffered in the RF500s. This polling interval could be set at 2 mins though so should still meet your alarm time requirements.
An alternative approach is to persist with your current scheme of connections and try to work out a method of avoiding conflicts.
To give advice on that we'd need to know if you are polling for "alarm data" using Loggernet, or whether the data is being send to another logger (perhaps using Sendvariables) which is controlling some alarm signalling system. It is not clear in your description..you do mention an alarm "site". Please clarify.
Andrew
Problem with our comms is that we have trouble even pinging our sites. One hop on the PakBus graph is usually fine, sometimes after a few "ping failed: Communications failed" we get a solid ping and then can connect.
If two hops are required (through a repeater site) we can see the sites in the PakBus graph, the repeater site has the routes listed as seeing all sites, but we get an "invalid PakBus" returned when pinging. Also in this instance connection to send programs, receive data or get settings in pakBus Graph are troublesome if not entirely impossible.
We have treied both polling the remote sites to retrieve data and getting the remote sites to send the data, no real difference between the two.
Best workaround we have come across is to disconnect one of the radio frequencies, which the system currently is working with, but comms is not stable enough to reliably connect to all sites (even via ping).
Does anyone know of a PakBus VHF (148-174) 5 Watt radio that is available?
We are out of here in two days and really need to find a totally reliable solution over the next two weeks
Grant
Grant,
What modem/PROM combination are you currently using? It may be quicker if you give me a call, Jeff Murray - 435.750.1728 or email jmurray at campbellsci.com, and we can discuss the radio/modem/PROM options.
Jeff
As a side to the conversation, I would make sure to use widely spaced frequencies (e.g. 160MHz and 170Mhz). I have set up a dual frequency system before using two narrow-banded Midland/Maxon SD125V2 radios. Until I had the frequencies widely spaced and antennas vertically spaced properly (i.e. one antenna greater than 1 wave length higher than the other) I had a lot of noise issues. I thought this was odd since they were narrow banded, but there was a high noise floor on one radio when the other radio was keyed. It made my coms unreliable. Note I was not using PakBus, I was using a one-way "aloha" protocol. Also I only know enough about RF to get myself in trouble. This was just my experience in the field.
I have tested the RF500M with both the Midland/Maxon SD125/225 series and the Calamp DataRadio 3400. Both are 5W adjustable.
* Last updated by: Sam on 6/10/2009 @ 10:22 PM *