I have an old java program that is communicating with an embedded device manufactured in 2000. The program communicates with this device using the standard Windows serial stack (from what I can tell, when I capture data using PORTMON in windows I see requests like IRP_MJ_WRITE and IOCTL_SERIAL_SET_RTS).
The device however, connects to a serial port on the computer using a Serial-to-Stereo Plug connector, similar to this. I believe this means the device itself is only capable of sending signals using two pins.
How can I analyze raw communication between the two devices in an attempt to reverse engineer the protocol? I am on Windows, but am capable of moving to OS X or *unix. I know at some point I am going to have to write something to deal with the specifics of how the device communicates, but what do you guys recommend for gathering information?
The stereo jack is just a cheap way to implement a minimal RS-232-based connection. That shouldn't affect monitoring.
Portmon should display the data you need to investigate the protocol. The IRP_MJ_WRITE requests contain the data sent to the device, while the IRP_MJ_READ requests contain the data sent by the device.
If you cannot do this by software interception means, a simple multi-channel logic analyze (such as one of the FX2 USB designs) should be able to capture traffic on both the transmit and receive lines, and then allow you to software decode this at leisure to see the full interplay of transmissions, responses, and any delays in between.
Related
The situation:
I'm developing an android app for some hardware that has a BlueGiga WT12 bluetooth modem. The hardware device sends 56 byte packets at around 240hz. I'm testing on a Samsung S5 and S8. A fully functional app has already been created for IOS and PC so we know the hardware device works.
I use a separate thread to read in the data and then dispatch it to the main thread.
Issue:
The issue I'm having is when I send the command to the device telling it to start streaming, it starts to stream but very shortly after I start receiving packets at a very slow rate 10-60hz.
After some examination I realized that the device was experiencing a bufferoverflow.
After talking to our hardware guy he said the only real thing that could cause that is something on the phone side not reading fast enough, resulting in the hardware device not wanting to send more packets because it thinks the phone can't receive anymore and then the buffer overflows on the hardware device.
The WT12 has flow control enabled so maybe this is an issue with Android not giving a clear-to-send signal to the WT12. But to my knowledge we don't have access to all of the flow control stuff.
What I've tried:
My first line of attack was to simply remove any code that I thought was slowing down the reads but that seemed to have no effect.
I also tried basically every bluetooth serial terminal app I could get my hands on, all with the same result.
So then I questioned if it was some weird problem relating to the hardware device but after using pc based (bluetooth) serial terminals I had no issues at all on the pc.
The hardware device can also operate over USB as opposed to bluetooth so I tried reading the data from it exactly the same as I had with the bluetooth connection but over USB. Using the USB serial connection I had no issues at all.
My thoughts:
So this leads me to believe the problem must be with the bluetooth modem on the phone side. I was thinking maybe it was a flow control issue as we have flow control enabled on the WT12. Maybe android isn't sending a clear to receive signal?
The problem is to my knowledge the flow control is implemented in the bluetooth stack and we as developers have no control over it if I'm not mistaken?
Other then flow control I don't really have much idea what could be causing the hardware device to not want to send me data.
I've just now been experiencing the same issues with flow control. Then I see that in case of RN4678 BT module, that it's best to disable the flow in the MCU FW and pull the cts pin low on the module. That worked for us.
I am making a game of Bingo. For that I will be connecting two mobiles via wifi- hotspot and the grid should be shared to both clients, that is both mobiles should see the grid. How can i pass the grid two both clients? Also, how to pass numbers in between client and server? Via object or other thing and how? Also how to exactly implement client server application making 2 java files n android? PS: we are not implementing a chat application.
Bingo XML file: https://github.com/TanishaShrotriya/SDL/blob/master/activity_main_bingo.xml
Java File:https://github.com/TanishaShrotriya/SDL/blob/master/MainActivity_bingo.java
You have a few options. First you need to determine which architecture works for you.
Client/Server (AWS Instance with APIs, and Firebase with PUSH)
---This will enable the devices to get current came status on open, and push changes to their board on confirming their space was called/filled.
---This will enable other devices in that "room" a name given to a virtual shared space for a game. To receive PUSH notification of changed data to display.
Next you need to decide if the server will maintain the full state of each user or just the current called values for comparisons.
If you decide that you do not want to write APIs and setup a Server for PUSH, you can do an ad-hoc wi-fi or even a BLE based communication among everyone in the area. However, this will require significantly more understanding of how to pass bytes, handle network issues, latencies, and communicating from device to device.
If you choose to do the ad-hoc wifi as you mentioned you would have to maintain a ton of connections like a mesh network. A better option would be to have all devices join the same wifi network so that they have access to each other, but aren't necessarily keeping track of mesh networking.
However, even if you are on the same wifi knowing who to send the information to can be difficult without a server to retain routes and IPs of current players. So you may have to create a host so that it can listen for enrolled players. The host device would need to retain routes to all other devices so that it can send the info to each IP address when a change occurs.
I still highly recommend going the client/server route of APIs and PUSH it will be far more reliable.
Now as far as how to pass the data, you could of course screenshot via code and send images, but that is wasteful. I would recommend having a matrix that keeps track of the values covered and simply send a JSON snippet of the card_id, the player_id, and the json of covered blocks to the server that can then push changes back to all players in the "virtual room". This allows them to see how their fellow competitors are doing.
So I would have to ask for more details about what your goal is to help any further, but that is my recommendation, because ad-hoc wifi or bluetooth is doable, but on a mesh scale size you will have a giant headache on your hands. The host scenario device with all on same wifi would be my second direction if you are really anti-server and APIs, which the only reason I could see you avoiding that is if you wanted to play off wifi that doesn't have internet or if you don't want to pay the $30/month for traffic while it is small.
Let me know if that helps or if you want to provide additional clarity.
I have a question:
I had created a client app in Android Studio, and I need to know if it will work if the server was on Windows as a GUI program using Java.
so if the server was made using java in GUI on Windows and the client as a app on a Android smartphone... Will they connect successfully to each other?
If both client and server comply with TCP protocol, they can interact with each other regardless of their underlying platforms, because all network protocols have their own principles and rules which must be obeyed by all platforms using them.
Also you shouldn't worry about medium-level byte ordering, because network has its own endianness which is big-endian and in various platforms they first convert their data to this endianness before sending it over medium. All these stuff are handled at OS level and you're not supposed to take care of them.
I have created database in one application and that application is installed in multiple devices.My requirement is that if i change the value in database of one device then,that changes in database should reflect in another device of same application.I need it without server/third api.
Thanks in advance...
This is precisely when one does need a sever.
Stop and consider what it is that you are asking for. You need a way for a phone to notify all other phones that hold the same application about a change. Phones are not directly addressable to each other via the web, which makes any kind of peer to peer algorithm tricky. SMS texts is the closest form of direct addressing that phones do support, thus it could be used to build a peer to peer protocol, but that would be tricky, unreliable and is unlikely to be beneficial.
A server on the other hand is the standard approach to solving this problem, the server acts as a shared agent that all phones that connect to the web can address easily. Even if the server is just an FTP server on a freebie hosting site.
You need to implement a server functionality in your android application.
What is a server : A server is a running instance of an application (software) capable of accepting requests from the client and giving responses accordingly. Servers can run on any computer including dedicated computers, which individually are also often referred to as "the server".
For further information,I would like to provide this link which will clarify you about communication between two devices Android - communicating between two devices (Use of bluetooth etc.)
I need to send out packets on a different frequency, not on normal 2.4GHz.
Has anyone tried that before and knows how to do it?
Would be nice, if anyone can give me a hint.
Best Regards.
If your Android device could communicate via 802.11p (it requires a specific radio/antenna combination), the 802.11p device would be a specific network interface. You could then, assuming you had an IP stack running on that interface, send out UDP packets on it.
If your Android device doesn't have an 802.11p radio, there's no way to turn an 802.11a/b/g radio into one.
Transmitting a packet implies that you already have, at very least, a transport layer established. It is not possible to transmit packets on arbitrary frequencies without first establishing a transport. Check out
http://en.wikipedia.org/wiki/Osi_model
In other words, you would first need to establish an 802.11p session with a wireless access point before you could transmit packets.
You cannot force a device which does not support 802.11p to connect with it. Devices are manufactured with specific chips to enable wireless communications, and are limited to the protocols supported by that chip.
You might be interested in this JSR:
http://jcp.org/en/jsr/detail?id=307
I don't understand the question.
You can definitely change the card settings through a variety of ways to change the frequency, then send all traffic out on that frequency.
I don't think there is any possible way to send a specific number of packets out on a specific frequency while other traffic maintains the original frequency.
One way around the fact that the phone itself doesn't have the radio hardware to broadcast on the 802.11p frequencies would be to build a small device that accepts Bluetooth or Wifi and rebroadcasts data using 802.11p hardware.
That may be a bit more than you want to get into, though.
You cannot do that. WiFi only works in either 2.4GHz frequency mode of 5GHz (which is not enables on most phones, because it's very battery-hungry). What you might not understand is that 2.4GHz is not the frequency you're sending signals on, but rather the full bandwidth of your wireless communication range. There 11 channels inside the 2.4G bandwidth that run on different frequencies, "modulated away from the 2.4 GHz center frequency", but only practically three of them (1, 6, and 11) run on non-overlapping frequency ranges.
The channel on which you are doing it is set the the wireless access point (such as a wireless router) and not the device. I suggest you look up the IEEE 802.11 standard as #Jonathon suggested.