Connecting/configuring ublox M8n GPS to Mission Planner Passthrough with BBBlu

[Timothy Litvin]

Greetings from the steep learning curve.  I’m setting up my first Arduplane while learning Linux on my first AP (BBBlue) with my first GCS (Mission Planner) on Windows 10, for use in a custom vessel. Practically speaking, it's been a recipe for delayed gratification, uncomfortably akin to a monkey with a typewriter. 

I now have blue-arduplane running on the Bone (sudo /usr/bin/ardupilot/blue-arduplane -C udp:192.168.8.132:14550 -B /dev/ttyO5 with telemetry reporting via wifi to my Windows 10 laptop, but no signal arrives from the GPS (booted, with flashing blue led). My GPS is a generic ublox neo-M8n (with compass), plugged into the GPS jst-sh (wired according to attached jpeg). Windows Device Manager reports ublox Virtual Com Port on COM5. 

I’m guessing the GPS needs to be further configured, i.e., I need to either download/install or create a new ublox-M8 configuration file. I've installed u-center to configure the GPS; u-center reports nothing.  That feed seems to imply/require a Passthrough connection in Mission Planner while running blue-arduplane) so, in the Flight Data screen, ctrl-F:

• It’s unclear whether the “MAVSerial pass” button is activated on click (doesn’t toggle color, just grays temporarily on rollover & click).
• u-center 8.25 doesn’t detect GPS on any port. Tried also creating a TCP connection in u-center through Network Connection, New, setting Address to tcp://localhost:500, set baud to 38400 (with and without AutoBaud) after which I get a Connection Error message.

I then installed minicom on the Bone. When I run "dmesg | grep tty" I get:

 

[    0.000000] Kernel command line: console=ttyO0,115200n8 root=UUID=1b96dc8c-4e92-4f4f-86de-36d769439063 ro rootfstype=ext4 rootwait coherent_pool=1M net.ifnames=0 quiet cape_universal=enable

[    0.002863] WARNING: Your 'console=ttyO0' has been replaced by 'ttyS0'

[    2.492065] 44e09000.serial: ttyS0 at MMIO 0x44e09000 (irq = 158, base_baud = 3000000) is a 8250

[    2.505478] console [ttyS0] enabled

[    2.506866] 48022000.serial: ttyS1 at MMIO 0x48022000 (irq = 159, base_baud = 3000000) is a 8250

[    2.507975] 48024000.serial: ttyS2 at MMIO 0x48024000 (irq = 160, base_baud = 3000000) is a 8250

[    2.509094] 481a6000.serial: ttyS3 at MMIO 0x481a6000 (irq = 161, base_baud = 3000000) is a 8250

[    2.510109] 481a8000.serial: ttyS4 at MMIO 0x481a8000 (irq = 162, base_baud = 3000000) is a 8250

[    2.511416] 481aa000.serial: ttyS5 at MMIO 0x481aa000 (irq = 163, base_baud = 3000000) is a 8250

[    9.819121] systemd[1]: Created slice system-getty.slice.

[    9.831852] systemd[1]: Created slice system-serial\x2dgetty.slice.

 

In Minicom I took a blind whack at setting Serial Port ttyS5 (and ttyS4) to 38400 Baud, 8N1 and Hardware control on/off, to my chagrin, no effect on the non-existent GPS connection. U-center still can't connect, so I can't configure the GPS...if that's what i need to do. Minicom reports the port's values have been changed, but  "dmesg | grep tty" reports the same as above, unchanged. I've also tried using the -B /dev/ttyS5 alternative for GPS when starting blue-arduplane. At this point it occurs to me that I could've steered wrong repeatedly, or just missed a step. 

If you know what you’re doing, by now it’s probably clear that I don’t. Helpful hints anyone? 

[Robert Nelson]

so you need to connect the pin to the peripheral:

#uart 2 (gps)
config-pin P9.21 uart
config-pin P9.22 uart

#uart 1
config-pin P9.24 uart
config-pin P9.26 uart

PS, i just pushed an arduplane deb update today too..

Regards,

--
Robert Nelson
https://rcn-ee.com/

[Jason Kridner]

With my latest device tree patches, it should be UART by default without any config-pin calls.

Most of these GPS devices are 4800 or 9600 baud by default.

I've created a page for one-liner tests for various modules: https://github.com/beagleboard/beaglebone-blue/wiki/One-Liner-Module-Tests

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/CAOCHtYgGjBjPfyc6Cmqo5Wep6%2BWMNBCr0Rhu2kw6a9M-DzLBqA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[Timothy Litvin]

Thanks Robert, I've loaded your update. I had assumed the BBBlue had those pins pre-allocated (as the PCB silkscreen indicates).  Mirko's instructions made the GPS sound like plug-n-play, not referencing additional setup. I’ve installed the config-pin utility, and a command-line entry of the line sudo config-pin P9.21 uart informs me “P9_21 pinmux file not found! Please verify your Device Tree File.”  From this I take it that I need to load cape-universala… 

[Robert Nelson]

On Thu, Jun 29, 2017 at 10:20 AM, Timothy Litvin <capnt...@gmail.com> wrote:
> Thanks Robert, I've loaded your update. I had assumed the BBBlue had those
> pins pre-allocated (as the PCB silkscreen indicates). Mirko's instructions
> made the GPS sound like plug-n-play, not referencing additional setup. I’ve
> installed the config-pin utility, and a command-line entry of the line sudo
> config-pin P9.21 uart informs me “P9_21 pinmux file not found! Please verify
> your Device Tree File.” From this I take it that I need to load
> cape-universala…

it's actually installed by default, and our local version has a few
changes from Charles' original.

it was only a recent kernel that has the uart change by default..

Please run:

sudo /opt/scripts/tools/version.sh

and copy the output to us for review

[Timothy Litvin]

debian@beaglebone:~$ sudo /opt/scripts/tools/version.sh

git:/opt/scripts/:[6d017b3c0902fd4e67fa6ef4801139da9a1726d6]

eeprom:[A335BNLTBLA21712EL005600]

dogtag:[BeagleBoard.org Debian Image 2017-02-19]

bootloader:[eMMC-(default)]:[/dev/mmcblk1]:[U-Boot 2017.03-rc2-00002-g11d4fd]

kernel:[4.4.68-ti-rt-r111]

nodejs:[v4.8.3]

device-tree-override:[dtb=am335x-boneblue-ArduPilot.dtb]

debian@beaglebone:~$

[Robert Nelson]

On Thu, Jun 29, 2017 at 11:44 AM, Timothy Litvin <capnt...@gmail.com> wrote:
> debian@beaglebone:~$ sudo /opt/scripts/tools/version.sh
> git:/opt/scripts/:[6d017b3c0902fd4e67fa6ef4801139da9a1726d6]
> eeprom:[A335BNLTBLA21712EL005600]
> dogtag:[BeagleBoard.org Debian Image 2017-02-19]
> bootloader:[eMMC-(default)]:[/dev/mmcblk1]:[U-Boot
> 2017.03-rc2-00002-g11d4fd]
> kernel:[4.4.68-ti-rt-r111]
> nodejs:[v4.8.3]
> device-tree-override:[dtb=am335x-boneblue-ArduPilot.dtb]

You don't need this /boot/uEnv.txt dtb modification

Jason fixed the base/default: am335x-boneblue.dtb last week? (maybe 2 weeks ago)

So just remove the dtb=am335x-boneblue-ArduPilot.dtb from /boot/uEnv.txt

[Timothy Litvin]

Hi Jason, thanks for your support as well. The One-Liner tests should be a great help. When I try your GPS one-liner verbatim, or set to 9600, the line feeds, but then just sits until I ctrl-C. What does this tell me?

[Jason Kridner]

On Thu, Jun 29, 2017 at 12:57 PM Timothy Litvin <capnt...@gmail.com> wrote:

Hi Jason, thanks for your support as well. The One-Liner tests should be a great help. When I try your GPS one-liner verbatim, or set to 9600, the line feeds, but then just sits until I ctrl-C. What does this tell me?

Can you copy the text out of the window to show what you typed and what you got?

I suspect it means you don't have a GPS lock, which is typical for indoors. Most GPS devices I've played with tend to be a bit quiet when they don't have a lock. They also typically have an LED pattern saying if they have a lock or not.

 

To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/18747066-6ad7-4a02-8918-d7867b1c6049%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

https://beagleboard.org/about

[Timothy Litvin]

My ublox M8n has a blinking blue led which I’ve come to believe means it has at least a good “2D lock”, i.e., at least 3 satellites while here, belowdecks. My breadboard is portable; I took it topside and the GPS LED continues to blink blue, with no apparent change to status. 

The first One-Liner was straight copy/paste from the wiki; then as you can see, I tried a few 4800, 9600, and 38400 (uBlox shipped default baud). 

[Timothy Litvin]

Robert, Easy enough: I’ve deleted the dtb=am335x-boneblue-ArduPilot.dtb from /boot/uEnv.txt and rebooted. So, explicitly, the Blue-Ardupilot recipe line #3 Add BLUE DTB

sudo sed -i 's/#dtb=$/dtb=am335x-boneblue-ArduPilot.dtb/' /boot/uEnv.txt

is now obsolete with Jason’s recent DTB fix.  Now I get: 

kimo@beaglebone:~$ sudo /opt/scripts/tools/version.sh

[sudo] password for kimo:

git:/opt/scripts/:[6d017b3c0902fd4e67fa6ef4801139da9a1726d6]

eeprom:[A335BNLTBLA21712EL005600]

dogtag:[BeagleBoard.org Debian Image 2017-02-19]

bootloader:[eMMC-(default)]:[/dev/mmcblk1]:[U-Boot 2017.03-rc2-00002-g11d4fd]

kernel:[4.4.68-ti-rt-r111]

nodejs:[v4.8.3]

However, having done so hasn’t yet gotten a GPS signal through. A query

desmg | grep tty

returns the same Port report I’ve gotten all along (included in the original post). I’ve nevertheless tried the blue-arduplane/Mission Planner with various parameters, e.g.,

 sudo /usr/bin/ardupilot/blue-arduplane -C udp:192.168.8.132:14550 -B /dev/ttyO2

that continue to transmit telemetry without GPS.

I’ve verified that I’m updated on Debian, blue-arduplane and the RT kernel.  

[Robert Nelson]

On Thu, Jun 29, 2017 at 5:38 PM, Timothy Litvin <capnt...@gmail.com> wrote:
> Robert, Easy enough: I’ve deleted the dtb=am335x-boneblue-ArduPilot.dtb from
> /boot/uEnv.txt and rebooted. So, explicitly, the Blue-Ardupilot recipe line
> #3 Add BLUE DTB
>
> sudo sed -i 's/#dtb=$/dtb=am335x-boneblue-ArduPilot.dtb/' /boot/uEnv.txt
>
> is now obsolete with Jason’s recent DTB fix. Now I get:
>
>
> kimo@beaglebone:~$ sudo /opt/scripts/tools/version.sh
>
> [sudo] password for kimo:
>
> git:/opt/scripts/:[6d017b3c0902fd4e67fa6ef4801139da9a1726d6]
>
> eeprom:[A335BNLTBLA21712EL005600]
>
> dogtag:[BeagleBoard.org Debian Image 2017-02-19]
>
> bootloader:[eMMC-(default)]:[/dev/mmcblk1]:[U-Boot
> 2017.03-rc2-00002-g11d4fd]
>
> kernel:[4.4.68-ti-rt-r111]
>
> nodejs:[v4.8.3]
>
>
> However, having done so hasn’t yet gotten a GPS signal through. A query
>
> desmg | grep tty
>
> returns the same Port report I’ve gotten all along (included in the original
> post). I’ve nevertheless tried the blue-arduplane/Mission Planner with
> various parameters, e.g.,
>
> sudo /usr/bin/ardupilot/blue-arduplane -C udp:192.168.8.132:14550 -B
> /dev/ttyO2
>
> that continue to transmit telemetry without GPS.
>
> I’ve verified that I’m updated on Debian, blue-arduplane and the RT kernel.

Hi Timothy,

i think i found the problem... the pinmux was still not being setup properly..

I just pushed a config-pin update for the Blue..

sudo apt update
sudo apt upgrade
sudo apt install tio

i picked up a uBlox PAM-7Q module, it's only 3.3v so i have it hooked
up to UT1, i know your on GPS connector (5.0v)

So on bootup we see:

(UT1)
debian@beaglebone:~$ config-pin -q P9.24
P9_24 Mode: none
debian@beaglebone:~$ config-pin -q P9.26
P9_26 Mode: none

and (GPS)
debian@beaglebone:~$ config-pin -q P9.21
P9_21 Mode: none
debian@beaglebone:~$ config-pin -q P9.22
P9_22 Mode: none

So by default, using tio:

debian@beaglebone:~$ tio -b 9600 /dev/ttyS1
[tio 16:32:20] tio v1.20
[tio 16:32:20] Press ctrl-t q to quit
[tio 16:32:20] Connected


<nothing>

If i switch P9.24/P9.26 to uart:

debian@beaglebone:~$ config-pin P9.24 uart
debian@beaglebone:~$ config-pin P9.26 uart
debian@beaglebone:~$ config-pin -q P9.24
P9_24 Mode: uart
debian@beaglebone:~$ config-pin -q P9.26
P9_26 Mode: uart

then fire up tio:

debian@beaglebone:~$ tio -b 9600 /dev/ttyS1
[tio 16:33:08] tio v1.20
[tio 16:33:08] Press ctrl-t q to quit
[tio 16:33:08] Connected
W$GPRMC,163309.00,V,,,,,,,300617,,,N*70
$GPVTG,,,,,,,,,N*30
$GPGGA,163309.00,,,,,0,00,99.99,,,,,,*68
$GPGSA,A,1,,,,,,,,,,,,,99.99,99.99,99.99*30
$GPGSV,3,1,11,01,31,123,,07,46,149,17,08,32,052,17,11,50,107,19*74
$GPGSV,3,2,11,13,31,299,21,15,08,327,,17,26,215,,19,02,218,*76
$GPGSV,3,3,11,27,00,046,,28,64,291,,30,79,211,23*42
$GPGLL,,,,,163309.00,V,N*44
$GPRMC,163310.00,V,,,,,,,300617,,,N*78


In your case run:


debian@beaglebone:~$ config-pin P9.21 uart
debian@beaglebone:~$ config-pin P9.22 uart


debian@beaglebone:~$ tio -b 9600 /dev/ttyS2

and see that happens (9600 might not be the baud)

I've added both UT1 and GPS info here:

https://github.com/beagleboard/beaglebone-blue/wiki/Pinouts

[Jason Kridner]

Robert,

Can we make sure the Blue UART pins default to UART and that config-pin is not necessary? This is critical to our expected user experience where the I/O ports are defined by their default function.

What did I do wrong?

Regards,

Jason

--

https://beagleboard.org/about

[Robert Nelson]

On Fri, Jun 30, 2017 at 11:51 AM, Jason Kridner <jkri...@gmail.com> wrote:
> Robert,
>
> Can we make sure the Blue UART pins default to UART and that config-pin is
> not necessary? This is critical to our expected user experience where the
> I/O ports are defined by their default function.
>
> What did I do wrong?

I'm not sure, i had assumed your dts changes would make it default..
but it didn't..

I'll shove it in the bootscript, to fix it now...

cd /opt/scripts/tools/
git pull

[Robert Nelson]

Okay that's fixed:

If config-pin is too old, it'll complain..

debian@beaglebone:~$ journalctl | grep am335x_evm: | grep config-pin
Jun 30 17:23:51 beaglebone sh[429]: am335x_evm: broken
/usr/bin/config-pin upgrade bb-cape-overlays

once it's updated..

debian@beaglebone:~$ journalctl | grep am335x_evm: | grep config-pin
Jun 30 17:27:17 beaglebone sh[412]: am335x_evm: config-pin: GPS:
Setting P9.21/P9.22 as: uart: [/dev/ttyS2]
Jun 30 17:27:17 beaglebone sh[412]: am335x_evm: config-pin: UT1:
Setting P9.24/P9.26 as: uart: [/dev/ttyS1]

debian@beaglebone:~$ config-pin -q P9.24
P9_24 Mode: uart
debian@beaglebone:~$ config-pin -q P9.26
P9_26 Mode: uart

debian@beaglebone:~$ config-pin -q P9.21

P9_21 Mode: uart
debian@beaglebone:~$ config-pin -q P9.22
P9_22 Mode: uart

debian@beaglebone:~$ tio -b 9600 /dev/ttyS1
[tio 17:30:57] tio v1.20
[tio 17:30:57] Press ctrl-t q to quit
[tio 17:30:57] Connected
$GPRMC,173058.00,V,,,,,,,300617,,,N*76
$GPVTG,,,,,,,,,N*30
$GPGGA,173058.00,,,,,0,00,99.99,,,,,,*6E
$GPGSA,A,1,,,,,,,,,,,,,99.99,99.99,99.99*30
$GPGSV,1,1,02,13,,,19,17,,,22*77
$GPGLL,,,,,173058.00,V,N*42
$GPRMC,173059.00,V,,,,,,,300617,,,N*77

[Timothy Litvin]

First, I'm genuinely appreciative of the time and attention you guys are putting into this. I was actually worried that I've overextended my pleading quota. That said, after running 

sudo apt update 
sudo apt upgrade 
sudo apt install tio

It seems I'm still across town from Easy Street, without functioning pinmux file:

debian@beaglebone:~$ config-pin P9.21 uart

P9_21 pinmux file not found!

Please verify your device tree file

debian@beaglebone:~$

   
I check the ports again...

debian@beaglebone:~$ dmesg | grep tty

[    0.000000] Kernel command line: console=ttyO0,115200n8 root=UUID=1b96dc8c-4e92-4f4f-86de-36d769439063 ro rootfstype=ext4 rootwait coherent_pool=1M net.ifnames=0 quiet cape_universal=enable

[    0.002905] WARNING: Your 'console=ttyO0' has been replaced by 'ttyS0'

[    2.488082] 44e09000.serial: ttyS0 at MMIO 0x44e09000 (irq = 158, base_baud = 3000000) is a 8250

[    2.501480] console [ttyS0] enabled

[    2.502849] 48022000.serial: ttyS1 at MMIO 0x48022000 (irq = 159, base_baud = 3000000) is a 8250

[    2.503933] 48024000.serial: ttyS2 at MMIO 0x48024000 (irq = 160, base_baud = 3000000) is a 8250

[    2.505034] 481a6000.serial: ttyS3 at MMIO 0x481a6000 (irq = 161, base_baud = 3000000) is a 8250

[    2.506066] 481a8000.serial: ttyS4 at MMIO 0x481a8000 (irq = 162, base_baud = 3000000) is a 8250

[    2.507345] 481aa000.serial: ttyS5 at MMIO 0x481aa000 (irq = 163, base_baud = 3000000) is a 8250

[    9.537077] systemd[1]: Created slice system-getty.slice.

[    9.613554] systemd[1]: Created slice system-serial\x2dgetty.slice.

debian@beaglebone:~$

...which are unchanged.

I run the tio command anyway, trying several different baud (4800, 9600, 38400) on ttyS1 and ttyS2 and, unsurprisingly, get no GPS:

debian@beaglebone:~$ tio -b 38400 /dev/ttyS1

[tio 06:21:56] tio v1.20

[tio 06:21:56] Press ctrl-t q to quit

[tio 06:21:56] Connected

[tio 06:22:01] Disconnected

[Jason Kridner]

I doubt this is the correct default baud rate. Can you try 9600 and 4800?

--

https://beagleboard.org/about

[Jason Kridner]

Ooops, I didn't read your e-mail well. I see you said you tried each.

Running 'sudo perl /opt/scripts/device/bone/show-pins.pl' is often helpful for debugging the pinmux situation.

--

https://beagleboard.org/about

[Robert Nelson]

On Sat, Jul 1, 2017 at 1:34 AM, Timothy Litvin <capnt...@gmail.com> wrote:
> First, I'm genuinely appreciative of the time and attention you guys are
> putting into this. I was actually worried that I've overextended my pleading
> quota. That said, after running
>
> sudo apt update
> sudo apt upgrade
> sudo apt install tio
>
> It seems I'm still across town from Easy Street, without functioning pinmux
> file:
>
> debian@beaglebone:~$ config-pin P9.21 uart
> P9_21 pinmux file not found!
> Please verify your device tree file

it shouldn't be doing that..

try with the full path:

/usr/bin/config-pin P9.21 uart

ps, if you do:

cd /opt/scripts/
git pull

and then reboot and run:

journalctl | grep am335x_evm

it should auto-set it as a uart.

[Timothy Litvin]

So I’ve re-flashed the Blue, upgraded, updated and reinstalled blue-arduplane (without the original uEnv.txt dtb substitution), and connected WIFI via connmanctl. The board is working again, with comms back. GPS blue LED is blinking (meaning that it has a GPS lock). I can again run blue-arduplane and receive telemetry via WIFI to my laptop but no GPS. I then ran…

config-pin –q

…on P9.21 and P9.22 and confirmed that those pins are now, in fact, pre-assigned as UART.  Progress. Thank you for that simplification.

At this point I understand (please correct me if I’m wrong) that no further action is required to use the UART connector silkscreened “GPS” on the BBBlue, except for configuring the connection for my specific GPS’ COM parameters. My uBlox neo-M8n, purchased from Hobby King, states “This module ships with a baud rate of 38400, 10Hz”.  I have not yet setup u-center to modify the GPS' firmware, so I’ll include the stated default baud in my testing, as well as the more common 4800 and 9600 baud and, while I'm at it, 19200.

I then install the TTY terminal application tio…

sudo apt install tio

 

Running tio to set the connection baud of a specific port, I get back…

debian@beaglebone:~$ tio -b 9600 /dev/ttyS1 

[tio 18:52:00] tio v1.20 
[tio 18:52:00] Press ctrl-t q to quit 
[tio 18:52:00] Connected

…no matter the baud (4800, 9600, 19200 or 38400) or the port (ttyS1, ttyS2).  None of those alternatives yet yields GPS data; it just hangs at “Connected” until I…

ctrl-t q

Then, running Jason’s One-Liner GPS test…

stty -F /dev/ttyO2 ispeed 4800 ospeed 4800;tail -f /dev/ttyO2

# also then with /dev/ttyS1 and /dev/ttyS2

…with the same baud and port parameter variations above also just hangs at the command line, until I ctrl-C. My guess is that this means the software tools are working, telling me that this monkey is still missing something important.   

[Timothy Litvin]

In my previous post I re-flashed the BBBlue because, after some amount of poking around troubleshooting, on reboot somehow I had disabled all my comms.  So: clean slate. Reflash. I setup WIFI and, with an updated Debian image, installed the most recent recipe for blue-arduplane, (the latest build that pre-assigns the BBBlue GPS socket’s pins P9.21 and P9.22 as UART):

sudo apt update && sudo apt upgrade –y

sudo apt install -y bb-cape-overlays cpufrequtils ardupilot-plane-blue 

sudo sed -i 's/GOVERNOR="ondemand"/GOVERNOR="performance"/g' /etc/init.d/cpufrequtils

cd /opt/scripts && sudo git pull

sudo /opt/scripts/tools/update_kernel.sh --ti-rt-channel --lts-4_4

sudo reboot

 

I use tio to query the pins (on ttyS2) and confirmed they’re UART.  The blue LED on the uBlox is blinking to indicate satellite lock. When I attempt to connect to my uBlox M8n GPS, (blindly using 4800, 9600, 19200, 38400 baud on that port) I still get no GPS data stream.  So I checked the GPS output on the o’scope and get 9600 baud pulses on the GPS’ Tx pin (and nothing on the Rx pin). I try config-pin query again with:

tio -b 9600 /dev/ttyS2

…and Jason’s one-liner tests

stty -F /dev/ttyO2 ispeed 9600 ospeed 9600;tail -f /dev/ttyO2

…with no response from the GPS.

Did I miss something? 

[Robert Nelson]

Is there any chance the tx/rx is reversed on the ublox module?

[Timothy Litvin]

I've wondered that too, but haven't yet switched them; I wanted to first confirm that the software really should be that simple.
I'm probing the GPS signal at the uBlox board itself, definitely the wire silkscreened "Tx": I'm getting a signal there. Not likely my spliced connector leads are shorted: they're soldered and wrapped. On the BBBlue, that wire is connected to the 4th pin from the silkscreened dot (which I assume is the Pin1 connector end, furthest from the USB end of the board) corresponding to UART2_Tx on the GPS connector in the schematic.  The fact that the uBlox is powered-up suggests my assumptions about the pin numbering are correct. I had dismissed the thought that these might need to be wired Tx/Rx cross-over, but suddenly I'm less sure of that.

[Jason Kridner]

Indeed, TX on the GPS (the one spitting out data) should be RX on the UART. 

[Timothy Litvin]

Aaaaaaand. Done. I have GPS and blue-arduplane. Thanks Robert and Jason. Now you'll be able to say you "knew me when..."
Cheers to you both. 

[gr...@meraki-digital.com]

I'm reading through all of this and I just feel like I am very close.

When I try

config-pin P9.21 uart

config-pin P9.22 uart

I get

bash: /sys/devices/platform/ocp/ocp*P9_21_pinmux/state: No such file or directory
Cannot write pinmux file: /sys/devices/platform/ocp/ocp*P9_21_pinmux/state

Same thing if I try sudo in front of the command.

The P9 output from

sudo perl /opt/scripts/device/bone/show-pins.pl | grep P9.

is as follows (if it helps)

P9.15                             16 R13 fast rx down 7 gpio 1.16        ocp/P9_15_pinmux (pinmux_P9_15_default_pin)
P9.23                             17 V14 fast rx down 7 gpio 1.17        ocp/P9_23_pinmux (pinmux_P9_23_default_pin)
P9.14                             18 U14 fast rx down 7 gpio 1.18        ocp/P9_14_pinmux (pinmux_P9_14_default_pin)
P9.16                             19 T14 fast rx down 7 gpio 1.19        ocp/P9_16_pinmux (pinmux_P9_16_default_pin)
P9.11                             28 T17 fast rx down 6 uart 4 rxd       serial@481aa000 (pinmux_bb_uart4_pins)
P9.13                             29 U17 fast    down 6 uart 4 txd       serial@481aa000 (pinmux_bb_uart4_pins)
P9.12                             30 U18 fast rx down 7 gpio 1.28        ocp/P9_12_pinmux (pinmux_P9_12_default_pin)
P9.15                             34 T13 fast rx  up  7 gpio 2.00
P9.22 / spi boot clk              84 A17 fast rx down 1 uart 2 rxd       serial@481a6000 (pinmux_bb_uart2_pins)
P9.21 / spi boot in               85 B17 fast    down 1 uart 2 txd       serial@481a6000 (pinmux_bb_uart2_pins)
P9.18 / spi boot out              86 B16 fast rx down 7 gpio 0.04        ocp/P9_18_pinmux (pinmux_P9_18_default_pin)
P9.17 / spi boot cs               87 A16 fast rx down 7 gpio 0.05        ocp/P9_17_pinmux (pinmux_P9_17_default_pin)
P9.42a                            89 C18 fast rx down 7 gpio 0.07        ocp/P9_42_pinmux (pinmux_P9_42_default_pin)
P9.20 / cape i²c sda              94 D18 fast rx  up  3 i²c 2 sda        ocp/P9_20_pinmux (pinmux_P9_20_default_pin)
P9.19 / cape i²c scl              95 D17 fast rx  up  3 i²c 2 scl        ocp/P9_19_pinmux (pinmux_P9_19_default_pin)
P9.26                             96 D16 fast rx down 0 uart 1 rxd       serial@48024000 (pinmux_bb_uart1_pins)
P9.24                             97 D15 fast    down 0 uart 1 txd       serial@48024000 (pinmux_bb_uart1_pins)
P9.31 / hdmi audio clk           100 A13 fast rx down 7 gpio 3.14        ocp/P9_31_pinmux (pinmux_P9_31_default_pin)
P9.29 / hdmi audio fs            101 B13 fast rx down 7 gpio 3.15        ocp/P9_29_pinmux (pinmux_P9_29_default_pin)
P9.30                            102 D12 fast rx down 7 gpio 3.16        ocp/P9_30_pinmux (pinmux_P9_30_default_pin)
P9.28 / hdmi audio data          103 C12 fast rx down 7 gpio 3.17        ocp/P9_28_pinmux (pinmux_P9_28_default_pin)
P9.42b                           104 B12 fast rx down 7 gpio 3.18        ocp/P9_92_pinmux (pinmux_P9_92_default_pin)
P9.27                            105 C13 fast rx down 7 gpio 3.19        ocp/P9_27_pinmux (pinmux_P9_27_default_pin)
P9.41                            106 D13 fast rx down 7 gpio 3.20        ocp/P9_91_pinmux (pinmux_P9_91_default_pin)
P9.25 / audio osc                107 A14 fast rx down 7 gpio 3.21        ocp/P9_25_pinmux (pinmux_P9_25_default_pin)
P9.41 / jtag emu3                109 D14 fast rx down 7 gpio 0.20        ocp/P9_41_pinmux (pinmux_P9_41_default_pin)

On Tuesday, June 27, 2017 at 5:39:17 PM UTC-5, Timothy Litvin wrote:

Greetings from the steep learning curve.  I’m setting up my first Arduplane while learning Linux on my first AP (BBBlue) with my first GCS (Mission Planner) on Windows 10, for use in a custom vessel. Practically speaking, it's been a recipe for delayed gratification, uncomfortably akin to a monkey with a typewriter. 

I now have blue-arduplane running on the Bone (sudo /usr/bin/ardupilot/blue-arduplane -C udp:192.168.8.132:14550 -B /dev/ttyO5 with telemetry reporting via wifi to my Windows 10 laptop, but no signal arrives from the GPS (booted, with flashing blue led). My GPS is a generic ublox neo-M8n (with compass), plugged into the GPS jst-sh (wired according to attached jpeg). Windows Device Manager reports ublox Virtual Com Port on COM5. 

I’m guessing the GPS needs to be further configured, i.e., I need to either download/install or create a new ublox-M8 configuration file. I've installed u-center to configure the GPS; u-center reports nothing.  That feed seems to imply/require a Passthrough connection in Mission Planner while running blue-arduplane) so, in the Flight Data screen, ctrl-F:

• It’s unclear whether the “MAVSerial pass” button is activated on click (doesn’t toggle color, just grays temporarily on rollover & click).
• u-center 8.25 doesn’t detect GPS on any port. Tried also creating a TCP connection in u-center through Network Connection, New, setting Address to tcp://localhost:500, set baud to 38400 (with and without AutoBaud) after which I get a Connection Error message.

I then installed minicom on the Bone. When I run "dmesg | grep tty" I get:

 

[    0.000000] Kernel command line: console=ttyO0,115200n8 root=UUID=1b96dc8c-4e92-4f4f-86de-36d769439063 ro rootfstype=ext4 rootwait coherent_pool=1M net.ifnames=0 quiet cape_universal=enable

[    0.002863] WARNING: Your 'console=ttyO0' has been replaced by 'ttyS0'

[    2.492065] 44e09000.serial: ttyS0 at MMIO 0x44e09000 (irq = 158, base_baud = 3000000) is a 8250

[    2.505478] console [ttyS0] enabled

[    2.506866] 48022000.serial: ttyS1 at MMIO 0x48022000 (irq = 159, base_baud = 3000000) is a 8250

[    2.507975] 48024000.serial: ttyS2 at MMIO 0x48024000 (irq = 160, base_baud = 3000000) is a 8250

[    2.509094] 481a6000.serial: ttyS3 at MMIO 0x481a6000 (irq = 161, base_baud = 3000000) is a 8250

[    2.510109] 481a8000.serial: ttyS4 at MMIO 0x481a8000 (irq = 162, base_baud = 3000000) is a 8250

[    2.511416] 481aa000.serial: ttyS5 at MMIO 0x481aa000 (irq = 163, base_baud = 3000000) is a 8250