Issue with hex data being sent out of a serial port - python-2.7

I am really hoping someone can help me with this issue, I have been working on it for 3 days and its driving me insane now.
I have two linux based devices connected over serial, one is an embedded device the other is a pc type device. I have some python code on the PC device that currently, successfully reads messages sent by the embedded device (hence the serial settings are correct).
However I now need to send commands back to the embedded device and this is what i am struggling with, I have a data tap on the serial line so i can see the data being sent / received.
When I send the string "\x2a\x00\x00\x00\x00\x00\x57\x78\xD6\x81\x00\x01\x00\x8D\x54" out of the serial port, on the serial data tap I see only "EF F7 FF FF".
Please see the code below:
import serial
serialport = serial.Serial(port=self.device,
baudrate=self.baudrate,
bytesize=self.bytesize,
parity=self.parity,
stopbits=self.stopbits,
timeout=0)
data = "\x2a\x00\x00\x00\x00\x00\x57\x78\xD6\x81\x00\x01\x00\x8D\x54"
serialport.write(data)
serialport.flushOutput()

This is now resolved, turned out to be a couple of issues the customer neglected to tell me that unless the embedded device is in engineering mode it will ignore commands. Also the data tap had a dip switch set incorrectly, so there was nothing wrong with my code. Thanks to Shane for making me question the hardware and not my code !

Related

Max For Live Not Patch Not Updating Data on Arduino Display

I've been working on a project with an Arduino recently where I'm basically trying to get a small display hooked up to an Arduino to update with the name of a MIDI mapped knob in Ableton Live.
For example, let's say I map the knob to the reverb send on a track the display should read "A-Reverb". This works today, but only works when I first open the Ableton project and map the knob for the first time. It does not update when I select a new option.
Here's the setup I'm using right now:
Arduino - w/Rotary Encoder & OLED Display
Hairless MIDI - For converting the serial connection from the Arduino into MIDI CC# messages Live can read.
Ableton Live 11 w/ Max For Live 8 - This is where the patch actually runs.
For the Max Patch, I'm using a version of Yehezkel Raz's One which I purchased and later modified. The reason I mention this is that this patch already has the name updating part worked out, so in theory I should be able to send that data over serial to the Arduino.
Out of respect for Yehezkel's work, I won't attach a screenshot of the entire patch, but have attached the part that I modified to send data to the Arduino, you can see it here.
Here's what I've tried so far:
Validated that the baud rate for Hairless MIDI, the Arduino, and the Max Patch is identical
Attempted to start Hairless MIDI only after Ableton has been launched
Attempted to power on Arduino without opening the Arduino IDE so that there are no Serial conflicts.
Here's what I think may be the issue, but I'm not sure how to fix it:
Part of the logic in my Arduino code relies on Serial.available() being true, in order to send the data to the screen. I'm thinking that maybe the Serial connection is only available in the beginning when the knob is mapped.
I know that was a lot of information, but if anyone has any ideas on how I may be able to get this to work, I'd greatly appreciate it!
Okay I figured this out on my own; basically what was happening was my code was expecting a line feed in order to refresh the output on the display. I figured out that I could send a line feed over the serial connection by sending the value "10" which would basically terminate the string as it is sent to the Arduino.
Any time the knob value is updated, it triggers a button which sends the value "10" back to the Arduino.
I've attached a screenshot showing the changes I made in case this helps anyone else out:

Send play/pause command c++

So I'm trying to control my computer with an IR remote control. I get the IR code thanks to an arduino nano which sends it to my computer by the serial port.
I want to, for example depending on the code sent, send a play or pause or next and so on command to spotify or win media player or any other app.
I know that you have keyboards shortcuts for this so my question is how do I reproduce the commands that these keyboards shortcuts send to all the programs to stop the music ?
Thanks in advance for any help ! :)

USB Serial Communication Console Application

I'm working on a project that involves data transfer from a host PC to the ngx Xplorer 433x microcontroller evaluation board which has a NXP - LPC 4330 uC on it.
I have read and seen that the USB Communication Class Device has interface descriptors for communication and bulk data transfer.
So far I can send commands/files via hyperterminal (TeraTerm) but the throughput is about 32kbit/s, so apparently the transfer is being done via the communication class interface descriptor. The goal should be to achieve a speed of about 10mbit/s or more and ideally it should be controled over a command window (and later a nice GUI).
So far I have been looking for example code on bulk data transfer on USB without any luck, all I found were some odd Microsoft examples that require Win8,VS2013,etc.
Basically what I'm looking is something like:
data[<some big number>] = "<many letters and stuff>";
port_send(COM8,data);
// end
I would greatly appreciate any link, tutorial, pdf, code snipped that could get me further.

Duplicate USB virtual serial ports being created - what might cause this?

I've got a strange problem with some code I inherited from another programmer who's left the company, and need some guidance on how to even begin to solve it.
The problem is this - on a semi-regular basis, we are finding that duplicate USB virtual comm ports are being created. For example, on my PC, when I view the Ports in Device Manager, and select "View Hidden Devices", I have two entries for the same device - one on COM6, and one on COM8.
Unfortunately, we cannot reliably re-create the problem. We suspect it may happen when someone quickly disconnects and reconnects the USB cable when our software is running, but that needs to be confirmed.
As far as I can tell, the code was written assuming that no one would ever unplug a cable. I see no logic whatsoever to detect this condition after the SW is started. And it fails when you re-plug the cable - silently generating read and write errors even after the cable is plugged back in. You have to restart the program before it will work again.
I have very little serial and USB experience, and am at a bit of a loss as to how to even get started on fixing this.
Can anyone suggest why this might be happening?
Misc. details, in case they might be relevant:
USB serial code is in a C++ DLL
VS2008
FTDIBUS USB/Serial drivers
Windows XP and Win7
Screen shot of duplicate Registry entries (note the value of the selected key!)
As explained on Raymond Chen's blog, the Old New Thing, here, and by commenters above:
https://blogs.msdn.com/b/oldnewthing/archive/2004/11/10/255047.aspx
To summarize:
Devices which are unplugged and plugged in again are tracked so they are not treated as a new device every time.
Usually this uses the device serial number to detect whether a device is the same one.
However not every device has a serial number. These devices are treated as the same device only if they have the same vendor ID and product ID and are plugged into the same port. If they are plugged into a different port they are treated as a different device.
Some manufacturers do not understand the word "Serial" in "Serial Number" and give all devices the same number instead of giving them numbers serially... To cope with this there is a registry setting which can be used to force these devices to be treated as if they have no serial number.
Therefore, if a device with no serial number or which is flagged in the Windows Registry as having duplicate serial numbers is plugged in to a serial port it has not been plugged into before, it will be treated as a new device rather than a reconnection of an old device. This will result in "Ghost" devices as you describe.
Some FTDI devices are specifically called out as having this problem by the manufacturer:
http://www.ftdichip.com/Support/Knowledgebase/index.html?ignorehardwareserialnumber.htm

Testing Serial port application

I have a code to send data to serial port. I just want to make sure that it is sending the data properly. I checked the function's return value and the number of bytes written and it is success. Is there any other way to actually see the data whatever i am writing?
if(WriteFile(m_hSerialComm, pszBuf, dwSize, &dwNumberOfBytesWritten, NULL) != 0)
I tried to use "Advanced Terminal Port software"
but the data is not coming in that window.
There are several ways to test your software. If you have two serial ports then connect them with a cable and listen on the other port with a terminal application such as the one you mentioned. Otherwise, you could loop back on the same port by connecting pins 2 and 3 together. A hardware-free option would be to use virtual serial ports as provided by tools like com0com.
Assuming from your piece of code that you are developing on a Microsoft Windows operating system, I would recommend the Portmon for Windows "official" serial port monitoring utility. I have used it in in the past, and found it simple enough, and also quite useful specifically for its multiple filtering/search options (since sometimes the amount of data passed on your serial port is huge).
If all you want is a log of the data you have written to your own port, why not encapsulate your WriteFile (and maybe also your ReadFile) functions in some "utility" function(s) that reads/writes both on your serial port and in some log file? You could even add timestamps, and filter "whatever you are looking for" straight from your own code.
I found this last option really useful when remotely debugging applications with customers. You add a button in your application that toggles the logging on and off, then you simply have to ask your customer to hit the "log" button and to send you the results.