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):
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:
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.
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/ocpP9_21_pinmux/state: No such file or directory
Cannot write pinmux file: /sys/devices/platform/ocp/ocpP9_21_pinmux/state