I am using XCOM v2.0. It comes with a hardware, and it will receive the data from the port com4 continuously, also sometimes I need to send command to this port com4 to control that hardware. The trick thing is, there is a option called "send new lines" in XCOM V2.0, If I want to send a command to the port, I have to check it to let the command work, otherwise the command will not work.
My goal is to understand this, and implement this command in my python code. Currently I could use XCOM V2.0 to real-time receive the data and send commands. But my python code does not work.
So XCOM V2.0 did something for my command, but how could I know? I do not have the firmware of that hardware, how could I monitor the com4 and see what commands I send to port com4? so I could do same thing in my python code?
at first I thought XCOM V2.0 just add \r or \n or any combination after/before my commands, but I tried every possbile combination and none of them work, you could even try this in XCOM V2.0, just add \n or \r or combination in the end of command, and do not check "send new lines", it will not work. Later I though XCOM V2.0 must send some hidden commands to stop the port receiving, and do sending, but how to figure out it?
Related
I am currently trying to write a script that could conduct an "HL7 Ping" but I am still new to HL7 and not 100% sure how I could do that. I am trying to build out a health check for my HL7 enabled devices and have come up fruitless. I've seen solutions like testing the port and such; however, this does not fulfill my goal. I want to send a message:
MSH|^~\&|MONITORINGPING||||||ADT^A01|
And get some sort of ACK back to confirm whether the service is up and running. Does anybody out there know the answer or know where I could go to get it?
There is no such a thing as "ping" or "health check" on HL7 or MLLP level. Please refer to this answer for more details about MLLP.
The message you are sending
MSH|^~&|MONITORINGPING||||||ADT^A01|
is just one segment of ADT message. This is not a valid message. If you want the ACK in response, you should send full and valid ADT (or any other) message. Although, some HL7 Listeners may send NAK for such message; I will recommend do not rely on that.
On TCP level, you may simply ping the IP or alternatively you can telnet IP and port.
An ADT message is not appropriate to "ping" a remote system. The closest trigger event for what you're trying to do is probably NMD^N02 (Application Management Data Message). But you'll find that trigger event isn't supported by most real world applications.
My employer has asked me to prepare for testing several thousand Chromebooks (mix of models/manufacturers) to refurb/flip. This may be a recurring thing.
Most or all of these will be old enough that CCD will not be available. I'd like to connect a widget such as a Raspberry Pi to the USB and have it automate testing as much as possible.
I know I can use keyboard emulation to inject commands, but I'd like to get a crosh session running over USB so that I can read info from the DUT besides just controlling it.
Google shows bazillions of returns about using a Chromebook as an ssh terminal but what I'm looking for is the opposite. I'm prepared for the answer to be a simple "no" but I'm concerned because I can't find that anyone else has asked this question. I don't think I'm that creative, so I suspect my Goog-fu is weak.
The answer appears to be "no". However I solved it another way; using "gadget mode" I have a Raspberry Pi ZW enumerate as a keyboard and a serial port. I put the Chromebook into Developer mode, open a developer shell with ctrl/alt/F2, or on a PC/linux or Mac system open a terminal window and type "sudo su" (these have to be done manually). Then I have the RPi issue this bash command to identify the serial port "in the blind":
SERPORT=/dev/serial/by-id/$(ls /dev/serial/by-id) # Chromebook or PC/linux
(or)
SERPORT=$(ls /dev/cu.usbmodem*) # Mac
Now I can have the RPi inject commands via the keyboard, put ">$SERPORT" on the end of each command, and the output comes in the RPi gadget serial port. The RPi then packages the data and forwards it over WiFi to our CRM. It's working nicely for Chromebooks, PCs booted into linux, Mac desktops and Macbooks.
Edit:
The company I work for has actually turned this into a product and so I'm not sure how much detail I should share, but...
I learned my way around gadget mode on the RPi from this link. There are examples for setting up a keyboard and a serial port. Using the templates in that link, I made a device called /dev/hidg0 which emits keyboard scancodes from the RPi to the Chromebook. I also made a device called /dev/ttyGS0 which the Chromebook sees as a serial port.
So I send keystrokes with some python like:
with open("/dev/hidg0","bw") as hid:
hid.write(blah)
and then have the Chromebook send text to the serial port, which I then read by looking at /dev/ttyGS0
Hopefully this will be enough to get you started. I found the isticktoit link very helpful.
For the past month, I have been working on two MQTT clients that will communicate with each other over a CloudMQTT broker.
The clients use the DAQIO LabVIEW MQTT library (found here https://github.com/DAQIO/LVMQTT). The basic operation is that one client (LaptopClient) will publish commands to the other client (USBClient), which will read the command, perform an action, and publish a message back to the origin.
The problem occurs when USBClient is unable to read the command. When USBClient is initialised and is waiting for LaptopClient to send a command, and LaptopClient sends a command, the "read subscribed topics" function of USBClient will present error 66, saying that the connection was closed.
What I've tried:
Using a local broker, instead of CloudMQTT
This resulted in no error, but I cannot use a local broker for the final product because I will not be able to connect from another computer over a wireless network.
Replacing LaptopClient's publish with mosquitto_pub (isolating USBClient)
This resulted in no error, USBClient was able to read the command and publish an acknowlegement.
Replacing USBClient's subscribe with mosquitto_sub (isolating LaptopClient)
This resulted in no error, LaptopClient was able to publish the command successfully.
Connecting to my phone's mobile hotspot
I tried this because I thought there might have been an issue with the network. It resulted in error code 1, which states that an input parameter was invalid. However, the only input parameter was the connection ID.
Replacing LaptopClient with default test client provided by DAQIO LabVIEW MQTT Library
I tried this to eliminate issues with the library. It resulted in no error.
It does not make sense to me, why does it work over a local broker but not online?
As you can see, the error occurs after reading the subscribed topics. Why does it work when either of the clients are replaced?
I am writing an application using Asterisk-Java. It is designed to run on a server that also runs Asterisk. So far, so good.
My application, that originates calls (using the AMI) and that manages user input (using Asterisk-Java's FastAGI and an embedded AgiServer) works great on both my development server and the production server.
For deployment purposes, I am now asked to create a Docker container that would pack up Asterisk and my application, so that it could be easily deployed to other places without having to go through installations and configurations.
The thing is, my application does not behave the same way in the Docker container: on the development / production servers, using the getData function, I can get a DTMF code; on the Docker container, getData seems to never receive the DTMF data from Asterisk (I can stream a file, but the function eventually times out, which means it did not get anything).
I first though of an unexposed port, but since this communication problem seems to be between the AGI Server and Asterisk, which are both running in the container, I find it hard to believe.
I have no other idea, please suggest.
Check out the dtmfmode Parameter for your SIP-Peer...
If your are using RFC2833 (DTMF via RTP), unexposed media ports could very well be the reason.
You could try to optimize your port settings (could be a lot of ports!).
Or try to use DMTF via SIP-Info as an alternative.
But that wouldnt fix any media problems...
Good morning,
I'm a embedded linux developer and I'm trying to dump J1939 CAN sentences on a iMX6 based board.
I tried saving RAW canbus messages on a file using the command
candump can0 -L > /tmp/fms_canbus
and everything works fine with NON BROADCAST messages.
However I'm not able to receive BROADCAST messages (BAM), it seems that no BAM message is recorded on the file.
As far as I know, in order to read BAM message, the socket should be opened with option SOCK_DGRAM, CAN_BCM, but it seems there is no CLI tool in canutils package that allows to perform an operation similar to the
candump can0 -L > /tmp/fms_canbus
Is there anyone that can help me fixing this issue?
Should I implement a custom tool or is there a standard utils allowing to perform the desired action?
Best regards
Giovanni