Unstable connection on UDP

Technical Support
1

Hello RS community,

I would like to use laptop to listen to data stream from RS3D, and these two devices were connected by ethernet cable using UDP protocols. The laptop is connected to WIFI. RS3D can stably be connected to server and forward data, however, while laptop is listening, the connection is not stable, and data is often lost:

image
image1754×155 27 KB

Could this be due to network congestion, buffer overflow, or other reasons? I have also attached log files for the review.
RSH.RB25D.2025-02-25T15_45_18.logs.tar (5.6 MB)

2

Hello pengfz,

First, let me provide our dedicated manual page for the Shake UDP protocol: Raspberry Shake Data Producer UDP Port Output.

If you are losing a few packets, that could be normal as, by definition, UDP does not guarantee 100% receipt of data packets.

However, from what you write, it appears that you are losing quite a lot of packets. Is this correct? Any other detail you can provide will surely help.

Thank you for the logs. From them, this one emerges as a prominent issue:

2025 056 15:45:16>>	No Data has been received from the MCU in 12 read attempts.It appears the MCU is not transmitting data.  This is a fatal condition and should be investigated if this condition persists!
2025 056 15:45:16>>	Data has been successfully received, fatal condition resolved.
2025 056 15:45:16>>	internal error: buffer overflow!  cannot process read data...
2025 056 15:45:16>>	buf: pĂź_k#I]ƠˆEQĂȘkÔQûÿOkˆM€eY27Q Ê”QÐE
2025 056 15:45:16>>	'ĂĄE€EY`ƒaQ
2025 056 15:45:16>>	yƓÀ

As you can see, error files contain some “gibberish” mixed with “no data received” errors.

I would recommend checking if the current power supply that is being used is continuing to deliver a stable voltage between 5.0 and 5.2V and a current of at least 2.5A at all times, as a decrease in power could lead to data services interruption. If you have another Pi power supply that you know is in working condition, please try to exchange the current one with that, and see if the Shake now properly works for longer. Also, remember to try different wall sockets.

A second check that you can do is to see if all the connections between the sensor, the blue Shake board, and the Pi board are still solid and free from dirt or any other element that could compromise transmission. If you decide to disassemble the Shake when doing this, please make sure you are using proper ESD (ElectroStatic Discharge) protection (such as gloves, etc.), as electronics do not like static electricity too much.

As a last resort, and if all these checks come out as positive, then I would recommend re-burning the microSD card again (or using a different microSD) after formatting and erasing all its data/partitions first (you can use DISKPART for this as it is very efficient), and see how the Shake behaves with the newly installed system, removing potential issues derived from corrupted files. I will leave the burning instructions link here for your convenience: microSD card topics

For anything else, I remain available.

3

Thank you for the assistance! And sorry for the late reply. I tested using different wall sockets as you suggested, and it did help. The connection stability improved. I’m also wondering whether the issue might be related to the network environment, as I usually encounter unstable connections when using the campus Wi-Fi.

2 Likes
4

Hello pengfz,

No trouble at all, and it’s great to read this!

Yes, it is also possible that, if you have what can be called “spotty” connections, this factor could interfere with the data transmission, resulting in missed packets.

5

Hi Stormchaser,

I’ve tried different power sockets, and a new Raspberry Pi power supply is already on the way.
However, I’m currently encountering a disconnection from the server, and the web interface looks like this:

image
image1017×1487 97 KB

I noticed that IPv4 address is 169.254.119.129, shows the PC failed to assign an IP address to RS3D via DHCP. I’ve already enabled Internet Connection Sharing for my Wi-Fi, but the Ethernet interface is not getting an IP address automatically. This issue emerged in the log like this:

2025 069 03:52:15: Unable to resolve hostname 'raspberryshake.net', most likely no DNS server available
2025 069 03:53:15: Unable to resolve hostname 'raspberryshake.net', most likely no DNS server available
2025 069 03:54:15: Unable to resolve hostname 'raspberryshake.net', most likely no DNS server available
2025 069 03:55:15: Unable to resolve hostname 'raspberryshake.net', most likely no DNS server available

By the way, I have used a brand-new microSD to have a try, also have tried to switch off the firewall, but the situation remains the same. Any advice on what might be going wrong here, and how to fix it? Thanks and regards!

1 Like
6

hello pengfz,

am i correct in concluding that you have connected the Shake directly to a computer of some sort? if so, then without some other extra work, the Shake will not have access to the internet-at-large.

there are two ways to resolve this:

  1. connect the Shake directly to the router, not a computer. when you do this, the router’s DHCP service will assign an IP to the Shake, also identify the DNS server to be used to resolve URLs.
  2. configure the computer to provide network sharing or bridging services to the connected Shake. this second option is best described by my chatty friend chatGPT:
    https://chatgpt.com/share/67f69575-ab44-8008-b344-09b6692fa3f5

as well, when posting to the forum, always provide the log files when possible, this allows us to provide responses that are more accurate than when we don’t have them.

hope this helps,
richard

7

Hi Richard,

Thanks for the sharing. Unfortunately, the first method isn’t quite applicable so far due to limitations in my working environment.

As for the second one, let me clarify my issue more clearly:

My PC system is Windows, so I have already used built-in Internet Connection Sharing features, as described in chatGPT:
Windows: In Network Settings, enable Internet Sharing for the Wi-Fi adapter, and set the Ethernet port as the target.

As mentioned by GPT, typically, the OS in such setups runs a DHCP server on the Ethernet interface, which should assign the Pi an IP address in the range of 192.168.137.x. However, my Pi still shows an IP address of 169.254.119.129.

I‘ve also included the log files for your reference here:
RSH.RB25D.2025-03-10T03_55_34.logs.tar (6.2 MB)

8

Just a quickly heads up, I’ve just tested a new Pi power supply, but it still doesn’t seem to work.

Here are the latest log files:
RSH.RB25D.2025-03-11T01_26_18.logs.tar (5.5 MB)

9

hello,

going back to your original post, there were two problems you reported:

  1. no data being received off the serial port
  2. UDP packets being dropped

with an additional problem being added along the way:

  1. shake unit is unable to access the internet when connected directly to a PC

the suggested solution to problem #1, replace the power supply, is resolved in the most recent log files you sent. this can be seen in the log file odf_SL_plugin.err; the former error messages related to data being read off the serial port are no longer present.

for problem #3, configuring your PC successfully to act as a bridge between the shake unit and the router / internet is beyond the scope of our technical support; this configuration is not a part of any recommended setup that we document should work.

it is unclear to me, then, when you say “it still doesn’t seem to work”, what exactly are you referring to.

this, however, is clear: that without NTP services, the data will not be able to be streamed to the server, (and will be of questionable value anyway since the date / timestamp used for the data is so far off).

resolving the lack of DNS server issue will solve both the NTP and shake data server connection issues at the same time.

hope this helps,
richard

10

Hi Richard,

Thanks for pointing out that the issue of lacking DNS leads to the problem #3. After several days of work, I have finally solved this problem. Here is my workout process:

  1. My PC is connected to the campus Wi-Fi. However, since my PC couldn’t automatically assign an IP address to my RS3D via ICS (Internet Connection Sharing).
    So, I manually configured both the PC’s Ethernet interface and the RS3D’s network settings.
  2. I manually set the following static IP settings on the PC’s Ethernet interface:
    IP address: 192.168.137.2
    Subnet mask: 255.255.255.0
    IP gateway: 192.168.137.1 (to stay consistent with the ICS subnet)
    DNS server: 8.8.8.8
  3. At this point, the PC can proxy DNS requests in ethernet. So, on rs.local, I configured DNS server the same as PC’s IP address in the ETHERNET SETTINGS, then clicked “SAVE AND REBOOT”, and all you need to do is to wait till the RS connect to the server.

In this setup, the PC is directly connected to the internet via Wi-Fi, and the RS3D is not connected to the internet directly but is connected to the PC via Ethernet.

image
image862×1312 75 KB

Within this local Ethernet network, RS3D sends its DNS queries to the PC, which proxies them to the internet. All RS3D’s traffic, including domain resolution and data upload, is routed through the PC to reach the internet.

Although there are still a few small problems left unsolved - like why my PC stubbornly refuses to hand out IP addresses via ICS - this setup has resulted in much more stable UDP data transmission from RS3D to my PC. No packet loss, no hiccups, just smooth streaming (at least so far).

2 Likes