I'm having trouble connecting to a GPS module with my Edison.
I'd like to read from it (obviously). But I cannot find which device it is. After more searching than I'm happy about, it seems that I should be looking for /dev/ttyUSB0. However, I have yet to see that device.
I already tried switching to the unofficial opkg repo and installing the FTDI driver from there. I ran into the issue of the default partition being too small. So then I resized my partition size as per http://alextgalileo.altervista.org/blog/install-kernel-from-repo-onto-edison-official-image/ this post (to be clear, I completed step 4 and stopped) and ran "opkg install kernel-module-ftdi-sio". There was no complaint trying to install it after resizing the partition. But that still didn't solve the issue, and /dev/ttyUSB0 is still nowhere to be found.
I'm trying to avoid having to install a new image/kernel if I don't have to. I want to verify that this isn't a problem on my end before I do that.
Let me give some more background on the problem.
-I am using the https://www.sparkfun.com/products/13045 Spark Fun Edison base block (among other blocks).
-There is an OTG cable connected to the "OTG" port on the Edison
-From there I connect to one of these https://www.parallax.com/product/32201 USB-Serial adapters
-I made a connector to connect the adapter to this https://www.sparkfun.com/products/8975 GPS module, as well as to power the GPS (from an external 3.3v source). One of the 2 ground pins on the GPS is wired to the ground of the 3.3v power supply, and the other ground pin is connected to the "VSS" pin on my USB adapter. GPS Tx to adapter Rx and GPS Rx to adapter Tx.
-I'm connecting to the Edison from a Win8 machine via putty and serial over USB to the "Serial" port, and sometimes putty via SSH over WiFi (Edison is in/out of AP mode as needed)
-I'm running "Poky (Yocto Project Reference Distro) 1.7.2", according to the message at the end of the boot sequence
-lsusb returns an FTDI device every other boot (I've seen elsewhere on here that the USB-only-on-every-other-boot bug is a thing -I'm not trying to tackle that at this moment, maybe later)
-lsusb "good" output:
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 002: ID 0403:6001 Future Technology Devices International, Ltd FT232 USB-Serial (UART) IC
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
-I see /dev/bus appear whenever lsusb would also tell me there's an FTDI device. However, I kinda get the sense that's not exactly what I'm looking for here, so I didn't spend too much time with it. (but maybe I'm wrong?)
So, how do I connect/read this GPS device? Am I missing something here? I would appreicate any assistance.
The problem you are having could be due to the package you are installing from the AlexT repository. There are some threads where other makers have had the same behavior you are having. I know you are avoiding to build a custom image but it could be the solution for this so I suggest you to build a custom image.
(Check the replies from KurtE, MaoNgo and allene)
(Steps for including FTD_USB into the image)
BSP - http://www.intel.com/support/edison/sb/CS-035278.htm Intel® Edison Boards — Board Support Package (BSP) User Guide
I tried the image linked in the first link from your reply, but that just leaves me with a blank screen when attempting a serial connection to my Edison. I flashed that image there using the flash tool and it said the flash was successful. However, I can't get a terminal to it. When I try and flash the latest official image (as of this writing), using the flash tool, I get a usable Edison. However, still no ttyUSB0 or anything of the sort.
Is there a working image out there for getting the OTG port and serial devices to play nice?
What ended up working for me was a clean flash of the latest official image as of this writing. And then I followed ALL of the instructions in Alex's blog post http://alextgalileo.altervista.org/blog/install-kernel-from-repo-onto-edison-official-image/ here (instead of just stopping after completing step 4).
Then I was able to see and cat /dev/ttyUSB0.
The only thing that's weird, now, is that I used to get continuous output from my GPS receiver when I configured it with stty and then ran cat on the device. But now, every time I run cat, I only get a handful of lines of output each time.
I'm glad to know that you are able to see ttyUSB0 now.
Could you attach a screenshot of what you are getting in those lines?
Are you using a logic analyzer to see these signals?
Have you tried with pull-up resistors?
Here are 5 screenshots of my console to the Edison in question. My connection to the GPS is the same as in OP. The only difference is that I've switched my power source from an external 3.3v to the https://www.sparkfun.com/categories/272 GPIO block from SparkFun. I'm using the 2 pins closest to the main part of the board, the 3.3v and the GND pins, on that block, to power the GPS.
All I did before these screenshots were taken was to run "stty -F /dev/ttyUSB0 57600". Then I ran "cat" on the device and took a screenshot of every output. I then ran "clear" and then the same "cat" command again, between screenshots.
If you'll notice, sometimes it autopopulates my prompt with "PuTTY" as if I typed it, after each time I run "cat". Also, some of the times I ran "cat", it would fill up my window with a lot of output and clear itself to keep going with more output. So some of the screens that show little text might have had a lot of text flash across the console before ending (and I then took my screenshot).
These screenshots are posted in order.
When Putty receives an ^E it will write "Putty" this is because you may be receiving some binary data. When you open Putty, you can go to Terminal and you will see the option "Answerback to ^E"
About the messages you are receiving, have you set all the settings of the device with stty? You can check this by running sty -F /dev/ttyUSB0 -a
What should you be receiving (format, data, values…) after cat /dev/ttyUSB0?
I had no idea bout PuTTY's behavior w/control characters like that. I just changed that setting and the "PuTTY" spam on my terminal is gone. But the rest of the behavior still persists. Here's the output from stty -F /dev/ttyUSB0
root@testEdison1:~# stty -F /dev/ttyUSB0 -a
speed 9600 baud;stty: /dev/ttyUSB0
line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = ;
eol2 = ; swtch = ; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R;
werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 0;
-parenb -parodd cs8 hupcl -cstopb cread clocal -crtscts
-ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr icrnl ixon -ixoff
-iuclc -ixany -imaxbel -iutf8
opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
isig icanon iexten echo echoe echok -echonl -noflsh -xcase -tostop -echoprt
Pay no attention to the speed. I set that to 57600 in my code to read from it. At 9600, it gives me gibberish characters.
And now, before I go further, let me give you a little more of an update. I have code working that reads from the GPS and prints it to the command line. This code can be made to run in an infinite loop and it will continuously read from GPS and output -this part is working. It turns out, after running cat /dev/ttyUSB0 > output.txt, and inspecting the text, I found that the GPS is sending control characters to stdin. And because I'm just taking a raw byte stream from the GPS into stdin, and then flipping it right back to stdout, the control characters were being consumed. Observing the text file of the output allowed me to see the literals of these otherwise invisible control characters that were influencing my terminal.
Curiously, this happens, even though I opened the the device with the "O_NOCTTY" flag, among others, like so: gpsFD = open(dev, O_RDWR | O_NOCTTY | O_NDELAY); If I'm understanding the part about O_NOCTTY correct, http://linux.die.net/man/2/open as posted here, then doesn't that flag mean my console (terminal) shouldn't be obeying commands from this tty (my GPS device)? This code is C++, not C, for what it's worth.
As of now, I am actually happy with how my code works. I do listen for control characters using iscntrl(), and ignore them accordingly. I guess I'm just unhappy with the overhead of having to read in one character at a time and checking that it's not a mischievous control character about to mess with my terminal, in the process of reading for good input from the GPS -I'd have much preferred if I could just read in the GPS as a raw stream of data and then pass it along to where it needs to go, without grooming it on arrival (grooming/parsing input after it has been gathered is both ok and expected).
If you have any suggestions for this, I'd appreciate them. If not and/or if I'm chasing after a solution that doesn't exist (or doesn't need to exist), then no worries. And thank you for your help!
I'm glad to know that you have better results now.
Is there a way to configure the GPS device? In order to send data in another format.
Have you tried with other flags while opening the file?
Another alternative is to create a script that receives the file and check all the data in it in order to translate it in the format you want.
Those are some ideas, I hope it helps.