Retrieve data from a USB port
 

Hi everybody.
I'm using uClinux and compiling with arm-linux-gcc.
I would like to connect to a USB GPS and retrieve its data saving them in a file.
The USB GPS is seen as a common read-only tty port .
I think I setted properly the \dev\ttyUSB0 port using the
struct termios options (bautrate, parity, 8 data bits etc)
and I can open it, but I can't manage to successfully retrieve data from it, it gives me blank spaces or unreadable characters.....
I tried with cat but it works only in the bash and like above.
If someone can give me any hint it would be very kind of him/her and I would be gratefull.
Thanks in advance and
1) Please I'm sorry for my English
2) Sorry I'm a Linux newby

Hi,
part of my code is

fd = open("/dev/ttyUSB0", O_RDWR | O_NOCTTY | 0);
options.c_cc[VMIN] = 1;
options.c_cflag |= (CLOCAL | CREAD);
options.c_cc[VTIME] = 60;
cfsetispeed(&options, B4800);
cfsetospeed(&options, B4800);
tcsetattr(fd, TCSANOW, &options);
read(fd, &read, 10);
printf("Reading on ttyUSB0 : %s\n", read);
cat.exe ./dev/ttyUSB0 > ./home/usr1/usbdata.txt ;


but the cat isn't recognized as a command and the read produce white spaces and an empty file.
If someone can give me a hint I would be gratefull.
Thank you in advance.
Best Regards
Ninaeve

Are you sure there device can be expected to return human-readable ASCII data? If so, have you tried communicating with it interactively, using a known-good terminal emulator?

--- rod.

@ theNbomr
 

Thanks theNbomr,

I assumed that a GPS receiver would return human-readable ASCII data, otherwise.....
Can you please suggest me a (possibly freeware) known-good terminal emulator for Windows?
Thanks for the suggestions, I'll check them out.
Ninaeve

I don't use Windows, but last time I did, it included something called Hyperterm (?). But why do you want to use Windows? Your first post talks about uClinux, termios, etc. In Linux, my preferred terminal emulator is C-Kermit. If the GPS receiver shows up as a serial port, that should be all you need.
You cannot always assume that devices communicate using ASCII string data. I've never used a GPS receiver, but many devices try to maximize throughput by using structured binary data. In such cases, you would need to have some documentation that explains how to interpret the data.

--- rod.

Have you tried different baudrates? 4800 seems to be quite small as for decent devices.

First : Thank you all very much for the suggestions!

@ theNbomr: I use uClinux as embedded sistem but I unfortunately have to test in Windows, but I meant that in this way if I have some porting problem ^_^''' I can see what is happening anyway.
I'll test C-Kermit.

@ formiaczek: I checked the baudrate in the pdf data sheet the producer gave me (the very only document apart from the Windows drivers) so that's it, but I don't need high speed GPS, it's ok.

Member response
 

Hi,
Device documentation should provide the format for your GPS. I used a older Garmin with ASCII output without any issues. You just need to know the message format protocol, baud rate, byte/word format;
Do a Google or DuckDuckGo search to get the format protocol for your device.
HTH!

Hi ! The data are in NMEA http://en.wikipedia.org/wiki/NMEA_0183 code so they are indeed ASCII sentences with the baudrate, bit length etc I imposed.
So how do I read from the port and create an ASCII file with the data?
I'm a Linux newby and I'm aware of it.

If someone can give me a hint I will be gratefull.
Best Regards
Ninaeve

Member response
 

Hi,

Please explain how you have the GPS device physically connected to your system(embed or desktop)? USB or USB to serial(adapter)? You are not clear enough as to the physical hardware.

What is the GPS model & manufacture?

Why are you speaking earlier about Microsoft Windows connection?

I would suggest we concentrate on using one system to communicate(embed) with the GPS. GPSdrive is a Garmin widget toolkit(example) for Gnu/Linux. Your GPS should have a toolkit of some sort to use.

The way you access the device may be completely different in different OS's. The Windows driver may provide one style of abstraction, while a Linux driver provides a completely different style. Therefore, testing in one environment may provide no transferable information. You say that the Linux driver makes the device look like a serial port, so start from there.
Since we've established that the device may not be sending human-readable ASCII data, I suggest using SerLook in Linux (needs KDE, I think). This will allow you to look at the data in ways that don't make sense in a terminal emulator, and will provide a means to record the data to log files for your analysis.
--- rod.

Member response
 

Hi,

Looks like you can use this daemon;

You still need to provide the requested information so we are not shooting in the dark.

FYI: I suggest that you look at 'How to Ask Questions the Smart Way' so in the future your queries provide information that will aid us in diagnosis of the problem or query.

Hi, and thank you all.
I'm sorry if I wasn' t clear/specific enough on describing my sistem.
(Forgetting about Windows, I'm cross compiling through Cygwin) I'm using a uClinux embedded system, Linux Kernel 2.6.14-M5.
The Realtek GPS is connected to the Linux mini-computer through a USB port but thanks to a Linux driver the USB port is seen as a normal serial port.


Thank you @onebuck and @theNbomr for the suggestions, I'll try with gpsd and SerLook.
Best Regards

Ninaeve

Hi, thanks to various codes I managed to listen to my GPS but: I imposed in termios

options.c__cc[VMIN]=480

and the gcc complained : "warning: large integer implicitly truncated to unsigned type".

Is this actually a real problem?
Anyway : is it possible to vary the type of the termios options?

THANK you all for your suggestion and support
Best REgards
Ninaeve

I haven't looked at the definition of c__cc, but I suspect it is a character type, which means the maximum value is either 127 or 255, depending on whether it it signed or unsigned. Moreover, setting VMIN to a non-zero value, while leaving VTIME at the default value of zero allows for the possibility of waiting forever if a character is dropped while reading a packet. See Serial Programming Guide for POSIX Operating Systems for the details.

--- rod.[COLOR="Silver"]