Serial1 and udp receive interference on argon with ethernet?


we have an argon product which speaks modbus (over Serial1) and ethernet (with the Adafruit ethernet board)

we talk to a modbus device every second and listen for udp messeges. this works fine as long as there is not much udp traffic to the device (udp broadcasts from another device)

increasing the udp traffic will result in modbus errors. the buffers will be mangled up. we reduced the modbus request to the bare minimum (static serial writes and reads)

has anyone seen this too? any fixes or advice?


Hi Frank,

Could you please provide the error(s) you’re encountering, just so we could maybe better answer your question.

Thank you,

hi lance

with the modbus library we see different errors (invalid slave, crc, timeout). to debug this we write a single modbus request as serial writes (representing a modbus request) followed by reads: we see the reads having missing parts/bytes or having extra parts/bytes when udp traffic increases

most of the modbus request go through fine. the modbus device we address is something we have used for a ling time and never gave us trouble with the same request sequences. without udp traffic it all works fine

any ideas?


best situation we got so far is reading all udp packages just before doing the serial/modbus operation. in this case we see about 1% errors in de modbus request (versus virtual none in case of no udp)

I’d guess the UDP packets are delaying the loop long enough to overflow the serial buffer, which is only 64 bytes. What I would do is run only the modbus serial decoding in a worker thread so the other system operations would not affect getting the data from serial at a constant rate.

the modbus response (to the request that we are testing this with) is 21 bytes. we only do this once a second. we should never hit the 64 bytes…

also we not only lose bytes: sometimes we get extra bytes or data is scrambled

modbus/Serial1 baud rate is 9600. we use udp broadcast to communicate between the nodes

this is how we read the modbus response (just for this test case):

        // 5 bytes, 1+1.5 ms each = 12.5ms
        bytesRead = Serial1.readBytes(rxBuffer,5);

        // 21-5 bytes, 1+1.5 ms each = 40ms
        bytesRead = Serial1.readBytes(rxBuffer,21-5);

ok so far we know that you have some issue with your modbus device response

  1. how do you handle the request ? I mean the full request is coming through UDP? (build at the host side ?) e.g : 12 03 4001 002 or you have defined, for example an array of requests and UDP just points which one should be used
  2. how are you checking for CRC ?
  3. which registers you are trying to read/set ?
  4. if requests are build on the host side are you able to confirm/check if they are always correct ? not corrupted ?

as more info we can get about your code, setup etc. as much we can try to help.
Right now is just a guessing game

1 - there is modbus over serial1 and there is udp. they have a different function but do seem to interfer. all we do now on the argon is a udp read of we see a packet. no processing. the modbus request is just a fixed serial write sequence then change the direction pin and the reads as in the previous post. no udp no problem

2 - the actual modbus code does have crc checken. right now in our test case (with fixed request) we just check the data coming in as to see exactly where the problem is

3 - this is a modbus fixed request to a device that we have been using for a long time (without udp) without any problems. same kind of reads every second for days without any error

4 - the problem is that the error rate is much higher than without udp but not so high i can put a scope on the signal and check. but it seems highly unlikely that the outgoing request or the addressed device is the problem as we see data coming in that looks like the response just with data added, changed or missing

it is a guessing game for us also… the test code is very simple. the actual part that seems to fail is the two reads already posted. the udp parts is really nothing, just getting the packets

What about RF interference? Obviously RS485 is pretty tolerant, so I’m more thinking about the lines between the modus transceiver and the UART port, and also the SPI lines to the Wiznet chip. This is completely grasping at straws, but maybe try changing the SPI data rate and see if has an effect? I don’t really think that is it, but if you’re out of ideas…

hi rickkas, will try. this might actually be something we can see on the scope. thanks!

Hi, so I guess I got you the UDP is not involved with modbus at all that’s corect? You have a fixed request for a modbus device and UDP is doing something on side ?
So 2 tings which is in my mind:

  1. You are using the Stream Class with your serial1 but what I read on reference is all are relay on that class I mean serial and UDP I’m so weak regarding to the Classes :man_facepalming:t3: Just know that they are some high abstract level of memory organization/representation
    Maybe there’s something regarding to this :thinking:
  2. Another thing is about RF which were pointed by @rickkas7
    So what about if you gona synchronize all tings ? I mean you need 60ms for a reading back the answer and some ms for send request let’s say another 60ms
    Total is 120ms and you stil have 880ms where UDP can act and in this time you can send as much as possible UDP packets then shut down all SPI and UDP stuff do Serial1 things and again. This test can show us if it’s related to RF interference :man_shrugging:t3:

correct, modbus is over Serial1 (and RS485 driver) and UDP is over ethernet using the Adafruit ethernet featherwing – functionally they have nothing to do with eachother…

1 - in the code excerpt above we use the stream class. but using the single byte write/read/available gives about the same results

2 - we are going to check electrical noise on the modbus lines. as for your idea about synchronizing, this will be difficult: we cannot schedule when UDP packets arrive. i guess we can test this by not allowing any interaction with the ethernet chip. will check this. i read something about how to do this.

thanks thinking about this!