V2.1.0.0 – Added timers & automatic startup/shutdown
You can now add a registry key to start with Windows. Create on/off timers for devices. Automatically turn devices on/off on program launch/exit.
V2.1.0.0 – Added timers & automatic startup/shutdown
You can now add a registry key to start with Windows. Create on/off timers for devices. Automatically turn devices on/off on program launch/exit.
2.0.0.0 – First release to GitHub
New features:
CLI mode.
Copy ID to clipboard.
Bug fixes:
Better management of tray icons.
Removed from alt-tab list when minimised to tray.
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!
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.
. @emfroamer Sad roamer, where shall we take it? Keeps turning in a circle even after being de-hayed. pic.twitter.com/J6CnaTgK6i
— Lauren Hutchinson (@Ravenbloom) September 1, 2018
Just needed a quick gearbox rebuild. Gears+grass=bad pic.twitter.com/yVSI09pj0w
— EMF Roamer (@EmfRoamer) September 1, 2018
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.
Just completed a blazing fast lap of 6:42 with @EmfRoamer on the @Hacky_Racers track at #EMFcamp pic.twitter.com/1joAqtAXFf
— Sebastian Goscik (@ep1cman) September 2, 2018
Some stats:
Improvements:
I used Excel 3D Maps to produce the map animation from CSV GPS logs.
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.
A #OneSquareInch musical tesla coil playing ghostbusters for the @hackadayio square inch PCB contest! pic.twitter.com/W7CcJEdNDg
— Chris Stubbs (@M6EDF) September 16, 2018
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.
Video and photos credit Pete M0PSX
Footage from TX Factor to follow.
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.
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.
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.
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.
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.
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.
The PCB was very quick to put together and Phil’s repeater code had it working almost straight away.
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); }
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.
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.
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
I recently ran a test to investigate why the rfm22b often fails at low temperatures, with some interesting results.
The radio module was set up in a test chamber and cycled from +20 to -50 degrees Celsius and repeated 5 times. The board was powered and the output frequency monitored and logged using an SDR.
The above results were surprising, as I was expecting the rfm22b to drop out around -40, however it carried on transmitting just fine all the way to -50. However as the temperature rose back out to ambient the module stopped transmitting as the temperature passed about -10. This happened consistently 4 out of the 5 times tested. I believe this is caused by dew forming on the crystal and pulling the frequency way out. You can see the frequency clearly shoot off to the side in this screen capture:
You can see in the graph below how the temperature affected the frequency, and where the module dropped out. I have also put together a time lapse of the SDR output to illustrate the drifting.
Test data spreadsheet: rfm22b_test_data.xlsm