Ok, so here's my problem. I have an android app transmitting UDP packets to a PC (a java program which listens for the packets), based on user interactions with the android device. To keep things simple, let's say this is happening - the user taps the screen of the phone, and it sends a UDP packet with the coordinates of the point where the user tapped. The listener program receives and reads this packet, and outputs the string received, using System.out.println().
Now, what's happening is that the program works perfectly for the first few packets. Then it stops working, as in, the listener program on the desktop does not display any output. Now, the issue is probably with the transmission, as I have a text label on the app (for testing purpose) that displays what is being transmitted, so the transmission packet is definitely being built properly. But I have no idea on how to understand if this is a problem with sending the data (on the android device side), or receiving (on the desktop side). How can I find out what's wrong and solve this issue?
I have mostly worked with TCP transmission and all the UDP i have done are mostly Copy-Paste [:-)] or with APIs
For TCP, after transmission, I throw a debug message, which helps me to know that the transmission occurred properly. But in this case, your write will have to be blocking.
Also, you could use a Packet Tracer on your listener terminal to determine whether it is receiving the packets properly. The one I love is WireShark (I think its a fork of Ethereal). Its really easy to use. You tell it which interface to listen on and give a filter and it will list out the packets as and when they come.
However, if you are using Windows 7, you will need admin privileges.
Are you using native code or Java classes? I have tried both, and with the NDK (i.e. sockets written as C functions being called from Java) I have seen erratic behavior on the server side, mostly due to threading issues. Using the Java Socket class I have not had issues however. Moreover, if your Android app is the client, that should not be the problem. I would also use Wireshark to check whether the packets are reaching the PC.
Related
I am doing a firmware upgrade of a BLE peripheral device based on ESP32 from an Android central.
The firmware file is sent in parts of 512 bytes each. The ESP32 device (the GATT server) sends a notification to the central (GATT client) and the central sends the next part, followed by a write command to the peripheral. Then the next notification is sent and so on.
The upgrade works, however, it takes a long time to complete (~10-12 min for a 600kB file).
I sniffed the traffic with Wireshark and it turned out there are 15-20 empty PDUs between the sending of each notification by the peripheral and the start of sending the part by the central. I searched what may be the problem on the server side but could not find anything relevant.
Maybe something is happening on the Android central that delays the sending process? Or maybe I am missing something with the ESP32? Here is a Wireshark capture (I’ve underlined in red where the sending should start):
EDIT: I haven't added extra sleep on server and if I had, there would be no empty server PDUs, correct?
I tried what you suggested, to use just android's internal mechanism for confirmation and the download is now about 3x faster. Thank you! However, in the captures there are some strange (to me) things like a lot of 26-byte response packets from the server to the master (captures below). Why is that and is it possible to combine them into 3 packets, the way they were sent from the master?
Also, about he explanation in the link you gave:
The Bluetooth controller sends a "number of packets complete" event back to Android's Bluetooth stack over HCI which indicates that the Link Layer of the remote's device has acknowledged a packet.
I didn't quite get that. If its a Write_No_Response from the master, how does the remote device acknowledge receiving a packet?
And is this Android flow control mechanism a possible explanation of my original problem with the empty packets?
Seems like the Android device is not fast enough, or you have added an extra sleep.
Assuming the peripheral can handle the data, you can quite reliably send write commands without using a notification acknowledging scheme. See onCharacteristicWrite and onNotificationSent are being called too fast - how to acquire real outgoing data rates?. Basically just wait for onCharacteristicWrite before sending the next one.
I've been searching for a long time with no luck.
I'm trying to get a Mac OS X application to communicate with an Android application. Nothing more complicated than a chat client type application where text is typed in Android and sent to OS X (maybe via Cocoa or even a Java app).
I'm lost how to accomplish a Wi-Fi based communication between the two. I looked into Bluetooth first, but it seemed way over my head on the OS X side. Wi-Fi I assumed would be easier to implement.
Any guidance is much appreciated.
So you want your android to communicate with your Mac , there are many ways to do it.
1- With Internet- Queueing mechanism/DB mechanism
Your android could connect to SQS #AWS and write messages to the queue. You could write code in any language on OS X that reads off the queue and returns the string
Similar implementation can be done with a database- think orchestrate.io
2-Without internet
Assuming you've setup an ad-hoc connection between your mac and your android. You could simply open a socket and send and receive data on them. It's pretty straight-forward. Your Mac will run a TCP client and show the stream and print data out as necessary.
Socket programming question here.
My interface comprises of an Android device(client), A wireless module hosting an access point, and an Arduino Uno(server).
My Android client class works when 1 user connects and sends commands to my Arduino server class.
I want to make my program friendly to many users at the same time. My server will only read in values from 1 connected client at a time.
After some research I've found that Arduino does not allow multithreading naturally, which is why i've decided to look into a number of libraries.
The Arduino library that I've decided to use for this specific issue is protothreads. Unfortunately, i've been unable to find any examples of creating a server with Arduino to accept a client's commands. Furthermore I'm having a lot of trouble figuring out how to make this library work in my favor.
Now for my question,
How exactly can I allow my Arduino server to constantly listen for
incoming messages from more than 1 client device?
Or is there something I can do on the client side that would make this communication possible?
Could you get away with accepting the socket responding and the closing it. Similar to a web page. As not to have multiple sockets open at once. Note uno only has 2k of ram flash goes quick. By one and close each stands alone and naturaly allow many different connections. Just one at a time.
I'm currently creating an Android App where it collects data through bluetooth and draw a real time graph but it seems like after short while there is packet loss and graph comes out weird. I've been searching for a while how to recover the loss but seems like there is no way.... only TCP/IP or UDP has.... Since I need all the data, I can't ignore the packets that doesn't have starting bit or end bit. Is there anyway to prevent the loss or recover the loss completely?
Thanks
Use of RFComm on Android already has built in packet order and reliability like TCP. You should try running tests to see if the Android device is too far away, receiving accurate information, has a bad Bluetooth module, or if the sensor is at fault.
I'm running some code on the nexus one - and I am having a very strange issue. The "server" sends UDP packets out on the multicast socket that the phone is joined to. The phone receives and sends stuff to the multicast group fine, but it appears that the phone chokes when it receives a large number of packets at one time.
For example, the server will occasionally send out 80 or so 512 byte packets in one go around. The phone starts receiving the packets, but then at the 31st packet (~16KB of data) the receive hangs (indicating that there is nothing on the socket anymore.) I've done wireshark testing and stuff so I know for sure that the packets are not being lost. Even if some are being lost, it is very strange that EVERY test produces the same result --- a large amount of data gets jammed onto the socket at one time, but the socket only allows me to socket.receive() for 16KB worth of data.
I have tried socket.setReceiveBufferSize() with a variety of values (up to 1MB) -- but that doesn't seem to work. Interestingly, a call to getReceiveBufferSize() tells me that the socket should hold roughly 100KB worth of data.
If I tell the server to slow down its send method (which I cannot deploy, I can only do that for testing purposes) - everything works fine, presumably because the packets aren't jammed onto the phone's socket all at one time (ie. I tell the server to wait 1/2 a second between packets.)
Has anyone else experienced this - if so - how did you get around it? I cannot switch the application to TCP.
Thanks!
Dan
PS. The Java code works fine if I run it on a regular machine...
Nevermind - I fixed it by moving onto a closed network where there is 0 possibility for loss and weird things -- not sure what was up with the network I was on (which was supposed to be goo) - but at least it works!
Dan