I have a CR1000X at a remote site that I connect to via a setup of IPPort, PakBusPort, pbRouter (NL201) and RF451 radios. The program was recently changed while another researcher was on site and now Loggernet is having problems- I can not download data because it gets stuck "Getting Table Definitions" and eventually fails and I get the red "Table Definitions Suspect" and no data is transferred. Loggernet does connect (in the connect screen) but even after a full 2-4 minutes of connection, I always get the "Table Defs Suspect" notice...
I have tried a myriad of things with no luck 1) I tried cutting the packet sizes all the way down to 128k for the logger and pbRouter- should I try even smaller? 2) I have tried associating the program via the setup screen (I loaded the .tdf file of the new program off of the field laptop that was used to change the program) and I put the new program in my Loggernet directory as well.
What else can I try? I have never had this much trouble updating table definitions on a telemetry connection.
Thanks!
Compile the program in CRBasic Editor to create a .TDF file. You can then associate that file to the station in Setup of LoggerNet. That will reduce the amount of data that needs to come from the logger for the table definitions.
Note that there is a max packet size setting in the logger and one in LoggerNet. On weak radio links, I reduce the setting in both. You should not have to go lower than 128. You can use Pakbus Graph to ping stations. There is an adjustable packet size when you ping a station. That allows you to test different packet sizes and see the network latency.
It is possible you need to adjust maximum response time in Setup. LoggerNet does not see how many repeaters are in the radio network, so does not account for the time. Pinging a station in Pakbus Graph will give you an idea of how many seconds to use for a timeout.
@JDavis -
Thanks for the pointers here. I have already done the .TDF and associate the file to the station in Setup within Loggernet. No luck there.
I can connect to the station in the Connect screen no problem but it never seems to be able to load the .TDF completely and I get the Table Defs Suspect message and can not download data.
Would it help someone to diagnose if I sent a screenshot of the log from log tool while Loggernet is going through this process?
I have set the packet size down all the way to 128 and tried multiple other packet sizes in both the logger and Loggernet within the Setup screen with no luck.
I have also upped the maximum response time from 0 to 200msecs... if I set it to be longer, how long would be reasonable?
There is one repeater in this network and I have 2 other stations in similar distances from the repeater that have had no issues connecting or updating in the past.
I will do some tests in Pakbus Graph as you suggest, what should I be looking for in terms of latency and how does that reflect different packet size optimums... in other words, if I set a packet of 256 then what do I look for as the response to know how to adjust packet sizes or response times accordingly?
Thanks again and any other ideas are much appreciated!
Also,
In my PakBusPort- I have not done anything with the Allowed Neighbors setting- it is at the default range of 1 to 4094- is there anything there that could be specified to try and help force the connection?
Reducing packet size helps if there is radio interference. Smaller packets are less likely to get hit by the interfering signals. RF451 radios can put a full 1000 byte packet in a single radio packet. On RF407 series radios, packets larger than 250 get split into multiple radio packets. I will often ping in Packbus Graph 20 packets to see what percent make it through at a given packet size. You want >50% to make it through.
Did you try forcing a table definition reset on Connect screen?
This post is under review.
Smaller packets are less likely to be affected by interfering signals. RF451 radios can put the full 1000 byte packet into one radio packet. On RF407 series radios, packets larger than 250 are divided into multiple radio packets. I will regularly ping Packbus Graph 20 packets to see what percentage is achieved at a given packet size
This post is under review.