Close

First TCP traffic

A project log for Chirppp, Serial over LORA

Use LORA via GPIO and a full-duplex serial emulator for serial a connection intended for extended range use.

dominic-demarcoDominic DeMarco 08/04/2017 at 03:450 Comments

I sorted out the problems I was having with the pty master and slave. As it turns out, echo is on by default. This means that if the master writes something to the slave and nobody reads it before the master reads, the slave will echo the data right back... not sure who decided to make that option the default, but for my purposes it served as a terrific wrench.

I was making... okay... serial connections. I was losing some packets, duplicating others, I think in order to transmit more reliably I'll have to wire up my vocore better. Here's what it looks like now

The wires are just hanging in the through-holes, I managed to exert enough pressure on the side of them to create a decent connection, but under load I don't think it's handing itself too well. I've been seeing some malformed input and output that wiggling the serial connection to the radio effects, I may have to whip out the soldering iron before too long.

But the connection was stable enough for me to stay up past my bedtime. I went ahead and did some digging on pppd and managed to create a command that would work on both devices.

Here's the command to run on my Vocore (server):

pppd -detach xonxoff noauth lock 192.168.69.1:192.168.69.2 /dev/pts/1 38400 eap-restart 100 lcp-echo-failure 10000 lcp-echo-interval 10 

And here's what I need to run on the CHIP (client)

pppd -detach xonxoff noauth lock 192.168.69.2:192.168.69.1 /dev/pts/2 38400 eap-timeout 100 lcp-echo-failure 10000 lcp-echo-interval 10 

As you can see, the only difference is the eap-timeout vs the eap-restart. The serial connection is, obviously, very slow, so in order to get ppp to maintain a connection I had to make it a little more error tolerant.

After that, I issued my first ping... I pinged the 69.1 address (server) from the 69.2 address (client), and much to my surprise, I actually got a response!

Now I couldn't do much more than that. I may need to recompile the kernel on my CHIP device to support PPP filtering, and I didn't have any firewall or iptables rules set up on the Vocore to allow any internet passthrough. To be honest I didn't think I'd get this far today.

I tried quite a few combinations of device speed and timeout duration as far as the serial emulator is concerned, but without a solid electrical connection for the devices to work with, there's no sense trying to fine-tune anything just yet.

I'm starting to see the light at the end of the tunnel though! Really all that's left to do is wire up the devices correctly, take it outside for some range testing, and see what kind of internet usage I can get out of it.

It's worth noting that the point to point protocol does have some error correction for dropped packets. It seemed at faster speeds with quicker timeouts the radios would be working harder, but could manage enough speed to allow ppp to pick itself up when the radios stumbled a larger portion of the time.

Discussions