Can I write a java application that uses RxTxComm
to get signals from a remote control send to my serial receiver?
I have a RS-232 receiver I am listening on that com port for incoming bytes.
When I press any button on my remote control I don't see any data arriving to my serial port.
What am I missing here?
Should I see any data?
How does lirc do it ?
It is sovled here: http://commjava.blogspot.com/ have a look at it. (Be aware that they use proprietary third party code)
Lirc is not in java, their solution won't help you.
Related
I want to create a UDP OUTPUT=UPLOAD stream using java. I will get my INPUT=SOURCE data from a named pipe or contiguous file opened as a file input stream.
My problem is, ALL of the UDP examples i can find on the internet, only demonstrate console sessions. Echo servers and such.
I'm trying to create a way to stream continuous content such as audio/video, and i don't care what gets lost, i'm leaving that up to my user to be concerned with, however my code does need to allow setting the buffer size, and creating a UDP connection.
Ideally a GOOD example would show how to do upload and download mode connections (client mode and server mode)
Can you provide some code to do this, or show me a link on the internets? The fact that I cannot find a UDP stream client/server example is ridiculous. Using UDP to do console sessions tests the limits of a person's sanity! That should never even be considered optional, let alone useful. The client/server code i need must be compatible with GNU netcat. (to ensure correct performance)
I have tried this with a client:
byte[] buffer = new byte[udpPacketSize]; // 4096
int len;
while ((len = standardInput.read(buffer)) != -1) {
udpSocket.send(new DatagramPacket(buffer, len, host, port));
}
But when I stop sending data, and disconnect, I cannot reconnect to send more data. I'm not sure if that is what is supposed to happen, because 1) I am completely out of my element here and 2) when I disconnect after sending the data, the remote instance of GNU netcat does not exit like it does in TCP mode.
HELP, I need a real network systems engineer, to show me how to implement UDP for practical applications!
[and somebody to remove all of that garbage from the internet, but let's keep it simple]
[further: please do not respond with libraries, packages, or shell commands as a solution. i must be able to execute on any embedded device which may not have the programs, and libraries are not teaching me or anyone else how to do anything on their own.]
But when I stop sending data, and disconnect, I cannot reconnect to send more data.
That's the way GNU Netcat UDP mode works, as far as netcat to netcat on a single machine goes...
Your client needs to read a response from the server before disconnecting. So, while acting as "middle-man", you should not be concerned with this, as long as you can connect your network-client's local-client, to the server's response mechanism.
In other words, you need to provide a bi-directional-half-duplex-connection (1:1 communications), since you are not managing the protocol.
Alternatively, you can use a different UDP server than Gnu Netcat. I have tested this one, and it works without the MUST-READ-REPLY-BUG, effectively meaning, there is nothing wrong with my example code. The must-read-reply feature has nothing to do with a correct UDP server implementation (unless you must connect with a Gnu Netcat 0.7.1 compatible server).
It is worth nothing that it isn't very useful to use Gnu Netcat UDP server mode without a driver (script/program) behind it, especially if you want a continuous process, as you could lock your remote client out of access until the process is respawned.
Has anybody successfully interfaced Medical Lab devices like Cell Counters /ABG instruments to mirth connect using ASTM 1381-02 or similar protocols over serial port. I am working on a small project. I need the data transmitted by the machine in ASTM format to a text file/ to a database and I cannot afford to pay $30000 for mirth commercial support. I need a low cost or open source solution.
I was expecting MLLP listener to be off use but it seems to work with TCP and I have to make it work purely on serial communication.
Secondly
I tried writing ASTM serial data receiver in Java. But control characters such as ACK, STX, ETX, ETB, and other delimiters are not visible in terminals be it in Win 7 cmd or Netbeans/Eclipse console. Making me helpless in parsing the data.
Any help will in right direction be deeply appreciated.
If you are under Linux environment you may use COM port redirector to a given TCP port and use Mirth's TCP Listener to intercept that flow.
E.g., to pipe the serial port through netcat:
netcat ipaddress port < /dev/ttyS0
Or using socat:
socat pty,link=/dev/virtualcom0,raw tcp:ipaddress:port&
(check for correct parameters)
I recognize 2 problems:
First, is it possible to raise an ftp service on the windows PC? if so, you only need to create a file reader addressed to ftp to capture the txt with the ASTM.
Second, to determine the characters of start and end of message I recommend you read the information of the provider, if you do not have it available, I suggest you use notepad ++ to see the hidden features. I hope you help.
Just FYI there is a commercial extension available that provides ASTM E1381 support: https://www.nextgen.com/products-and-services/integration-engine?extension=astm-transmission
my task is to receive UDP packets on an Google Compute Engine. Given is the port, which is 300 and I already have a simple Java program which can handle these UDP packets.
My problem now. Get the UDP packets to my Java program.
For that I don't know how to do this.
What I have tried so far ist to let the Java program direct listen to the port, which didn't work. I suspect the traffic from outside the GCE must be routed to the inside?
First make sure you've added a firewall rule on your GCE VM instance's network which allows incoming traffic for UDP protocol on port 300.
You can do this by going to the Developers Console, select your project, then Compute-> Compute Engine-> Networks, click on the right network and verify firewall rules (and tags as well if you used them). If the rule is not added, then add a rule for the traffic.
"gcloud" is a command-line tool which you can use it to list and verify your firewall rules as well [1]:
$ gcloud compute firewall-rules list
If the firewall rules are good, then use a simple troubleshooting tool like netcat to test if traffic is being forwarded to your VM instance.
1. Listing Google Compute Engine firewall rules
I recommend not using Java to process UDP. I experienced inexplicable short periods where all UDP traffic arriving was being lost. This was caused by garbage collection.
The architecture that works for me is to use a GCE VM with a C++ app receiving UDP data, then using libCURL, convert the data to HTTP and dispatch it to Google App Engine for processing. To make the UDP receiver scalable and tolerant, use network balancing and multiple VMs listening for UDP.
I'm new to embedded systems,
could i send data from java application on my pc to serial 7 segment display direct via serial port or i have to use micro-controller in between
"TTL serial communication" probably means the same protocol used by a PC serial port, but at a different voltage.
You will be able to connect it to a serial port if you use a level shifter in between to convert the voltages. Search for "MAX232" chips, which are designed to do exactly this. There will be a bit of wiring involved. For more help with this part, try https://electronics.stackexchange.com/
On the software side, I don't know if Java has a way to access serial ports. There is probably a 3rd-party library to do this, but C might be better-suited anyway.
given a flash application that opens a socket connection to a webserver, is it possible to reads packets exchanged with a java application, without redirect all the flash traffic ( that is, without programming a socket proxy)?
What you are trying to do requires lower level network analysis than sockets. Namely libpcap and its Java bindings , jNetPcap. This will let you capture packets much in the same way wireshark does, but from Java. The other options are analysing Wireshark logs after an experiment and that can get clunky quite quickly. You may also consider writing a custom wireshark dissector.
The only way I can think is to modify the hosts file to list your Java server address as if it was the destination address.
BTW if your are only interested in examine the network traffic for that app, you could also use fiddler