UDP Broadcast on WIZ120SR

I have a WIZ120SR (2 serial ports; FW:1.3; IP: Evaluation Kit, connected via ethernet to a PC on the
same subnet ( IP Mask in all cases was (

The ports are configured for 9600 baud 8N1, UDP.

Port numbers are 62001, 62002, both local & remote ports are set to the same port number.

If I set the Remote IP’s for each port to the PC’s IP address ( everything works reliably, and I can see the data on both ports.

I would like to use the broadcast address on each of these ports, mainly so the user doesn’t need to worry about IP addresses and just needs to monitor the ports & so the IP doesn’t need to be specifically configured by them, since they may not understand Networking.

I set up the first port on the card to the Broadcast address of “” with different port numbers 62001 & 62002 (still pointing at Both ports are received OK at the PC.

I then set the second port of each card to the Broadcast address of “”, the port reception then became erratic on the PC (@ with the data seeming to be scrambled.

Since the ports are different I would have thought there wouldn’t be any reason why this wouldn’t work, since the requests would be in different packets, can anyone see what I am doing wrong, or is this somehow something that shouldn’t work?

I’m a little confused about next configuration.

Would you please attach your system block diagram? (including assigned IP address and port number of devices)
and, what does mean - the ‘card’?
please explain more your situation.


Hi, Thanks for the reply, my block diagram is attached.

The Logging PC is setup to receive UDP on Ports 62001 & 62002 and display it on the screen, once set up I don’t need to change this.

1/ If I have the setup as shown then the data seen by the logging PC is corrupted while reading Ports 62001 & 62002.

2/ If I change the Wiz120SR to a Remote IP of on both ports then the Logging PC data is OK.

3/ I can have either port on the WIZ120 with a Remote IP to and the second with a Remote IP of (broadcast) and the data is also OK at the Logging PC.

Any ideas, or am I doing something stupid?

We tested ‘data transfer over UDP’ using broadcast in WIZ120SR(fw v1.3), but the test PC received all correct data.

* Dataflow : [Serial devices] => serial => [WIZ120SR port #1, #2] => Ethernet => [PC] * Serial data : 40 byte, Transmitted per 1 second. * WIZ120SR port #1, Serial : 9600-8-N-1, operation mode : UDP, Remote IP :, local & remote port : 62001 * WIZ120SR port #2, Serial : 9600-8-N-1, operation mode : UDP, Remote IP :, local & remote port : 62002

How often does the ‘serial device’ send data to the ‘logging PC’? Please try to adjust the ‘Data Packing Condition’ in configuration tool.
If you possible, would you please post the captured packet at the moment of corrupt? (wireshark)

Just wondering how I would capture this packet for you? What software do I need to do that. Please advise. :confused:

The Wireshark is a network packet analyzer. this tool is used for troubleshooting network problems.

If possible, please post the captured packet at the moment of corrupt on logging PC using Wireshark program.
Captured packet is helpful for solve a problem I guess.
And, did you adjust the ‘Data Packing Condition’ options in configuration tool? (e.g. adjust the ‘timer’ value)

I downloaded Wireshark as per your recommendation and had a look at the data.

It took me a while to make sense of what I was seeing but after a few hours getting used to it I can see how useful it really could be.

My UDP data was very fragmented, many contained just a single byte of data, so as per your other suggestion I set the ‘Data Packing Condition’ (in my case to <0A> = LF) and this gave full “packets” containing one string of serial data per broadcast “packet”. (Not sure if packet is the correct word here but you probably get the idea).

The serial data was at 10 time per second in both cases but the logging software is now seeing it correctly so this is now working OK so I guess the fragmentation was the cause of the problem.
Thanks for your assistance, I am rather new to this.