I’m really new on the coding world and I need your help. I need to do the following:
In a Zedboard platform I take data from a USB port and want to make real time packets and send them via TCP.
I have establish FreeRTOS for that. I take the data from a UART and keep them in a cycle buffer. I send a TCP command from Matlab for starting the transmission but that gives me just one packet of data. How a make this real time?
I'm afraid I don't understand your question - you mention both USB and UART - is the USB a virtual COM port? Whether its a UART of a USB port, once the received data is placed in the buffer you can use something like a direct to task notification to unblock a higher priority task to then send that data over the TCP link.
There is a FreeRTOS/Zynq/TCP example on the following link: http://www.freertos.org/FreeRTOS-Plus/FreeRTOS_Plus_TCP/TCPIP_FAT_Examples_Xilinx_Zynq.html
Related
I am working on Windows with C# but this is more of a general question.
If I receive UDP packages with a UDP client they are normally removed from the receive buffer so other programs can no logner access this data.
My experiments showed that this is not the case for boradcast messages. If I connect multible programs to the same UDP port and call the receive function both application can see the broadcast packages, but only one application can see unicast packages as they are deleted when first read by the OS?? I guess...?
My question is is there a way to change this socket behaviour? can I set up my socket to preserve this data so a second programm could access it as well? Or is this not possible?
the overall goeal as you can guess is to have multible programs receive the same UDP packagees send via Unicast.
After alot of research i can confirm this is not possible with unicast packages.
You can use PCAP to achive this but not with the native UdpClient
I wrote a simple Python3 code that takes readings from a sensor at 250Hz. I wish to send these readings to my laptop so the values can be used in real time in an application that I'm creating in Python.
Therefore, I would like to be able to add code into my existing Python code that instead of simply printing the sensor readings on the Pi, sends the values to my laptop in a way that can be read by my Python application.
I'm thinking to use wireless or ethernet on the Pi, so I intend to send the data via a cable or WiFi.
UDP protocol can be used at this sample rate (250Hz)? Or I need to develop some way to bufferize the data until to send over UDP?
Any advice on how I could achieve this would be very appreciated, thanks.
UDP protocol can be used at this sample rate (250Hz)?
Sure.
Or I need to develop some way to bufferize the data until to send over UDP?
Yes. There are 28 bytes of overhead to every UDP packet you send. If your sensor data is only 2 bytes long and you send this at 250 Hz, 93% of the data you're sending is overhead. Send several samples at once per-packet.
The other thing to keep in mind is that lower layers will also add overhead. There is also some overhead in switching and routing. Fit as many samples in a packet as you can, for your latency requirements.
I have some (very) old software written in C, that was used for two devices that communicate via serial cable (RS232) - both sending and receiving messages.
Now the old devices are to be replaced by new modern ones that do not have serial ports, but only Ethernet.
Hence, the request now is to convert the old serial communication to UDP communication (C++ is the choice for the moment).
So, I have some questions about this "conversion":
1) Suppose there are two peers A and B. Should I implement a server and a client for each peer, i.e.: serverA+clientA (for device A) and serverB+clientB (for device B)? Or is there some other/different approach?...
2) The old serial communication had some CRC, probably to ensure some reliability. Is it CRC necessary to be implemented (in my custom messages) also on UDP communication or not?
Thanks in advance for your time and patience.
1) UDP is a connectionless protocol so there's no rigid client and server roles here. You simply have some code that handles receiving and some code that facilitates sending.
2) You don't need CRC for UDP. First, there's a FCS (CRC32) in each Ethernet frame. Then, there's a header checksum in IP packets. After all, checksum is already included in UPD datagram!
Please also consider the following things:
In everyday life COM ports are long gone from the physical world, but they're still with us in the virtual form (even Android phones have COM ports). There are a lot of solutions for doing COM over USB/TCP/whatever. Some of them are PC apps, some of them are implemented in hardware (see Arduino's COM over USB),
When an UDP datagram fails checksum test, it is dropped (usually) silently. So in UDP you don't have built-in capabilities to distinguish between "nothing was received" and "we received something but that's not a valid thing". Check UDP-Lite if you want to handle these situations on the application level (it should simplify the porting process I believe).
Default choice for transferring data is TCP, because it provides reliable delivery. UDP is recommended for users that care about being realtime and for those who can tolerate some data loss. Or for those who care about the resources.
Choose TCP if you are going to send large amount of data or be ready to handle packet congestion on ports. Choose TCP if you plan to go wireless in future or be ready to handle periodical significant loss of packets.
If your devices are really tiny or filled with other stuff, it is possible to operate directly on Level 2 (Ethernet).
im in the process of making an application similar to skype to interact with another computer and i have a few questions.
I know all the basics such as how to send data over tcp etc in the form of an image and audio.
How does applications like skype send live audio? Does it litrally record 1 byte of audio, send it and play it and then repeat the process? For me its not instant so i dont see how that would be possible.
How would u send string and image through tcp at the same time (video call + chat), would you use multiple ports? i can see how that would be very bad. The way im doing it atm is when i click to recive an image, i set it up to receive an image so it receives properly, if a string got sent at this time for example, it wouldnt work as it cant be converted to an image if you see what im saying. im not sure how else i would do it. I Could send each thing with its type as the beginning for example "string Hello how are you" then decypher the data type through that, but that seems abit tedious and slow.
If anyone could give me an insight, that would be fantastic
I can't speak for how skype does it, but this should be a starting point:
Streaming audio/video is usually transported over UDP sockets, not TCP. TCP guarantees delivery whereas UDP is best effort. If you have a temporary connection loss you care more that the video you're receiving is current, not that you receive the whole stream.
The data is usually compressed (and sometimes encrypted) using a standard compression algorithm after being received from a camera/microphone. Have a look at H264, which is commonly used to compress video.
RTP is often used to transmit audio/video. It allows multiple types of stream to be combined over a single socket.
Control traffic is usually sent separately over a different socket, usually TCP. For example SIP which is used for VoIP phones initiates a control connection over a TCP or UDP port (usually 5060). The two ends then negotiate which types of stream will be supported, and how those streams will be sent. For SIP, this will be an RTP stream which is set up on a different UDP port.
I want to capture and save the data that's being sent to a certain process through internet .
Are there any tools for the job?
If not, does listening to the same port as the process that I'm trying to get data from, will get me the data?
Any help appreciated !
You can try Wireshark: http://www.wireshark.org/
Or RawCap: http://www.netresec.com/?page=RawCap
I don't know what is the data format you are trying to capture. I used these two tools to capture xml data from web service.
On Windows, use Winsock Packet Editor (WPE). You will be able to hook a process' all Winsock-related functions and capture (and even modify/block) any TCP/IP, UDP packets that the application receives or sends. For all other operating systems, you will have to either:
write your own tool that hooks various socket functions (e.g. send, recv, etc.)
or just use Wireshark which will capture all Layer-3 packets that goes through your network card. You will have to use your own knowledge of the application that you're trying to monitor in order to filter the packets that are specific to the application.
Are there any tools for the job?
Wireshark. But what have you tried?
If not, does listening to the same port as the process that i'm trying to get data from, will get me the data?
Not if you don't forward the traffic to the real destination, otherwise the other party will be waiting forever on a response, or simply timeout and close the connection. You should create something like a proxy.
Wireshark is easier.