CRC & ID Mismatch errors


Recommended Posts

Hi

My project testing on my bench has worked well with no timeout errors / no data acquisition errors

I have just completed my first field test at my friends cattle station where data acquisition is over wifi links (3km and 10km with a ping of 12ms)

I am getting both CRC and ID mismatch errors on a regular basis and after reading a number of posts re these believe I have timing issues

please see attached below

I am using an ethernet /RS 485 converter with a the timeout set to 1000ms (same unit/ settings used for bench testing)

I need some guidance as to which parameters etc I need to change / maybe try catch error scripts in sequences?

 

Rodney

 

 

MPPT_Comms_errors2.PNG

MPPT_TxRx.PNG

Link to comment
Share on other sites

Hi 

I've been playing around with various settings and changed to another type of equipment at a different site to the above post and reduced the channels I am reading to just 1

I have set the time out to 750ms on both the tcp/ethernet converter and the comms device

I am still getting timeout errors

please see attached 4 screenshots

your guidance greatly appreciated what I need to change to remove the timeouts

 

Rodney

ps disregard theuploaded images 2& 3 use 5&6 instead - I couldn't work out how to delete them....

 

pingtest.PNG

pressure_cmd.PNG

pressure_comms.PNG

pressure_Config.PNG

pressure_cmd.PNG

pressure_comms.PNG

Link to comment
Share on other sites

Unfortunately you didn't quite catch the timeout error at 19:36:31.  But I do see that occasionally your device takes 200ms or more to reply to a query from DAQFactory.  That seems long, especially since other times it's closer to 60-80ms (which is also pretty long for ethernet).  Are you going over a radio?

Link to comment
Share on other sites

Rodney...First thing I would try is to increase your timeout on both the DF driver and ethernet/serial device.  Your timeout is simply that your not receiving a response in the 750ms time frame.  Set your timeout to 2 seconds (2000 ms)  on both DF and your ethernet/serial converter and see what changes.  This is for troubleshooting right now to see if there is a latency issue somewhere.

Also, how often are you polling the single value from DF?  The  default is 1 second. Good move to poll a single tag  right now until your figure this out.

What is the baud rate of your RS485 connection?

Are you seeing any errors on the WiFi side of things?

John

Link to comment
Share on other sites

John

I have set the timeout to 2000 ms as suggested and after 30 minutes no errors.....

I will let it run for 24-48 hours and see what happens

I am actually polling 3 different sites concurrently  - 1 has one tag  the 2nd 4 tags and the 3rd 10 tags

the baud rates are all 9600 as I have a number of different types of equipment so I set them all to 9600 to make it easier to write the sequences

Initially I had wifi issues but I think I have solved them -  ping tests now are fairly consistent just the occasional packet loss in 24 hours

one of the sites is 13 km away and I getting average 12ms pings from the wifi /RS485 converter there

Thanks for your suggestions

Rodney

 

 

Link to comment
Share on other sites

Hi John

Testing over the last couple of days has shown spasmodic timeouts - runs for 7 hours then a timeout another an hour later then 4 hours before the next etc

It appears to me these are wifi related not timeout issues - Thanks for the 2000ms timeout fix

I can live with these spasmodic outages - it will be interesting when we eventually go to the planned 30km wifi hops...

Regards

Rodney

 

 

 

Link to comment
Share on other sites

Hi Rodney,

Glad the timeout worked.  Another thing you might want to try is to setup your WiFi with fixed values... no auto negotiation.  Also, try slowing down the WiFi link speed if your devices support this.  Some WiFi devices will change speeds and channels based on conditions and this can induce delalys.

Make everything a fixed value so that the WiFi link is always the same and does not have to be negotiated.  Start at a very slow speed and work your way up.

If the links were good how many tags are you going to poll?

John

Link to comment
Share on other sites

Hi John

I'm using TP-Link CPE520 for the 3km and 10 km links

for the planned 30km links again using TP-Link it will be WBS510 with ANT5830MD dish Antennas

for us it was the best bang for our buck.....

Re the Auto negotiate - in initial testing that was what I used but ping times were 1700-2500ms plus so I used the "survey" mode and locked the channel to the best one available - like I said above return pings are now averaging 12ms

Re the tags to poll - this is going to be interesting....

Each site might have up to 5-7 pieces of equipment - Solar controllers, tank sensors, flow meters, pressure sensors, Amp meters weather stations etc

so each site might have 100 tags x the planned 16 sites 1600+

As we add sites we may have to reduce the amount of data we are gathering - we just don't know yet

Rodney

PS I'm an accountant and knew a liitle about wifi and networking but have taught myself DAQ factory in the last 12 months from scratch - it a big learning curve this and a great adventure for me!!

 

 

 

 

Link to comment
Share on other sites

The CPE520 looks like a nice piece of hardware and should be more than adequate for the 3km and 10km links.  I like learning new things, so I'm going to dig into CPE520 a little because it looks interesting.  If I see anything that might help I'll let you know.

I bet turning off the auto negotiate disabled the long distance features of the CPE520. 

Accountant or not, your doing a fine job figuring this stuff out.

Take a look at the OSI model to see how networking protocol stack is structured.  Ping (ICMP) is a great tool but only tests up to layer 3 of the TCP/IP protocol stack.  This is why you were seeing ping times of 12ms but still getting timeout errors. I believe your ethernet/serial device is using MODBUS/TCP which is part of the application layer 7. So when DF is communicating to your devices there is additional overhead (i.e. latency). 

Your getting 12ms pings, but the actual transmission time might be taking 1000ms, or longer, because you have to...

  1.  Transmite the MODBUS/TCP request to the ethernet/serial converter

  2  The ethernet/serial converts to MODBUS/RTU, transmit the request over RS485

  3.  Wait for a response from the slave device

  4.  Convert the MODBUS/RTU response to to MODBUS/TCP,.

  5.  Transmit the MODBUS/TCP response back to the master.

How often are you  polling data from DF?  You might be pushing it at 1.0 second when you shift to your 30km links. Running 9600 baud with multiple nodes on RS485 is OK for 1 or two devices but as you increase the number of RS485 nodes I would recommend a higher baud rate to decrease your latency.  

If you don't mind do you happen to have a network drawing I could look at?  If not or don't want to I completely understand.

If you want to contact me direct my email is jesawyers63 <at> gmail <dot> com.

John

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

 Share