I have an infrared thermometer which operates on a virtual serial port over USB, which I am trying to use on a Linux intel and next on a raspberry Pi. The system did not enumerate a /dev/ttyUSB device.
I found a piece of a solution here :
Cygnal Integrated Products serial port on Linux
I reprogrammed the product_ID and can now see it as /dev/ttyUSB0.
But trying to talk to the thermometer with minicom doesn't work.
minicom keeps saying "disconnected" despite the "9600 8N1" indication.
I must say, I had many attempt to work with this kind of communication over USB/serial adapter trying using many different terminal emulator like screen or minicom but without any success at all !
I'm not even sure about the right way to send request and receive data.
Here is the documentation I'm using trying to talk to the thermometer :
http://www.optris.com/interfaces?file=tl_files/downloads/Manuals/addendums-de-en/ct-ctlaser-commands.pdf
Edit :
I'm now trying to use PySerial Python library in a Python script with an Arduino as a target (to act as my thermometer, the arduino runs a simple code that takes the data received and send them back to my Python console.) But still, there is so many confusion possible between ASCII, Hexa, binary, that I'm not capable of debugging anything as I don't know where the transformation between different format takes place !
The communication is working as I can get some data forth and back from my Python console through the Arduino. But I can't get sending hexadecimal data and getting any response back in hexadecimal format. + You say "Your latest question puts you in the off-topic category. ", what do you mean ? Sorry of being so confused.
I'm trying to build a device to read the current GPS coordinates. The device will include a small computer inside running Windows 7.
I'm looking for a usb GPS to connect it to the computer and be able to read the GPS coordinates from my VB.net 2010 program. Of course, here the most important thing is what hardware I need to accomplish that. Suggest me some GPS models.
Do I need only a GPS receptor or do I need even more hardware?
In addition to jcibar's answer:
For Bluetooth GPS or most USB devices you probably don't even have to set the classic RS232 communication settings like "baud rate". It will just work, whatever baud rate you set.
Look at the "Ports (COM & LPT)" list of the Windows Device Manager - One of the "COM" devices listed should be the GPS receiver and it many times includes a description that indicates what it is.
E.g. on my Win7 x64 notebook I have a "Sierra Wireless Gobi 2000 HS-USB NMEA 9001 (COM8)" port, which is the notebook's built-in GPS. It will just start communicating the moment I open the port:
17.09.2013 10:12:01.890 [RX] - $GPGSA,A,1,,,,,,,,,,,,,,,*1E<CR><LF>
$GPGSV,4,1,16,10,,,,21,,,,20,,,,32,,,*7A<CR><LF>
$GPGSV,4,2,16,31,,,,30,,,,29,,,,28,,,*78<CR><LF>
$GPGSV,4,3,16,27,,,,26,,,,25,,,,24,,,*79<CR><LF>
$GPGSV,4,4,16,23,,,,22,,,,19,,,,18,,,*7E<CR><LF>
$GPGGA,,,,,,0,,,,,,,,*66<CR><LF>
$PQXFI,,,,,,,,,,*56<CR><LF>
$GPVTG,,T,,M,,N,,K,N*2C<CR><LF>
$GPRMC,,V,,,,,,,,,,N*53<CR><LF>
You can use any serial COM port / RS232 logger to test this.
You can use any GPS (USB, Bluetooth) that provides a RS232-level serial interface (serial port). The GPS will create a virtual serial port (e.g. COM13) that you can use in your VB.net program to read serial data (NMEA frames tipically at 4800 bauds).
For instance, for USB you could use something like this: Haicom HI-206USB.
I'm running some code on Arduino, I have website with a slider which uses a cgi script to pass values to Python. Then the python script uses pySerial to send the values to Arduino which controls a motor.
The plan was to be able to control the motor speed using the slider on the website.
However I seem to be coming up against a problem of the Arduino resetting whenever I change a value on the website, causing the motor to stop. Is there any way around this? My python code is below.
#!/usr/bin/env python
import cgi
form=cgi.FieldStorage()
import json
ser = serial.Serial('dev/ttyACM0', 9600)
#I think there should be a sleep here for 1.5 seconds
ser.write("%s\n" % (form["value"]))
ser.close()
print "Content-type: application/json"
print
print(json.JSONEncoder().encode({"status":"ok"}))
So, say I have the motor running at 50% speed, then change a value on the website, it runs this script which executes the serial.Serial('dev/ttyACM0', 9600) command. That opens the port which resets the arduino, stopping the motor before passing the new command.
Is there any way to pass ser.write("%s\n" % (form["value"])) to the arduino without freshly opening the port? Such as leaving the port open between python sessions?
If not, is there any other way around this problem?
I believe the reset is due to a hardware design of the specific Arduino device you are using. I suggest using an Arduino Micro or Leonardo board instead. They use a virtual serial port and should not restart your sketch each time a serial port is opened. This is from the Arduino site:
No reset when you open the serial port.
Unlike the Arduino Uno, the Leonardo and Micro won't restart your
sketch when you open a serial port on the computer. That means you
won't see serial data that's already been sent to the computer by the
board, including, for example, most data sent in the setup() function.
Serial re-enumeration on reset.
Since the boards do not have a dedicated chip to handle serial
communication, it means that the serial port is virtual -- it's a
software routine, both on your operating system, and on the board
itself. Just as your computer creates an instance of the serial port
driver when you plug in any Arduino, the Leonardo/Micro creates a
serial instance whenever it runs its bootloader. The board is an
instance of USB's Connected Device Class (CDC) driver. This means that
every time you reset the board, the USB serial connection will be
broken and re-established. The board will disappear from the list of
serial ports, and the list will re-enumerate. Any program that has an
open serial connection to the Leonardo will lose its connection. This
is in contrast to the Arduino Uno, with which you can reset the main
processor (the ATmega328P) without closing the USB connection (which
is maintained by the secondary ATmega8U2 or ATmega16U2 processor).
This difference has implications for driver installation, uploading,
and communication...
I you might be able to use the setDTR(False), but I have tested this yet. A while back they fixed the bug that were initially associated with setDTR. What operating system are you use this on?
ser = serial.Serial('dev/ttyACM0', 9600)
ser.timeout = 1
ser.setDTR(False)
Let us know if this does not work.
Follow on from - GPS Intermediate Driver Issues
The above was not successfully answered and feel I have new information over the issue to go for a new question.
The issue I am facing is the speed of which data is being delivered by the GPS Intermediate Driver.
I have successfully used Pocket Putty to read the serial ports and see the exact information been exposed.
COM 1 - GPS Intermediate Driver
COM 6 - Serial port to PC (Input data manually)
COM 8 - Virtual serial port for GPS hardware.
When reading COM 8, I can see about 18 NMEA strings appear every ~3 seconds, this is as fast as we can push it over the limited USB connection. And it appears quickly on the display. When reading COM 6 (send data from PC manually), it is displayed equally as quick. So there is no problem with the data been available.
Enter in the GPS Intermediate Driver. When The GPS Intermediate Driver is set to COM1 (Software) and COM6 (Hardware). The data entered on COM6 is displayed on COM1 just as quickly as it was without the GPS Intermediate Driver. The data is unaltered, so if I send "JON" on COM6, it will appear on COM1, even though its not valid NMEA data, which is fine.
The problem is with COM8. When the GPS Intermediate Driver is set to COM1 (Software) and COM8 (Hardware). The data showing in PocketPutty on COM1 is really slow. The output on the screen is about 5 characters per second, the data is valid but it just been delivered very slowly. This to me points out an issue in the implementation of the virtual serial port, as if the GPS Intermediate Driver is not reading all the data just one character at a time, given I have isolated the issue to my virtual serial port.
Can anyone provide a clear example of a virtual serial port implementation, as im not sure what I could change to improve this, given COM8 directly works with GPS software and the PocketPutty application, which indicates the data is available, being read, and is correct.
After getting support from the device manufacturer running a debug build, the cause of the problem was client applications were making to many read calls. The serial port could handle them on its own, but via the GPS Intermediate driver the number of calls were too high and the overhead was crippling the communication, this was down to Mutex locks and general threading issues.
Client applications need to read 960 bytes of data per read to the GPS Intermediate driver for them to work ok. This is not an ideal solution so another fix was found.
The resolution was to add in a WaitForSingleObject(IsThereEnoughGPSDATAEvent, COMTotalTimeout) in the read method, so that all reads would only get data if there was a sufficient amount of data available. Originally I requested 960 to be available in the buffer but i've set it down to just 10 bytes and it still works.
Sample Code
DWORD COM_Read( DWORD hOpenContext, LPVOID pBuffer, DWORD Count )
{
if(gpsThreadEvents[GPS_THREAD_EVENT_DATA_AVAILABLE] != NULL)
{
if(WaitForSingleObject(gpsThreadEvents[GPS_THREAD_EVENT_DATA_AVAILABLE], GPSTimeouts.ReadTotalTimeoutConstant) != WAIT_OBJECT_0)
{
return 0;
}
}
//read code goes in here
return dataOut;
}
I'm trying to build a microprinter using an Arduino and an Epson TM-T88II receipt/POS printer. The printer uses the Epson Esc/POS system, but I can't get it to do anything at all from the Arduino. I'm doing things like:
#include <SoftwareSerial.h>
#define out_pin 3
#define in_pin 2
SoftwareSerial printer = SoftwareSerial(in_pin, out_pin);
void setup()
{
pinMode(in_pin, INPUT);
pinMode(out_pin, OUTPUT);
printer.begin(9600);
delay(1000);
printer.print(0x1B, BYTE);
printer.print('#'); // ESC(HEX 1B) # is supposed to initialize the printer
printer.print("hello world");
printer.print(0xA, BYTE); // print buffer and line feed
}
I just can't get the printer to respond at all. The printer powers up and prints its self test just fine. It's a serial (RS-232) printer, and I'm connecting it to the Arduino through a MAX233 chip. I've checked and rechecked my connections through the chip, which I think are right based on a friend who has a similar setup working. I read somewhere that the TM-T88 printers need null-modem serial cables, so I bought an adapter, and that didn't seem to make any difference.
I'm new to electronics, so I'm completely stumped. I just want to get it to print something, so I can get to the fun part - the programming :). Any thoughts on things to test/try? I can give more detail on wiring or anything else, just didn't want this to get TOO long.
Are you using an RS-232 transceiver? The Arduino outputs 0 and 5 V for serial, while the printer uses -12 and 12 V for serial. You should use a MAX232 or similar device to get the correct physical interface. (You might be able to cheat if you invert the serial port on the Arduino, but that might not work, and it's more trouble when just getting started.)
Once that's taken care of, the RTS and DTR may be your problem. You should be able to change the DIP-switch settings on the printer and turn off flow control altogether, or switch it to software flow control.
Also, you may need to send both line feed and carriage return.
However, once all that's done it should print just fine, even without any reset commands. Send a bunch of ASCII characters and line feed/carriage returns, and it'll spit it all out.
You can ignore the RX line (on the Arduino side, TX on the printer side) for now - just send it data until you figure out the wiring, level conversion, flow control, etc.
You could check whether you can communicate with a PC, both from the Arduino and to the printer.
I would use an oscilloscope to see if the serial signals come out of the Arduino and the MAX as they should, but then you probably don't have one.
Are you sure the communication settings are correct? You set the baud rate to 9600, but what about data bits, parity, stop bits? What about the control lines?
I'd hook another PC instead of the printer to the other end of the serial cable and run telnet or PuTTY on that system to make sure you are communicating out and actually talking through the serial port. If so, you could use the same solution to send data to the printer to confirm all settings such as number of data bits, parity, etc.
I've done a similar project and had the same issue. You need a null modem / crossover cable to go from max232 to the printer as both devices are in slave configuration