I'm sending packets using UDP protocol from Windows to Mac computer (Windows 10, Mac OS X 10.10). I'm using Windows API on Windows (C++) and GCDAsyncUdpSocket on a Mac (Objective C and C). The frequency that I send is around 100Hz. I'm expecting latency of 10ms, and it really is 10ms on the sending computer. But the receiving part gets delayed every 1 second. So it receives around 100 packets and then there's a delay about 50ms.
I tried dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_HIGH, 0) on the Mac side but it didn't help. I tried Wi-Fi, Ethernet, different computers and networks, it didn't help either! Firewalls, Windows Defender are off everywhere. There's always a delay every ~100 packets on the receiving (Mac) side.
I can post the code, but it's really basic.
What can be the problem here? It looks like I'm missing some setting that I'm not aware of!
Related
Setup
I have a TCP server running on a microcontroller, and a client running on a Linux Destop.
What I'm trying to do
I am establishing a TCP connection, and then periodically sending messages with lengths varying from 18 bytes all the way up to 512 bytes, from the microcontroller (server) to the desktop (client).
The messages must be sent in one packet, so the TCP stack is configured to not split up the data in the microcontroller end.
In the Linux Desktop, I am using the TCP_NODELAY option which allows messages to be sent immediately, turning off the buffering algorithm. Good, I want this.
What the issue I'm facing is
I try to set the option SO_RCVLOWAT to 18 as well. My understanding is that when I call recv() it will return when at least 18 bytes have been received, which is the smallest messages I'll receive.
This didn't work as expected, and I don't know if it's because I'm misusing the API, or what I want to do cannot be achieved with the TCP/IP stack of the Linux Kernel.
The problem is more with the small packages, recv() won't return with small buffers.
One last Note
When running the client on another microcontroller, with the same TCP/IP setup, I can send and receive the data, how I want it, with no problems.
How can I achieve what I want to do under Linux?
It's for a real time application so I need the functionality of UDP but with the reliability of TCP. Thanks in advance!
Newbie in the community, here. First of all, thanks for all the help in all these years i've been working on embedded development :D
I have a problem with an Atmel AT91RM9200 ARM microprocessor, connected via RMII to a Mikrel KSZ8863 ethernet physical interface. The ARM is loaded with U-Boot 1.1.2, which loads the Linux Kernel v2.4.27.
I manually added the code to interface U-Boot with the KSZ.
The problem is:
Using U-Boot, if I try to download something from my TFTP server (located in the same network), the connection sometimes has so many timeouts that the download fails, and sometimes has just 2 or 3 timeouts.
I checked the U-Boot FAQ page, and the most probable reason for the timeouts is a wrong speed configuration, which I double checked.
What could be the reason for the unreliability of my connection?
Thanks,
Loranzp.
Setup a minimalist network consistent of TFTP server, client and Sniffer (Wireshark in promiscuous mode) (if you use a switch it must have a repeater port where to connect the sniffer PC)
Next run traffic captures and analyze when and how the timeouts occur.
Consider:
TFTP BlockSize too big leading to mishandled IP fragmentation.
Server provides the packets too fast after REQ or ACK
Not correctly handling block number roll-over (only when handling big files)
etc
I'm having an issue connecting a serial device to an embedded device I'm writing code for.
The device I am writing has two serial ports, an incoming from my laptop, and an outgoing to an external device.
When I connect both terminals to my laptop and view the data, I get exactly the data I am expecting.
When I connect my laptop to the external device directly, I am getting exactly what I expect, and a response.
When I connect the laptop and the external device to the embedded device I am working on, the laptop sends data to it, it receives it, it passes it on to the external device. This works as expected.
However, the external device doesn't send back the response.
If I send data to the external device from the embedded device, each new message I send allows it to send the original reply.
I know the first message got through correctly because the external device whirrs to live, and I know when it is sending the response by running and logic analyser on the tx/rx comms and viewing the traffic.
I considered that the embedded device is holding the rx line and preventing its transmission, but I don't see how that possible in the code. Also if that is the case it shouldn't work when I plug both lines into my laptop.
I also considered the DTR was not set high, but checked this and it appears to be set high.
Does anyone know a reason which would prevent a device from responding?
Note: When I say Serial Ports I am referring to the UART when referring to the embedded device. All device use a DB9 connector running RS232.
Edit: Operating System on laptop is Windows 10. Embedded device is a Atmega324p.
Edit 2: Did some more testing. It appears that it sometimes work and sometimes doesn't.
I have added an image which show a almost perfect signal of the response.
The blue section is a gap in the signal that shouldn't be there.
Ended up finding a solution.
The RTS line was held via the embedded device at 1.2v, while the Pc was holding it at 5.2v.
Pulling the RTS line up to 5v fixed the issue.
I'm using stm32l151 and I want to use usb peripheral in cdc mode. I used stm32 cubeMx to generate the project. however the function CDC_Transmit_FS() always return USBD_BUSY. can anyone help me?
Here is my code:
while (1)
{
CDC_Transmit_FS(Buffer, 6);
HAL_Delay(2000);
}
I only added the above code to the project created by STM32cubeMX but it didn't work.
STM library is buggy and it stalls when you for example try to send many larger packets of data.
There is a problem with the windows drivers and there are quite long delays between packets. So 12MB is quite difficult to archive - using CubeMx I could only have about 3-4Mb (12MB when packet is sent).
Another problem I had - I needed to send some data to the device bofore I could transmit next packet (max 8kB in my case), otherwise it stalled randomly.
Fortunately, the problem is solved and I can receive data in the PC from the STM32. There was a problem in my terminal software. I used serial port manitor to monitor the received data from the serial port, however this serial monitor software do not open the serial port by itself and if any other software opens the serial port and receives the data, it monitors data receptions. I didn't know that.
Thanks
I'm having trouble understanding the API to set up a l2cap (or RFCOMM) client/server running on OSX like I can with BlueZ on Linux.
On Linux, I simply open a socket, bind, listen & then accept for the server, & socket, bind, connect for the client (w/ the bind taking in the BT address of the device I want to use). Also, there's no pairing done.
I can't figure out how to configure my application to start listening for connections on a particular device (or if OSX only supports 1 BT adapater at a time, then how to listen for any incoming connections).
I also can't figure out how to configure my application to send to one BT device using a particular device (this is irrelevant if OSX only supports 1 at a time).
Also, does the OSX stack require pairing to have occured between 2 devices before it'll pass through l2cap?
Any language examples would be appreciated, although C/C++ would be preferred.
Thanks
In Mac OS X 10.5 there's an example (in /Developer/Examples/Bluetooth, titled RFCOMM_Open_SPP_Example) that shows connecting to and reading data from a bluetooth device (i've used it to read NMEA lines from a BT GPS receiver). See also: Leopard & Bluetooth RFCOMM channels
Unfortunately I can't find a copy of the example project anywhere.
It looks like the code samples have been replaced with: Developing Bluetooth Applications