Topics in this list: Best practices, RxJS Operators, Interview Questions, PWA, Promises with RxJS, TypeScript Wizard, Angular and React, Refactoring
“Watch” Angular Monthly Top 10 on Github and get email once a month.
As an article ranking service for professionals, we take quality very seriously and make sure each article you read is great. Mybridge AI considers the total number of shares, minutes read, and uses our machine learning algorithm to rank articles. This is a competitive list and you’ll find the experience and techniques shared by the Angular leaders useful.
Topics in this list: Mirror Works, ARKit 2, Messaging App, Notifications, Images Size, Enigma Machine, Marzipan, Designing Augmented, Application Security, Text Kit
“Watch” Swift Monthly Top 10 on Github and get email once a month.
As an article ranking service for professionals, we take quality very seriously and make sure each article you read is great. Mybridge AI considers the total number of shares, minutes read, and uses our machine learning algorithm to rank articles. This is a competitive list and you’ll find the experience and techniques shared by the Swift leaders useful.
For the past month, we ranked nearly 200 Swift Open Source Projects to pick the Top 10.
We compared projects with new or major release during this period. Mybridge AI ranks projects based on a variety of factors to measure its quality for professionals.
Average number of Github stars in this edition: 535
“Watch” Swift Top 10 Open Source on Github and get email once a month.
Topics: Time diffs, Syntax Highlighter, Head Tracking, NSFW, iOS Depth, Learn Swift, Universal Links, Stateful, UIStackView, SwiftPM package
Open source projects can be useful for programmers. Hope you find an interesting project that inspires you.
ScrollingStackViewController: A view controller that uses root views of child view controllers as views in a UIStackView. [493 stars on Github]. Courtesy of JUST EAT
Many of us have experienced the pain that is a Raspberry Pi with a corrupted SD card. I suspect the erase-on-write nature of flash memory is responsible for much of the problem. Regardless of the cause, one solution is to use PXE booting with the Raspberry Pi 3. That’s a fancy way to say we’ll be booting the Raspberry Pi over the network, instead of from an SD card.
What does this have to do with Hacking My House? As I discussed last time, I’m using Raspberry Pi as Infrastructure by building them into the walls of every room in my house. You don’t want to drag out a ladder and screwdriver to swap out a misbehaving SD card, so booting over the network is a really good solution. I know I promised we’d discuss cabling and cameras. Think of this as a parenthetical article — we’ll talk about Ethernet and ZoneMinder next time.
So let’s dive in and see what the Preboot Execution Environment (PXE) is all about and how to use PXE with Raspberry Pi.
GETTING FAMILIAR WITH RASPBERRY PI’S PXE BOOT FEATURE
New Raspberry Pis ship with PXE boot enabled, allowing the Pi to load its file system from a server on the same network. My experience is that the Pi 3 model B+ boots more reliably than the older version. Either way, it’s a good idea to begin by running rpi-update. Additionally, you may need to manually enable PXE by booting once off an SD card with an option added to config.txt. The official write-up is a great guide, and one of the resources I used when I stumbled through the PXE process for the first time. However, I will be doing things just a bit differently.
Take a moment to consider your network layout. Will your Raspberry Pi connect to your existing network, or to a new, dedicated network? To use your primary network, your router must support custom DHCP options. An OpenWrt router or similar device has this capability, but a stock D-Link or Linksys probably does not.
You will need a server on your home network to provide the file systems for the PXE Pis. There are multiple approaches, and I’ll be using CentOS 7. The hardware for this could be an old desktop, a virtual machine, or even another Raspberry Pi. We’ll assume a server with two interfaces — one connected to your primary network, and the second, with a static IP of 192.168.2.1, dedicated to the Raspberry Pi network. (If you plan to use a single network, skip the dnsmasq steps below, and use your server’s existing IP address instead of 192.168.2.1.)
HOUSEKEEPING AND PREPARATION
The code block below takes care of the initial dependencies and firewall settings, and enables the needed services. On the server, we need three primary services: Dnsmasq for DHCP, nfs-utils for NFS, and tftp-server for TFTP. Xinetd is a helper service for tftp-server, and we need unzip and wget for downloading and extracting the Raspbian disk image.
Install your favorite text editor (I’m using nano), and the policycoreutils package in order to work with SELinux. Then, allow the services through the firewall and set them to run automatically on boot. Lastly in this block of instructions, we’re setting SELinux to a more relaxed stance concerning the TFTP service.
Booting with PXE starts with DHCP option 66 (not order 66, that’s something different), which points to the TFTP server. We’ll configure dnsmasq to add that option, as well as the listen interface and the IP address range. Change these values as is appropriate in your case, and add to /etc/dnsmasq.conf.
1
2
3
interface=ens9
dhcp-range=192.168.2.50,192.168.2.150,12h
dhcp-option=66,192.168.2.1
The configuration for NFS is simple. We specify what directory we want exported by editing /etc/exports.
Xinetd stands for “eXtended InterNET Daemon.” This one service controls several other services, including TFTP. We’ll configure xinetd’s config file at /etc/xinetd.d/tftp looking for the lines “server_args” and “disable”. We’re adding the two “-v” flags to increase the verbosity, as we will need to see what files the Raspberry Pi is looking for as it boots.
1
2
server_args = -v -v -s /tftpboot
disable = no
BUILDING THE PI’S BOOT IMAGE
Kpartx is an invaluable tool to keep in your Linux-fu toolbox. We’ll use it to mount the partitions contained in this disk image, and then copy the file system to the new PXE root. The Pi looks first for bootcode.bin, so we also copy that file into place.
sudokpartx -a -v2018-06-27-raspbian-stretch-lite.img
sudomount/dev/mapper/loop0p2~/rootmnt/
sudomount/dev/mapper/loop0p1~/bootmnt/
sudocp-a ~/rootmnt/* /nfs/raspi1
sudocp-a ~/bootmnt/* /nfs/raspi1/boot/
sudocp-a /nfs/raspi1/boot/bootcode.bin /tftpboot/
We can also customize the filesystem for the Pi. First, to enable ssh access.
sudotouch/nfs/raspi1/boot/ssh
Next, we’ll modify the kernel boot line, at /nfs/raspi1/boot/cmdline.txt. Here we’re informing the kernel that it shouldn’t look for filesystem on a local disk, but to mount an NFS share as its root.
And finally, we remove a couple lines from the Pi’s fstab, so it doesn’t try to mount filesystems from the non-existent SD card. Edit /nfs/raspi1/etc/fstab and remove the last two lines, that mount / and /boot.
NETWORK SLEUTHING AND BIND MOUNTS
At this point, we’re ready to see if our hard work has paid off. Reboot the server so the pending changes are applied. (Yes, it’s fairly easy to apply them by hand, without the reboot, but this step also tests that everything comes back up correctly on power loss.) Once it’s back, watch the system log while powering the Pi connected to the new network. (Al Williams just ran an article on the versatility of the tail command that’s worth a look.)
Sep 24 11:05:15 PXE in.tftpd[4826]: RRQ from 192.168.2.103 filename bootsig.bin
Sep 24 11:05:15 PXE in.tftpd[4826]: Client 192.168.2.103 File not found bootsig.bin
Sep 24 11:05:15 PXE in.tftpd[4826]: sending NAK (1, File not found) to 192.168.2.103
Sep 24 11:05:15 PXE in.tftpd[4827]: RRQ from 192.168.2.103 filename 57b3548e/start.elf
The date will differ, as will the “PXE”– the hostname of this server. You’re looking for the RRQ from an IP address. If that shows up, then everything is going great. If not, time for some troubleshooting.
You may notice that your Pi is not actually booting. That’s because we’re not quite done. Look back at the TFTP log lines, because we need the folder name your Pi is looking for, which happens to be its serial number. Create that folder inside the tftpboot folder. Replace 57b354e with the folder name from your log.
sudomkdir/tftpboot/57b3548e
We need to talk about bind mounts, and why we’re not just copying files into this folder. Raspbian has a built-in procedure to update the kernel, through apt-get. PXE transfers the kernel stored in the TFTP folder, while the rest of the system is mounted as an NFS share. This arrangement prevents the Pi from updating its own kernel. There are a couple ways to fix this, but today we’re using the bind mount. Think of it as a hard link for directories. We’ll add a line to the server’s /etc/fstab, once again using the Pi’s serial number as the folder name.
And then use the mount command to make the bind mount live.
sudomount/tftpboot/57b3548e
Now, power cycle the Pi, and it should come to life!
THE POWER OF PXE AND PI
The number one problem with Raspberry Pi systems is SD card problems. Booting over the network will get around this weakness (assuming your network and your server are both stable systems). For my purposes this is a perfect choice, since I plan to use a Raspberry Pi in a three-gang electrical box, connected via Ethernet and using Power Over Ethernet. That said, any application where you will have an Ethernet connection, and need your Raspberry Pi to be reliable over the long term, is a good candidate for PXE.
Where do we go from here? Next time we’ll set up Zoneminder, and finally put these Pis to use. Let us know what else you want to see, or what we missed this time. Until then, happy hacking!
A couple months ago, Andrés Calleja EB4FJV installed a 2.3GHz beacon in his home in Colmenar Viejo, Madrid. The beacon has 2W of power, radiates with an omnidirectional antenna in the vertical polarization, and transmits a tone and CW identification at the frequency 2320.865MHz.
Since Colmenar Viejo is only 10km away from Tres Cantos, where I live, I can receive the beacon with a very strong signal from home. The Madrid-Barajas airport is also quite near (15km to the threshold of runway 18R) and several departure and approach aircraft routes pass nearby, particularly those flying over the Colmenar VOR. Therefore, it is quite easy to see reflections off aircraft when listening to the beacon.
On July 8 I did a recording of the beacon from 10:04 to 11:03 UTC from the countryside just outside Tres Cantos. In this post I will examine the aircraft reflections seen in the recording and match them with ADS-Baircraft position and velocity data obtained from adsbexchange.com. This will show the locations and trajectories which produce reflections strong enough to be detected.
EXPERIMENT SETUP
The receiver for this experiment is formed by a LimeSDR connected to a StellaDoradus 9dBi planar 2.4GHz wifi antenna. I chose this antenna rather than a more directive grid parabola because it has a very small form factor and its wide radiation pattern may allow us to receive reflections from unusual directions. The antenna is connected to the LNAH input. The whole receiver setup is mounted on a camera tripod.
The setup can be seen in the picture below, taken at home during testing. The signal in this position is quite strong even though there is not line of sight to the beacon. There are trees just in front of my window and then there are some higher buildings obstructing the direct path.
Testing of the receiver setup
In my usual portable location in the countryside just outside of Tres Cantos I have line of sight to the beacon. The received signal is extremely strong. In the figure below, reciprocal mixing from the local oscillator of the LimeSDR can be seen. Thus with this setup the limiting factor for receiving weak reflections is the dynamic range of the LimeSDR.
2.3GHz beacon in GQRX showing reciprocal mixing with the LO of the LimeSDR
After experimenting for some time in this location with different directions and positions for the receiver, I decided to place the antenna aiming directly towards Barajas, using my car as a makeshift shield for the direct path from the beacon. This is good because I aim the antenna away from the beacon and my car also reduces the direct signal a little. This can be seen in the two pictures below. Note the airplane in the first picture. It is taking off from runway 36L in Barajas and producing a reflection which can be detected in the receiver (click on the image to view it in full size).
View from the antenna towards Barajas (note the airplane on departure)Receiving station. The car is used as a shield from the direct beacon signal.
My location was the grid locator IN80do68pw (or 40.62045ºN, 3.69466640ºW). The antenna azimuth was set to 120º. At 10:40 UTC I changed the azimuth to 80º, though this did not produce any noticeable difference in the reflections observed.
RECORDING RESULTS
The recording was made in GQRX by recording the audio output in SSB mode with a wide filter. The recording can be downloaded here(738MB). The WAV recording was processed with the script waterfall_13cm.py to produce waterfall data that was saved to an npzfile. The resolution of the waterfall data is 11.7Hz or 0.43s per pixel.
The waterfall can be seen below. It is divided in chunks of 10 minutes for easier visibility. Several aircraft scatter traces are visible, especially with positive Dopplers. Near the end of the last chunk there is something curious: a strong reflection that was produced by a car driving over a nearby dirt road (from several 10s of metres to a hundred metres away). I find it surprising that the reflection is so strong. This opens up the possibility for other experiments. Maybe passive radar traffic monitoring.
ADS-B DATA
The ADS-B data I have used has been downloaded from the historical data archive of adsbexchange.com. I have made the recommended donation of 0.15 USD per GB to help to cover bandwidth costs. The data is downloaded as a zip file per day. Each of these zip files contains a JSON file per minute with the ADS-B data. The format of the JSON data can be seen here.
The JSON data is loaded in Python using the json library. Unfortunately the JSON data has a few occasional quirks (such as extra commas in lists), so there is some string processing that needs to be done before the json library can accept all files as valid JSON.
Since loading the JSON files is quite slow, once the data is loaded and filtred by geographic location, it is save to a pickled file to load it faster in future executions.
The figure below shows the tracks of all airplanes passing through the zone of the recording between 10:00 and 12:00 UTC. The tracks are coloured by Doppler, with red representing positive Doppler and blue representing negative Doppler. Most of the aircraft that appear in the map are taking off from Barajas’ runways 36L and 36R, since Barajas was in its usual north configuration (takeoff runways 36L and 36R, landing runways 32L and 32R).
The location of the beacon is shown with an orange circle, while the location of my receiver is shown with a red circle.
Airplane tracks. Colour indicates Doppler (red is positive, blue is negative).
The Doppler traces for each aircraft can now be superimposed on the waterfall to match the reflections with each aircraft. This is done in the figures below. Each Doppler trace shows the aircraft callsign and ICAO hex id. I have selected by hand all the aircraft that produced a reflection of the 2.3GHz beacon and marked their trace in orange. The trace of aircraft which do not produce an observable reflection is marked in white.
Since we have now selected by hand which aircraft have produced a reflection and which haven’t, we can plot again the map of aircraft, marking in red the aircraft which produced a reflection and in blue those who didn’t. This is done in the figure below.
Map of aircraft producing reflections (in red) versus those not producing reflections (in blue)
We see that how likely is an aircraft to produce a reflection obviously depends a lot on the route that the aircraft has taken. This leads us to study the aircraft routes more in detail.
DEPARTURES FROM BARAJAS
Most of the aircraft that appear in the map are departing from runways 36L and 36R from the LEMD (Madrid-Barajas) airport. The route that these aircraft fly is called a Standard Instrument Departure, or SID. The information about the SIDs for a certain airport can be obtained in the relevant AIP (Aeronautical Information Publication). The AIP for Spanish airports can be found online at ENAIRE.
Daytime SIDs for runway 36L are shown in the figure below. They are identified the name of the final fix, a number with the revision of the SID, and a letter indicating the initial route. Currently, they are BARDI2K, BARDI2T, CCS1K, CCS1T, NANDO2N, PINAR2N, RBO1N, SIE1K, SIE1T, VTB1K, VTB1T, ZMR1K and ZMR1T.
SID for LEMD runway 36L (day)
The figure below shows in more detail the initial routes. Aircraft departing on K climb runway heading direct to SSY VOR, then via SSY R-001 to SSY DME 2.7, then turn right to 026º to intercept and follow BRA R-001. Aircraft departing on T climb runway heading direct to SSY VOR, then turn left to 291º to intercept and follow SSY R-321 to SSY DME 5.7 (or 6.8 for VTB1T). Then they turn either left or right depending on the route. Aircraft departing on N climb runway heading direct to SSY VOR, then via SSY R-017 to SSY DME 5.6, then turn right to intercept BRA R-005 to BRA DME 12.
SID for LEMD runway 36L (day)
Daytime SIDs for runway 36R are shown in the figure below. Currently they are BARDI5W, CCS4W, NANDO1D, PINAR1D, RBO1D, SIE2W, VTB1D, ZMR2W.
SID for LEMD runway 36R (day)
The figure below shows the details of the initial routes. Aircraft departing on W climb runway heading to BRA DME 5, then via BRA R-001 to BRA DME 7, then right to intercept and follow SSY R-017. Aircraft departing on D climb heading 016º to BRA DME 5.8 to intercept and follow RBO R-222.
SID for LEMD runway 36R (day)
The next step in our study is to classify the aircraft according to the SID they are flying. The algorithm used is very simple but effective. For each SID we choose a waypoint and assign to that SID all the aircraft that pass within a certain distance of that waypoint. The algorithm for calculating the distance between the aircraft track and waypoint is also simplistic: only positions in the JSON data are considered, rather then interpolating between them. Even though the algorithm is simple, it is able to classify all the aircraft without any mistakes.
The results of the classification are shown below. Each SID is shown in a different colour. Aircraft not flying any SID are shown in black. These are aircraft in cruise flight, most of them flying along the high level routes UN865 and UN870. We are not concerned with them, since none of them have produced any visible reflections. We observe that, from all possible SIDs, only K, T and D are in use. It makes sense not to use N and W in order to keep the traffic for each runway well separated: aircraft departing runway 36L use heading 321º or runway heading, while aircraft departing runway 36R use heading 016º.
Aircraft tracks classified according to SID (T in red, K in green, D in blue).
REFLECTIONS PER SID
Now that we have a classification for the SID flowm by each aircraft, we can compute the fraction of the aircraft on each SID that produce a reflection. It turns out that 89% of the aircraft flying T produce a reflection, while 75% of the aircraft flying K produce a reflection. No aircraft flying D produce a reflection. This makes sense, since T takes the aircraft very near the receiver and beacon (indeed I could see the aircraft passing near my receiver), while D takes them away from the receiver and beacon.
Now we study which parts of the routes T and K produce the reflections that we see on the waterfall. Below we show the waterfall drawing only with the Doppler traces for those aircraft on a route T. We note two things. First, all the aircraft except the first two, which had already flown away when the recording started, produce a detectable reflection. Second, the shape of the reflection is as follows: it starts quite flat around 1300Hz, lasts for a minute, then crosses fairly quickly towards 0Hz, increasing in strength and disappears just after passing 0Hz.
This means that the reflection can be detected starting shortly after the airplane takes off from runway 36L. The reflection is visible while the aircraft climbs on SSY R-321. In this part of the route the reflection is backscatter: the receiver is almost inside the line segment joining the 2.3GHz beacon and the aircraft. The receiver’s antenna is pointing directly towards the aircraft. After crossing 0Hz, the airplane turns and flies away from the receiver. It is now on the back of the beam of the receiver, so the reflection disappears quickly.
The waterfalls below show the Doppler traces of aircraft climbing on K. We see that the reflections are only visible for a brief period of time, when the Doppler crosses through 0Hz. This happens when the aircraft has passed SSY DME 2.7 and turns right to heading 026º. In this situation the aircraft is centred on the receiver’s antenna beam, in a good backscatter position, and in the point of its track that is nearest to the receiver.
CLOSING REMARKS
In this post we have seen that it is not difficult to receive aircraft scatter in the microwave bands, given an appropriate transmitter and air traffic. This is well known by the Amateur radio community, where people routinely observe aircraft scatter in the VHF, UHF and microwave bands, and even use it for communication. There is a lot of material reporting different situations of aircraft scatter. However, I had never seen a study where the aircraft scatter Doppler traces are matched against aircraft position and velocity data in such a detailed way as it is done in this post.
In these days, ADS-B is a very accessible way of obtaining aircraft position and velocity data. There are several online sources such as adsbexchange.com where it can be streamed in real-time or downloaded for later analysis. Alternatively, it is also possible to receive the ADS-B transmissions at 1090Mhz directly at the aircraft scatter receiver’s location.
The figures shown in this plot have been made in this Jupyter notebook. I have included the supporting data (npz waterfall file and pickled ADS-B JSON data) in the github repository so that interested people can run the notebook again. Hopefully this notebook may serve as the starting point for someone doing its own experiments that require processing and plotting ADS-B data.
In an attempt to get the Amateur radio community interested in topics such as air traffic and air traffic control, I have included an in-depth discussion about the SIDs used at Madrid-Barajas. Of course there are many more air traffic topics relevant to radio than what has appeared here. The reader may want to read and experiment about some of the following: VOR, DME, TACAN, NDB, ILS, primary and secondary radar, ADS-B, mode C transponders, ACARS, VDL, HFDL, Inmarsat AERO, oceanic routes and communications, HF SELCAL, VHF and UHF ATC, METAR and VOLMET, and several more.
Then multiply this by the desired range (largest value – smallest value + 0.999999).
Then add the offset (+ smallest value).
Then truncate to an integer.
Something like this in your device code:
int idx = threadIdx.x+blockDim.x*blockIdx.x;// assume have already set up curand and generated state for each thread...// assume ranges vary by thread indexfloat myrandf = curand_uniform(&(my_curandstate[idx]));
myrandf *=(max_rand_int[idx]- min_rand_int[idx]+0.999999);
myrandf += min_rand_int[idx];int myrand =(int)truncf(myrandf);
For the past month, we ranked nearly 250 Node.js Open Source Projects to pick the Top 10.
We compared projects with new or major release during this period. Mybridge AI ranks projects based on a variety of factors to measure its quality for professionals.
Average number of Github stars in this edition: 1,817
“Watch” Node.js Top 10 Open Source on Github and get email once a month.
Twitch-Dog-Treat-Dispenser: ”LarryBot” is an automated dog treat dispenser that let’s live viewers on Twitch.tv give treats to a good boy on command. [9 stars on Github]. Courtesy of Tyler Pearce
That’s it for Node.js Monthly Open Source. Visit our publication to find top posts for more programming skills.
For the past month, we ranked nearly 250 JavaScript Open Source Projects to pick the Top 10.
We compared projects with new or major release during this period. Mybridge AI ranks projects based on a variety of factors to measure its quality for professionals.
Average number of Github stars in this edition: 1,079
“Watch” JavaScript Top 10 Open Source on Githuband get email once a month.
Topics: Webpack, Data Grids, Visualizer, Audio, Compiler, Vanilla Javascript, d3-dag, Web Scraping, Debugger, Visual Programming
Open source projects can be useful for programmers. Hope you find an interesting project that inspires you.
Javascriptvisualizer: A tool for visualizing Execution Context, Hoisting, Closures, and Scopes in JavaScript. [180 stars on Github]. Courtesy of Tyler McGinnis
Apify-js: The scalable web crawling and scraping library for JavaScript. Enables development of data extraction and web automation jobs (not only) with headless Chrome and Puppeteer. [1312 stars on Github]. Courtesy of Apify
For the past month, we ranked nearly 200 Swift Open Source Projects to pick the Top 10.
We compared projects with new or major release during this period. Mybridge AI ranks projects based on a variety of factors to measure its quality for professionals.
Average number of Github stars in this edition: 459
“Watch” Swift Top 10 Open Source on Github and get email once a month.
Topics: Testable data source, Server Framework, panel UI, Auto Layout, Swift Syntax, Sliding Menu, Voice, Server Side Swift, Volume Popup, Xcode
Open source projects can be useful for programmers. Hope you find an interesting project that inspires you.
AloeStackView: A simple class for laying out a collection of views with a convenient API, while leveraging the power of Auto Layout. [429 stars on Github]. Courtesy of AirbnbEng
SwiftSyntaxHighlighter: A syntax highlighter for Swift code that uses SwiftSyntax to generate Pygments-compatible HTML. [152 stars on Github]. Courtesy of NSHipster
中尺度数值模式得到全球的大力发展应用，其中最著名的是美国大气研究中心 NCAR、国家环境预报中心 NCEP 等多单位联合建立发展的 WRF（Weather Research and Forecasting Model），其次则是美国国家环境预报中心 ( National Centers for Environmental Prediction，NCEP) 用于业务预报的 ETA( η) 模式。
其他由美国主导的中尺度数值模式尚有：
美国宾夕法尼亚大学和美国国家大气研究中心 (PSU/ NCAR) 合作研制的 MM5( Mesoscale Model 5) 模式；
Lightning Network is trying to solve a few of the current problems that the Bitcoin is suffering: scalability (number of transactions per second, right now Bitcoin handles about seven transactions per second), speed (time required to confirm a transaction,), cost (fee to pay for each transaction).
Curiously enough, it turns out that transaction speed and cost are some of the same problems that Bitcoin is solving, but “how long a minute is depends on which side of the bathroom door you’re on”.
How it works?
The basic idea is to create a “channel” between 2 participants (let’s s Alice and Bob) and place some funds in, for example 1 BTC each. This requires a transaction on the Bitcoin blockchain, that locks the funds in a 2 multisig address. Here is the situation of the open channel:
Alice <= 1 BTC == 1 BTC => Bob # opening of a new channel
Alice and Bob can now make as many transactions as they want “off-chain”, they just need to exchange an updated “balance-sheet”: that is transaction signed by the other party (so it’s missing one of the signatures) that is not propagated to the bitcoin mainnet (yet), and that pays the updated funds to the participants.
Because the transaction are stored “off-chain”, Alice and Bob don’t need to wait for a confirmation from the main blockchain (instant transaction) nor to pay a fee to the mainnet miners (low fees).
Here is the situation of the open channel while the transactions are happening:
Alice <= 0.8 BTC == 1.2 BTC => Bob # Bob sent 0.2 BTC to Alice
Alice <= 0.9 BTC == 1.1 BTC => Bob # Alice sent 0.1 BTC to Bob
Alice <= 0.4 BTC == 1.6 BTC => Bob # Alice sent 0.5 BTC to Bob
…
…
At any moment, a participant can make the balance-sheet “real”, signing the latest multisig transaction received from (and signed by) the other party, and broadcasting it a as regular Bitcoin transaction: the channel is now closed.
But the real power of the Lightning Network is the “six degrees of separation” idea: a participant can reach any other in just a few hops, if the “routing” is know. So if Alice has an open channel with Bob, and Bob has an open channel with Charlie, Alice can make a transaction with Charlie, and send for example 0.5 BTC to him. Here is the situation of the channels before transaction:
Alice <= 1 BTC == 1 BTC => Bob # Bob has 3 BTC on 2 channels
Bob <= 2 BTC == 2 BTC => Charlie
and after the transaction:
Alice <= 0.5 BTC == 1.5 BTC => Bob # Bob is still having 3 BTC
Bob <= 1.5 BTC == 2.5 BTC => Charlie
The total balance of Bob remains unchanged, while the balance of Charlie increase of 0.5 BTC and the balance of Alice decreased of 0.5 BTC.
Choosing the Lightning Network implementation to use
I spent some time reading the features implemented by the each project, and then decide to install LND because:
Both projects require a full bitcoind backend daemon running on the same host (or an host reachable by net), but LND supports also a bitcoind node in prune mode: this means that you don’t need to store the full bitcoin blockchain locally (more than 200 GB at the moment), so the disk space requirements are less and I my spare 128 GB USB pen drive is more than enough.
LND has an experimental support for the neutrino backend (only testnet at the moment), a Bitcoin light client, that further reduce the disk space requirements: I bet that soon or later it will reach a production ready quality, and that I could switch to it.
LND has an automatic channel management (autopilot), that creates and manage channels.
LND has “nat” feature: this allow to advertise the node to the network as long as it’s behind a single NAT, automatically handling the change of the public IP address, so that less scripting tricks are required on the node.
Let’s the fun begin: Preparing the Lightning Network node
Before the installation, I read and digested a few good guides, that I have to give credits:
I had a Raspberry Pi 3 Model B+ mostly unused at home, a spare 128GB USB pen drive and a good network connectivity, so I tried to reuse those components. Please mind that you need to run your node 24/7, so a noiseless host is preferable. I installed some heat sinks on the Pi to avoid to have a fan running all the time while keeping the CPU temperature in a safe range. During the full installation process and further daily running operations, the temperature of the CPU never exceeded 65°C, safely below the max temperature of 85°C: anything above this and the Pi will throttle the CPU frequency to bring the temperature back down.
Remember to add an empty file ssh in the root of the MicroSD: this is required to activate the ssh remote connectivity, otherwise you can’t login into the Pi from the network and configure it.
Then using the nmap map tool I found the ip address given by my home router to the Pi
> $ nmap -sP 192.168.1.0/24
and started an ssh session using the default user pi and password raspberry.
> $ ssh pi@192.168.1.134
To complete the configuration of the Pi, I run the raspi-config tool from the command line, tweaking the parameters to configure the WiFi SSID and pre-shared key, the locale, the timezone, enabling the ssh connectivity. Because the node is running headless, I also decreased the amount of memory made available to the GPU, in Memory split.
Because this is node is connected to the internet and is managing “money”, is better to enter the “paranoia” mode.
In order, what I did:
Removed the default user pi and created a new user to use as the main user to connect to the Pi.
Configured the passwordless ssh, following this guide https://www.raspberrypi.org/documentation/remote-access/ssh/passwordless.md and then allowed only the login via SSH certificate, changing the settings ChallengeResponseAuthentication and PasswordAuthentication to no in the file /etc/ssh/sshd_config
Created a “service” user bitcoin to run the demons required to interact with the Lightning Network, running sudo adduser bitcoin
What I should also do:
Install fail2ban to automatically ban IP addresses that make too many password failures. My Pi is behind an home router that doesn’t forward ssh port, so this is not strictly required, but this can prevent attacks generated from other compromised device in my home network (smartphones, laptops, smart tv….)
Install a firewall
Utilities
Here some handy aliases that I added to ~/.bashrc to make life easier:
# handy aliases
alias ..=’cd ..’
alias …=’cd ../..’
alias ….=’cd ../../..’
alias …..=’cd ../../../..’
alias ……=’cd ../../../../..’
alias 1=’cd -’
alias _=sudo
alias afind=’ack -il’
alias d=’dirs -v | head -10'
alias l=’ls -lah’
alias la=’ls -lAh’
alias ll=’ls -lh’
alias md=’mkdir -p’
alias rd=rmdir
Remember to reaload the ~/.bashrc
source ~/.bashrc
Then I installed iftop, a useful utility to monitor the network traffic that run in a terminal
sudo apt install iftop
sudo iftop -i wlan0
PuTTY configuration
I use PuTTY to connect to the RaspberryPi. Here is how I changed the default configuration for the connection:
terminal → keyboard → The function keys and keypad → Linux
connection → seconds between keepalive → 30
Installing bitcoin core on Raspberry Pi
LND works with bitcoind as backend, so I first installed the latest bitcoin core software (https://bitcoincore.org). I quickly prepared a script, that I can reuse in my next projects, to download bitcoin core, verify the checksum and install the binaries:
# Raspberry Pi optimizations
dbcache=100
maxorphantx=10
maxmempool=50
maxconnections=40
maxuploadtarget=5000
Now the time consuming task, the Initial Block Download , the system need to download and verify all the blocks (from 2009) to catch up to the tip of the current best block chain.
I said before that lnd supports a bitcoin core backend in prune mode, this means that the old blocks are purged from the local disk, but they as still downloaded and validated: I started the process, but I quickly realized that full process would have taken more than 10 days… Someone suggests to use a separated device, with a more powerful CPU, to download and validate the blocks, and then copy the validated blocks on the Pi.
Spawning an Amazon EC2 instance to speedup the IBD
I don’t have a spare device fast enough to leave 24/7 crunching data, so I quickly spawn an m4.large instance on Amazon EC2 with an additional 50 GB EBS volume, visible as /dev/sdf . I used the amzn-ami-2018.03.a-amazon-ecs-optimized (ami-c91624b0), that natively supports docker, and then run bitcoind using a docker image. Here a quick recap:
Formatting and mount the additional EBS volume
sudo mkfs.ext4 /dev/sdf
sudo mkdir /mnt/bitcoin-data
sudo mount /dev/sdf /mnt/bitcoin-data/
Why? ok, Lightning Network is still is it’s infancy, but IMHO the root cause is the topology of the network itself: it’s not distributed at all.
Let me explain this better: according to https://1ml.com/ today we have 3,544 nodes, providing a network capacity of 112.16 BTC in 12,160 channels, but guess what: the top 20 nodes by BTC capacity, just the 0.56% of them, control 85% of the total BTC capacity and 33% of total channels.
the “not decentralized” distribution of lightning network capacity
So it’s easy to figure out that the actual topology is a based on few “super hubs” that route the big part of the payments, and get the fees.
Is this a bad thing®? I’ll expose my opinion in a upcoming story.
Feel free to connect my Lightning Network:
>$ lncli connect 039401f72bc0d40efb58b01de15527a2a5ae1943d7c29067b725a1467a93c7e66f@2.238.144.76:9735
New Raspberry Pis ship with PXE boot enabled, allowing the Pi to load its file system from a server on the same network. My experience is that the Pi 3 model B+ boots more reliably than the older version. Either way, it’s a good idea to begin by running rpi-update. Additionally, you may need to manually enable PXE by booting once off an SD card with an option added to config.txt. 
Lightning
