True 3 wire SPI on the ESP32 (detaching MISO from the pin matrix)

I screwed up.

On my latest board using an ESP32 I connected an LED to pin 19, but it would never light up.

I wasn’t using the pin for anything else, and sources online didn’t seem to indicate any problem with using it as a GPIO output. I was however using the VSPI port to connect to an ePaper display, but it was only physically connected in 3 wire mode.

When the display was initialised, I could no longer control the LED.

Fortunately I had read about a handy feature of the ESP32 known as the GPIO matrix. It allows the physical pins of the chip to be mapped (and importantly unmapped) from an internal signal.

Poking around inside esp32-hal-spi.c the signal name of “VSPIQ_OUT_IDX ” can be found.

A little further on an example of detatching a signal can be found here.

pinMatrixInDetach(signal, false, false);

Meaning all we need to run to detatch the MISO of VSPI is:

pinMatrixInDetach(VSPIQ_OUT_IDX, false, false);

And it works!

The EMF Roamer

While packing for EMFcamp 2018, I came across a small tracked robot chassis at the back of my cupboard. It was instantly obvious that this needed to be turned into a small internet controlled robot for the camp. It could be deployed and roam around the site, controlled by anyone!

Just allowing people to drive it line of sight wasn’t good enough! Especially not in the world of raspberry pi’s. The video from a raspi camera should be streamed to the user while they have control. A GPS module showing a roamer icon on the official EMF map was also a must-have at this point.

A free for all in terms of control would also be a mess, so we devised a queue system. People could join the queue in their web browser and wait their turn, or provide a mobile phone number to receive an SMS when their turn is up (thanks nexmo!). We also planned twitter integration, but didn’t get our account approved for developer use until after the event. Cheers twitter. The queue system was hosted by Hostgator ,but it ground to a painfully slow halt where pages took almost 60 seconds to use, forcing us to move the whole thing over to Servage. I think I will be ditching Hostgator soon after this experience.

The first step was to get a low latency video stream working. Youtube does offer a low latency mode, but I found that it still had a latency of 5-10 seconds. Nowhere near good enough for live control! Youtube streaming was however still a nice idea, as it would allow people to watch the stream as they wait in the queue. Step in MJPEG-Streamer. It can produce a stream with extremely low latency. Perfectly good enough for control. The only difficulty being that once the MJPEG streamer was using the raspi camera, it was then locked and could not be used by other programs.

Step in horrendous FFMPEG commands! After far too much poking around online, with lots of commands that didn’t work, or did something slightly different that broke when I tried to modify them, I found a winning combination. FFMPEG picks up the MJPEG stream, adds a fake audio source (required for youtube), and sends it out to the youtube ingest server over RTMP. This FFMPEG command sat inside a shell script that would monitor the log, and restart the process if no new frames were sent in a few seconds.

My initial plan for controlling the motors was to run an HTTP server on the pi, and control the GPIO pins depending on which directories were accessed. This was accomplished through a python/flask script. The motors themselves are controlled by a [chip] H bridge driver chip.

The GPS side of things was pretty trivial using this python port of TinyGPS. The data is sent to a webserver via GET where it is then stored in the MySQL database. The official EMF map was open source, but after a couple of days of trying, we were’t able to integrate a roamer icon on to the map nicely. Instead as a last minute bodge, I centred an icon on top of the map in straight up HTML, and repositioned the map to reflect the position.

In order to get the best possible WiFi coverage and quality, we purchased a high gain antenna/adaptor from Amazon, which was supposedly Pi compatible. This worked on my home WiFi, but actually felt more laggy than the el-cheapo Netgear adaptor we were initially using.

When we arrived at emfcamp, the fancy WiFi adaptor just flat out refused to connect to either their legacy or insecure 2.4GHz networks. I can only put this down to an incompatibility with WPA2 enterprise. This can apparently be fixed by recompiling some drivers, if you have the patience. We did not have the patience, so taped the Netgear adaptor to the high gain antenna on a USB extender. Coverage was a little patchy, and it was unreachable for several seconds when it roamed between AP’s.

This patchy WiFi performance was a massive problem to the controls. Sometimes the stop packet was lost in transit, and the motors would lock on moving in a direction. To try to mitigate this, I had programmed a 3 second dead mans switch, which would stop the motors if no new packers were received. Three seconds of driving in a random direction however was a pretty poor experience. I quickly replaced the HTTP control with websockets, and the results seemed much better. I was able to reduce the dead mans switch to one second, and it seemed to be needed less often.

All of these scrips were started using cron jobs to run @reboot.

Tiny tracks and long grass were a terrible idea. Initially you were able to turn on the spot by driving one motor forwards, and the other back. I ended up disabling this as it caused the tracks to ingest way too much grass, and was probably the main culprit to us shredding the first gearbox. It also fell over at almost any opportunity.

This however did not stop one keen driver from taking it for a lap around the Hacky Racers track, and officially scoring the worst time of the entire event.

Some stats:

  • GPS updates: 1632
  • Distance driven: 3.217918922 miles
  • Number of attempted users: 307
  • Number of users who drove: 253 (including us testing it)
  • Number of unique drivers: 116
  • Hours of video: 6:19:29
  • Number of talks crashed: 2 (stage A, first one here, second one not captured)
  • Number of times the tracks came off: >2
  • Number of times people tweeted it wasn’t working: 6
  • Time it took to load the homepage on our old shared webhost: 30-60 seconds
  • Official hacky racers lap time: 6:42 (slowest of the whole weekend)

 

Improvements:

  • Bigger chassis, bigger tracks, or just wheels.
  • Diversity WiFi antenna. Use a bridge to LAN?
  • Timestamp video (aligning patch YouTube DVR with GPS was a nightmare).
  • Make the map less broken.
  • Night vision camera.
  • Something to discourage people from standing in front.
  • Battery voltage monitoring.
  • RF gateway from wired server for remote control (LORA?)
  • Moar RGB
  • Some kind of game. Collect/chase things on the map?

I used Excel 3D Maps to produce the map animation from CSV GPS logs.

µTesla – One inch tesla coil

For the Hackaday square inch PCB contest, I decided to have a go at miniaturising the slayer exciter circuit often used on chip musical tesla coil kits often found on ebay and aliexpress.

It turned out to be fairly straightforward!

The details of the project can be found at the hackaday.io page.

TP-Link HS100 WiFi socket controller for Windows

I own a couple of TP-Link HS100 WiFi sockets.

When I’m using my PC, it’s a minor pain to have to unlock my phone, open the Kasa app, wait for it to finish displaying the infernal splashscreen, then turn on my socket.

What I wanted was a program sitting in the windows tray to control them. So that’s what I made. It’s in VB.NET. All you need to do is toggle a switch icon on your taskbar.

This is heavily based on the API research over at itnerd.space

Instructions:

  1. Log in to a cloud account in the Kasa app, and make sure at least one device is associated with your account. Give them names if it’s helpful.
  2. Download and install my program.
  3. Put in your Kasa account details and click the “update devices list button”
    The list should be populated with the details of each device you have connected. You can click each one and control it from this screen. Notifyicons will also be created in the system tray for each device.
  4. If you click the x (close) in the top right of the program, it will minimise to the tray.
    You can mouse over the tray icons to see their name, and click them to toggle the state. Right clicking any icon will open the menu again.
  5. I recommend you tick the “start in system tray” box and add a shortcut to the program in your startup folder.

Changelog:

1.0.0.4 – 15/05/2018 – Fix errors when a device in your account is offline.

2.0.0.0 – 23/06/2019 – New features: CLI mode. Copy ID to clipboard. Bug fixes: Better management of tray icons. Removed from alt-tab list when minimised to tray.

2.1.0.0 – 25/06/2019 – New features: Start with Windows. Create on/off timers for devices. Automatically turn devices on/off on program launch/exit.

Download installer TPLink-HS100-controller-2.1.0.0

Download source code from GitHub.

[GUIDE] Make windows taskbar always show an icon

[GUIDE] Command line interface

This program has no affiliation with itnerd.space or tp-link. I accept no liability for its use. This program is provided without warranty/guarantee.

SXHAM1 – CHEAPO18 flight for EssexHAM/TXFactor/RSGB – 31/05/15

I was approached by Pete M0PSX to do a HAB launch for a promotional video by the RSGB.
The launch took place from the EssexHAM field event at Shoebury East Beach on Sunday the 31st of May.
There were a few other radio amateurs present operating on HF and 2m, as well as a couple of guys flying drones.
Footage was captured by a group called TX Factor, who are doing a piece for the RSGB promoting youth and interesting new activities in amateur radio.

We launched a Cheapo Micro tracker under a 100g Pawan balloon, then tracked the flight from the event using a couple of RTL-SDR’s with a yagi and a 2m/70cms magmount.

Yagi

 

exham

 

sxhamlanding


Video and photos credit Pete M0PSX

Footage from TX Factor to follow.

ECC1 – Pi in the sky test flight 24/05/2015

On Sunday the 24th May 2015, I carried out a test flight of the Pi in the sky high altitude balloon tracker for our local council. There are currently over 10 schools constructing payloads around this tracker which should be launching in the next couple of months. A couple of my experimental trackers also hitched a ride on the flight to test out, as well as another backup tracker.

I was joined by Will to help with the launch, tracking and recovery. After a quick stop for breakfast and to check the predictions one last time, we met Steve up at the Elsworth launch site at Cambridge. Steve was also trialling out live streaming the launch over 4G, which turned out to be very successful.

Shortly after arriving, we powered up all of the payloads, ensured they had a GPS fix and were transmitting correctly, then joined them together with the 3ft rocketman parachute to form a train.

Balloon — 5m — Parachute —– 10m —– ECC1 — 5m — CHEAPO – 2m – CS4

We then began filling the Hwoyee 1200g balloon with about 3.6m³ of helium. The lift was checked by attaching a 2500g weight to the balloon and filling until it achieved neutral buoyancy. The balloon was then sealed off at the neck and joined to the train using cable ties and duct tape.

 

Image credit Steve Randall

Image credit Steve Randall

After Steve coordinated with local air traffic control and the rocketry club in the next field, it was time to launch. The wind was picking up a little bit, so the launch was a little more violent than usual. Will and I ran along with the payloads to match the speed of the wind, and then released them when the balloon was straight above us.

We then shot off in the chase car to wait in a car park in Royston until the burst. This ensured we had good 3G/4G signal to run predictions and fast access to the main roads once we had a predicted landing site.

Unfortunately shortly after launch ECC1’s signal dropped to a single carrier (as opposed to the normal alternating frequency of RTTY), this was a pretty solid indication that the tracker had crashed. We continued receiving updates from SPARK and CHEAPO for the duration of the ascent. When the balloon eventually burst at 32759m altitude, we waited for a few more updates of the descent from CHEAPO before heading out to the predicted landing site. SPARK once again however failed to report the burst or descent, and carried on “floating” at a roughly steady altitude.

Alt Graph

 

Once we arrived at our predicted landing site the flight had landed, and the signals from all 3 payloads were visible and audible, however too weak to decode. After 15 minutes or so of trying different antennas and tweaking decoder settings, we decided to head out further west in pursuit of a stronger signal. Around this point we saw a bunch of updates appear on the tracker from Steve, and headed to the new location.

Untitled3 - Copy

We were greeted by Steve and his cameraman, who had already had time to locate the payload and set up their live stream before we arrived. The payloads were sitting happily on the ground, with the parachute caught up a tree dangling most of the balloon remnants below it. After a couple of tugs the parachute joined all 3 payloads in their successful recovery.

 

Keen to investigate what happened to ECC1, we headed back to Essex to carry out some debugging. On recovery neither of the OK or WARN LED’s were lit on the board. The camera LED was however still flashing, and had stored images of the entire flight on its SD card. Voltage readings were normal. On closer inspection I found that the SDA wire for the BMP180 sensor had broken at the solder joint to the PITS PCB. After soldering this back on and simulating the breakage, the PITS tracker program once again crashed and dropped to a single carrier. I also found that the micro SD card was very lose in the low profile micro SD adapter I was using. It could easily be pulled out by dragging your finger across it (despite remaining in the “locked” position), More hot glue required.

I’ve reported these findings back to Dave Akerman and he is hoping to release a software patch by the end of the week. I think it would then be wise to carry out a small repeat test flight (perhaps on a 100g pawan) just for a little more confidence.

A recording of Steve’s entire live stream can be found here, along with all of the pictures of the flight recovered from the SD card here.

Untitled

UKHASnet WiFi node using ESP8266

Since the UKHAS conference in August I have been playing with some UKHASnet nodes, which are “A simple wireless network aimed for use with low power licence exempt wireless modules”.
The system was developed by members of the UKHAS community, but is not specifically aimed at ballooning (however can be used for it).
I have 2 LPC810 based nodes designed by James Coxon, and an AVR node from Phil Crump. After I had these set up, I loaded Phil’s code onto an old Cheapo v3 PCB and bug soldered a RFM69 onto the back. This made a pretty effective GPS node and after some tinkering I had positions being uploaded to ukhas.net.

15129165171_617a8f28db_b

The system relies on packets being repeated between nodes, before hitting a “gateway” node which is connected to the internet. This may be a node connected to a PC, or a raspberry pi with an RFM69 radio. After seeing the ESP8266 popping up in various places, I decided to order a couple of modules and design a PCB for a simple AVR based wifi node.

qlbQJpC

The PCB was very quick to put together and Phil’s repeater code had it working almost straight away.

node

I put together a library for sending HTTP POST requests to the ukhasnet server from an ESP8266 via AT commands. I updated my ESP chip with this firmware (File:V0.9.2.2_AT_Firmware.bin.zip from http://www.electrodragon.com/w/Wi07c /   Mirror) to reduce the speed down to 9600 baud. The chip does indeed work with WPA2 (which I was not expecting, possibly down to the firmware update)

The node has been running now for about 72 hours with no apparent problems 🙂

The ESP8266 Library, repeater/gateway code (credit to Phil) and PCB files are up at https://github.com/chrisstubbs93/ESP8266

The basic upload sketch looks something like this:

#include "ESP8266.h"
#include "wifiConfig.h" //this is where you need to set your SSID and Password
#define DST_IP "212.71.255.157" //ukhas.net 212.71.255.157
#define WIFI_EN 7 //CH_PD

ESP8266 esp8266 = ESP8266();

void setup()
{
  Serial.begin(9600); //Open serial communications 
  esp8266.initialise(Serial, WIFI_EN); //Pass it over to the ESP8266 class, along with the pin number to enable the module (CH_PD)
  while (!esp8266.resetModule()); //reset module until it is ready
  esp8266.tryConnectWifi(SSID, PASS);//connect to the wifi
  esp8266.singleConnectionMode(); //set the single connection mode
}

void loop()
{
  esp8266.uploadPacket(DST_IP, "your_data");
  delay(10000);
}


JOTA HAB launch

On the 18th and 19th of October I joined Steve Smith (G0TDJ) and Pete Sipple (M0PSX) at the Jamboree On The Air scout event in Basildon. We carried out two launches, a cheapo payload under a 100g pawan on Saturday, followed by Steve launching VAYU under a 36″ foil on Sunday.

My flight made it almost across the north sea before ditching in the water just short of the Netherlands.

DA13891_25 (Small)

gb1lc-day1-06

gb1lc-day1-07

Steve’s flight on the other hand entered a very nice float after being launched from the top of the climbing tower and made its way towards Sweden before running out of power.

JOTA1+2 B0TOg3mIUAEESu9.png large

 

Steve has done an excellent write up of the launch over on his blog: http://projecthab.co.uk/2014/10/22/jota-2014-two-successful-hab-flights/

As has Pete on the EssexHAM site: http://www.essexham.co.uk/news/basildon-jota-day-one.html