Damn, today has been a hard fucking start up sequence ( slow starts punk brother ). TCP jokes are the best, if you don't get them we can keep retrying until you do.

This tweet by dwf

Possibly the most unbelievable thing about Star Trek is how different alien
civilizations maintain cross-compatible video calling software.

It's a funny joke. Current humans are still competing in the name of capitalism, there is little to no incentive to build interoperable system when you can control a market sector. Of course no one actually can, but that doesn't stop facetime not being available on android.

Rants aside; We are going to solve this set of problems with automation, machine learning and AI. Here is a great talk on transport layer improvements , it talks about machine learning approaches to optimise delay/bandwidth for live streaming video connections.

It is entirely feasible that we could run similar approaches to coordinate video communication, especially if we are a civilisation that spends all of its time exploring and finding new people to speak to. Automate the boring stuff, you know?

Reading: Little Brother, Transmet

The BBC have an excellent rendition of Burning Chrome by William Gibson. I am sure a neighbour will help you out if you are geographically impaired.

On Sunday I set up some quick and dirty temperature monitoring. At that point I didn't have any server code lying around to recieve the readings from the sensors. I set up tcpdump on a fileserver to capture the packets, tcpdump has the benefit of loggin a timestamp with each packet helping me get around limitations of the nodemcu hardware.

A day later I have to try and process the pcap files.

$ tcpdump -A -r temperaturevalues.pcap-1 | head -n 4
reading from file temperaturevalues.pcap-1, link-type EN10MB (Ethernet)
12:20:55.766057 IP 10.4.4.160.4097 > 10.4.4.187.acmsoda: UDP, length 134
E...........
...
......9....[{"humditiy": 47, "temp": 23, "pin": "Pin(4)", "sensor": "Pin(4)"}, {"humditiy": 45, "temp": 21, "pin": "Pin(5)", "sensor": "Pin(5)"}]

The -A flag for tcpdump will show me the packet payload as ascii, I was pushing json from the server so this is rather easy to see. I could use some shell magic to pull this out, but I wanted to play with scapy.

Scapy is a python library for dealing with packets, it does everything tcpdump will with packet injection to boot. Scapy will happily take in the pcap files.

#!/usr/bin/env python

from scapy.all import rdpcap
import json

if __name__ == "__main__":
    pcapfiles = [ "temperaturevalues.pcap-1", "temperaturevalues.pcap-2"]

    readings = []

    for files in pcapfiles:
        pkts = rdpcap(files)

        for p in pkts:
            time = p.time
            readings = json.loads(p.load)
            print("%s,%s,%s,%s,%s" % 
                (time, 
                readings[0]["sensor"],readings[0]["temp"],readings[0]["humidity"],
                readings[1]["sensor"],readings[1]["temp"],readings[1]["humidity"],
                )
            )

Running

$ python process.py  > readings.csv

Gives me a csv file with the temperature and humidity data from the sensors. Feeding this to gnuplot with something like the below results in a nice(albeit noisy) plot of the temperature from the two sensors.

set datafile sep ','
set timefmt "%s"
set format x "%m/%d/%Y %H:%M:%S"
set xdata time

set terminal png size 3000,500
set output 'data.png'

plot 'temperaturedata.csv' using 1:3 with lines, 'temperaturedata.csv' using 1:6 with lines

It said

Are you awake? Read a blog!

And I was awake, so I opened the blog. It was about baseball.

Instead I read an actual blog post , another one about the RSGB convention. Then I looked at this bytebeat album . Fuck baseball.

Reading: Litte Brother, Transmetropolitan

Fresh of great weekend at the RSGBConvention my good friend hibby was talking about doing point to point line of sight lines with 400MHz and up. He is super eager to do giant 50Km links and was suggesting hills to climb at the weekend.

I thought maybe we could try something a little easier to debug when it doesn't work. We settled to try point to point between my house and something the other side of the valley.

We did some local test and I was able to hear clear audio out to about 500m. At that distance we ran out of road to walk down. I can see the Newhills Parish Church from a rear window of my house, it is probably a little under a mile away line of sight.

While Hibby headed out there and I set up the yagi, we used 70cm as a return channel as the portapack can't transmit with the current firmware.

We ended up using the rad1o badge from cccamp last year as a 2.4GHz transmitter and a wifi yagi I had lying around. We played with settings for a while and eventually figured out the right combination of settings to do WFM voice!

Next we need to find a pair of points with los that are far enough apart to test range.

I ordered a handful of the cheapest nodemcu boards I could find from ebay. A couple of weeks later I got a nodemcu 'like' board from a company callsed AI-THINKER . The boards following instructions written on the back of them:

1. Install CH340G driver.
2. Use 9600bps baud rate.
3. Connect to WiFi.

I tried playing with two of the boards, powering them up and searching for wifi networks showed a network with a name like:

AI-THINKER_238810
AI-THINKER_23A9BF

Connecting to the wifi was fine, but I didn't really know what they expected me to do. nmap'ing the device has no results and an hour googling didn't really show up anything. Connecting over serial resulted in some noise then nothing.

I was going to flash micropython anyway, so lets do that.

Flash micropython

Connecting to the nodemcu board over serial spits out some gibberish no matter the baud rate I pick.

$ sudo cu -l /dev/ttyU1 -s 76800
Connected
Sd3²ì{£P:ýCê
ets Jan  8 2013,rst cause:2, boot mode:(3,6)

load 0x40100000, len 1856, room 16 
tail 0
chksum 0x63
load 0x3ffe8000, len 776, room 8 
tail 0
chksum 0x02
load 0x3ffe8310, len 552, room 8 
tail 0
chksum 0x79
csum 0x79

2nd boot version : 1.5
  SPI Speed      : 40MHz
  SPI Mode       : DIO
  SPI Flash Size & Map: 8Mbit(512KB+512KB)
jump to run user1 @ 1000

êñ+Pr-r+§(r

SD«¢hJëÙ-$xùÊkPx\)§k ¢ÀjtNü

Some time with a scope reveals the board is starting up at one rate then switching to another. The rate switch means the esptool is unable to do automatic baud rate detection.

With that we can flash the boards:

erase the flash
esptool.py --port /dev/tty.wchusbserial1420 erase_flash

flash the image
esptool.py --port /dev/tty.wchusbserial1420 --baud 76800 write_flash --flash_size=8m 0 esp8266-2016-05-03-v1.8.bin

reset the board

cu -l /dev/tty.wchusbserial1420 -s 115200
MicroPython v1.8.2 on 2016-08-05; ESP Module with ESP8266
Type "help()" for more information.
>>>