Setting up a PPP server and client over GPIO/UART?

[tastycrust]

I'd like to set up an always-on PPP connection between two zeros over their serial ports for a consistent-latency connection to improve clock syncing precision, but I'm not sure where to start. Anyone have sample config files? What packages need to be installed? I've already physically connected tx->rx,rx->tx, gnd->gnd, and they are already using NTP to sync clocks to another computer over wifi, but that's it.

I saw an old post on here from 2013 and it looked like a lot of steps, hoping to take the lazy shortcut.

Also, I want them both to remain connected to wifi as their primary connection to the local network.

[topguy]

I saw an old post on here from 2013 and it looked like a lot of steps, hoping to take the lazy shortcut.

Could have been really helpful with a link to that post.

But basically this link tells you how to use pppd for what you want.
https://www.tldp.org/HOWTO/PPP-HOWTO/direct.html

[tastycrust]

Sorry, good point! This was the post I was referring to: viewtopic.php?t=51633

Thanks for the link, that looks like what I was having trouble gleaning from google.

[tastycrust]

Hmm... so I'm having trouble getting the serial port to work at all.

I've enabled the serial port in raspi-config (and disabled console login), then disabled the hciuart service:
sudo systemctl disable hciuart

I then added the following line to /boot/config.txt:
dtaoverlay=pi3-disable-bt

I rebooted and confirmed hciuart is disabled, and that /dev/serial1 maps to /dev/ttyAMA0.

However, when I attempt to use minicom to do a loopback test (Tx->Rx on same pi):
minicom -o -D /dev/serial1

Nothing prints to screen when I type, and if I put echo on I get only the single instance, not double like I should. Ditto for using pyserial.

Any other steps I should do to check what's wrong? I have double-checked that the correct pins are shorted.

[topguy]

I've enabled the serial port in raspi-config (and disabled console login),

This should be enough.
I dont know why people bother messing with the BT, it should have nothing to do with UART pins.

Check in minicom that not hardware handshaking is not activated.

[tastycrust]

I've enabled the serial port in raspi-config (and disabled console login),

This should be enough.
I dont know why people bother messing with the BT, it should have nothing to do with UART pins.

This is why:

By default, on Raspberry Pis equipped with the wireless/Bluetooth module (Raspberry Pi 3 and Raspberry Pi Zero W), the PL011 UART is connected to the BT module, while the mini UART is used for Linux console output. On all other models the PL011 is used for the Linux console output.

(Source)

So, if you don't switch them, then serial uses mini UART instead of PL011, which has lots of drawbacks from what I've read.

For "hardware handshaking" do you mean the setting "Hardware Flow Control"? I don't see any other references to hardware in the minicom settings.

[topguy]

For "hardware handshaking" do you mean the setting "Hardware Flow Control"?

Yes. If should be turned off if you are just using a 3-wire connection.

[tastycrust]

For "hardware handshaking" do you mean the setting "Hardware Flow Control"?

Yes. If should be turned off if you are just using a 3-wire connection.

OK, I've changed that, saved as default, restarted (just in case it didn't take effect immediately), but still nothing when I type into minicom.

Is there some more basic way to check the functioning of the serial port without messing with minicom? Like can I read/write to /dev/serial1 directly from the command line?

EDIT: I'll add that I've now tried this on both of my Pi Zero W's, and it's not working on either one, so clearly I messed something up along the way.

SECOND EDIT: Actually, on the other Pi Zero W, it works if I use /dev/ttyAMA0, but not if I use /dev/serial1, even though when I look in /dev/ it shows those are mapped. So that's extra confusing. But for the one I've mostly been trying to get working, it doesn't work with either.

[tastycrust]

Solved! Just a word to the wise: If you are going to switch between device tree overlays, make sure you first do a reboot without any overlay before doing the second overlay. In this case, I first tried the pi3-miniuart-bt overlay, but since Bluetooth seemed to be broken using the miniuart, I then switched to the pi3-disable-bt overlay and rebooted. But this scrambled something in the serial port I guess, because once I commented out the overlay line, rebooted, then uncommented it, rebooted again, things worked OK.

Crisis averted!

[tastycrust]

Of course that was premature celebration. I'm pulling my hair out again. Both zeros work fine in loopback, but when I connect them to each other, nothing is sent via minicom. Wired as follows:

Tx1==>Rx2
Rx1==>Tx2
Gnd1=>Gnd2

I'm using the exact same settings in minicom on both cards, but I feel I must be missing something fundamental here. Is there any conceivable reason that loopback would work fine but not card-to-card?

[tastycrust]

Just thought I'd give a final update on this thread since I got everything working OK. I ended up just flashing backed up images to the SD cards from before I started messing with serial port stuff, then starting over again with a modified version of the instructions in this instructable.

Those instructions are for the case where you have a pi without internet access and want the pi to use UART as its primary internet connection. In my case, I still want both RPi0's to use their wifi connection as their primary internet connection, with the PPP connection used only for time syncing, where consistent (and low) latency is more important than high bandwidth.

So here are the modified steps to follow for anyone else who wants to pair two pi's together over serial:

(1) Install the ppp package:

Code: Select all

sudo apt-get install ppp

(2) Disable console login:

Code: Select all

sudo raspi-config
Select option 5, "Interfacing Options"
Select option P6, "Serial" 
Select "No" to login shell and "Yes" to enabling serial port

(3) [For Pi 3 and Pi 0 W ONLY] Decide whether to use the PL011 (which means Bluetooth will be degraded or nonfunctional) or miniUART (your serial connection may not work great but Bluetooth still will work). I have not tested this setup using miniUART, but I assume it would work OK. For PL011, you need to enable one of the device tree overlays that frees PL011 from Bluetooth use. I went with the one that disables bluetooth entirely (pi3-disable-bt), but you can also try the one that switches Bluetooth to miniUART (pi3-minuart-bt) if you want, but it didn't work for me at all. Either open /boot/config.txt with your favorite editor or just add it with this one liner:

Code: Select all

sudo bash -c "echo 'dtoverlay=pi3-disable-bt' >> /boot/config.txt"

(4) To enable a faster connection, speed up the UART clock:

Code: Select all

sudo bash -c "echo 'init_uart_clock=64000000' >> /boot/config.txt"

(5) Next up, time to actually set up the PPP connection. You'll need to pick one pi to be the "server" and the other to be the "client." Since we're not using this for an actual internet connection, it doesn't really matter which is which. On the client, add these lines to /etc/rc.local (BEFORE the exit line!):

Code: Select all

echo "Starting pppd..."
stty -F /dev/ttyAMA0 raw
stty -F /dev/ttyAMA0 -a
pppd /dev/ttyAMA0 1000000 10.0.5.2:10.0.5.1 noauth local debug dump  nocrtscts persist maxfail 0 holdoff 1

On the server, add these lines to /etc/rc.local:

Code: Select all

echo "Starting pppd..."
stty -F /dev/ttyAMA0 raw
pppd /dev/ttyAMA0 1000000 10.0.5.1:10.0.5.2 proxyarp local noauth debug nodetach dump nocrtscts passive persist maxfail 0 holdoff 1

Assuming you have the UART pins connected correctly (Tx-->Rx, Rx-->Tx, Gnd-->Gnd), once you reboot both boards they should automatically establish their connection at boot and keep it connected. There are a few ways to confirm this, but among them are:

Code: Select all

~/$ ip addr show

Which should include "ppp0" with the IP addresses you assigned:

Code: Select all

4: ppp0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdis
 pfifo_fast state UNKNOWN group default qlen 3
    link/ppp
    inet 10.0.5.2 peer 10.0.5.1/32 scope global ppp0
       valid_lft forever preferred_lft forever

You can also test the connection by pinging:

Code: Select all

~/$ ping 10.0.5.1
PING 10.0.5.1 (10.0.5.1) 56(84) bytes of data.
64 bytes from 10.0.5.1: icmp_seq=1 ttl=64 time=1.65 ms
64 bytes from 10.0.5.1: icmp_seq=2 ttl=64 time=1.50 ms
64 bytes from 10.0.5.1: icmp_seq=3 ttl=64 time=1.47 ms
64 bytes from 10.0.5.1: icmp_seq=4 ttl=64 time=1.57 ms
64 bytes from 10.0.5.1: icmp_seq=5 ttl=64 time=1.50 ms
64 bytes from 10.0.5.1: icmp_seq=6 ttl=64 time=1.49 ms

Tada! Now for any data where low-latency is more important than high-bandwidth, you can use these IP addresses to exchange data between the RPi's instead of their LAN IP addresses.