While trying to create log files for non-frequent network/firmware problems for the TTN Gateway, I ended up with my laptop connected to the gateway 24/7 since February 14th. So, I was kind of happy it finally failed and needed a reboot last Friday. 
Rather than hooking up my laptop again, I’m now using a Raspberry Pi 3 to do the monitoring, prefix proper timestamps to the output, and as a bonus send notifications to a (private) Slack workspace and/or Telegram chat to know when to act.
The full thing (using Node.js) with instructions is on GitHub, but the main points regarding the UART:
-
One needs to connect the gateway’s
RXto the Pi’sRXD. Earlier, with an FTDI cable I also noticed that an ESP8266 uses different labeling, so yes, I guess theTXandRXpins on the gateway are labeled wrong. -
Raspberry Pis that use Bluetooth will have their preferred UART hooked up to that Bluetooth. You might want to disable Bluetooth which will automatically make that best UART be mapped to the Pi’s
RXDandTXDpins; see the README. -
An UART is not line-based but will receive series of bytes from which, for the TTN Gateway, one can assume that each message ends with a newline. So, to get a message, the JavaScript needs to await such newline(s):
const raspi = require('raspi'); const Serial = require('raspi-serial').Serial; let buffer = ''; function log(data) { // To debug the raw stream, use: process.stdout.write(data); buffer += data.toString(); if (buffer.indexOf('\n') > -1) { const lines = buffer.split('\n'); // Log whatever complete lines from the buffer, up to the last newline for (let i = 0; i < lines.length - 1; i++) { console.log(`[${ (new Date()).toISOString() }] ${ lines[i] }`); } // The message following the last newline might not be complete yet; // handle later buffer = lines[lines.length - 1]; } }; raspi.init(() => { const serial = new Serial(); serial.open(() => { serial.on('data', data => log(data)); }); });
And yes, it’s a bit weird to (semi-)permanently connect a Pi to the TTN Gateway… But this also allows me to remotely access the logs, which are stored on the Pi. And I could even grant the TTN crew access if they want to experiment; I just need a relay then to remotely power cycle the gateway whenever needed. One could also easily parse the incoming messages to, say, create statistics. And when building one’s own firmware one could also log more details about the packets that are not yours, and then get even more details using https://github.com/anthonykirby/lora-packet
