Here it is, the 1st episode of Season 2 of HursleyFM!
This week Jezz leads the posse, and we walk through the latest and greatest in tech news. We include a strange new development of doping in competitive video game tournaments, the project to save our space heritage and we also talk about the mysterious Edge of Space project where we go into space using IBM's Bluemix and Messaging technology, and (is this the very first I.T related incident of divine intervention?) talk about how our probe fell 20 miles with no parachute and survived without a scratch.
That's our action in this podcast folks - plus a funky new intro soundtrack...
ICYMI - the HursleyFM crew talk to Steve Poole and Alan Ogilvy from the IBM Hursley Devops team, about helping IBMers and our customers support Developer Operations and so we can drive innovation while maintaining stability. What is the Devops culture and how is Cloud changing the game? Find out here...
ICYMI the first time around, here is HursleyFM S1 Episode 10 - where we talk to the (then) newly acquired Cloudant. Meet Simon, Kurt and Mike from the Cloudant team, who explain what Cloudant is and how it can be used to make our users lives simpler and easier.
Hey folks - ICYMI here is the recording of HursleyFM S1 Episode 4 - where we talk to one of the pillars of IBM Hursley, the awesome Derek Treagus. Derek talks to us about having a career in a software lab and having a terrific day, every day.
Welcome to HursleyFM Season 1 Episode 3, a podcast about life at IBM Hursley, a busy software Lab in the UK. In this episode we talk to Peter Anghelides who gives a wonderful insight into the workings of IBM Hursley and the people in it.
If this name is familiar to you Doctor Who and Blakes 7 fans, well there is a reason for that...
In this episode of HursleyFM Series 1 Episode 2, we give a roundup of tech news and then talk with Guy Barden who gives a technical introduction to Bluemix and Messaging.
Hey folks - I wanted to give you an introduction to HursleyFM about life in a busy software lab - namely IBM Hursley.
In this podcast we give a roundup of technology and talk to Joshua Carr about his (then) new role in developer relations. Click below to listen to the very first HursleyFM podcast:
Folks - if you are new to HursleyFM you might want to listen to the season 1 podcasts, just so you know what you have let yourself in for.
Mainly, they are all about life in a busy software lab, in this case IBM's Hursley Park near Winchester. It's kind of an awesome place, made so by the fantastic people that inhabit it.
Folks - just wanted to point you in the direction of the podcasts that we created as well as the Imperials own blog - hope you enjoy listening and reading as much as we enjoyed working at the Edge of Space...
We have posted quite a bit around the Edge of Space project and I thought it would be useful to put all the collateral in one place, so that you wouldn’t have to keep searching around for the podcast episodes and the blog posts on progress. So in a way, for anyone new to the story of getting a probe up to the Edge of Space and representing the conditions physically in the IBM Innovation Center, using Bluemix services including Messaging, Watson, Cloudant and NodeRED, here is a ‘jumping on point’
Ok – so let’s begin…
1. So start here, this is the overview presentation – given at the Hursley Summit
Here it is, thanks and reflections from the project.
It's been a truly joyous experience, I am so glad to be a part of it, but as is right the final word goes to the engineers...
Every project has to end, and this will likely be the final post on our blog. It’ll contain a bunch of leftover pictures and media, along with final thoughts and thanks to all involved.
The launch story is in Part 2 of this post if you want to read it, but I skimmed over the chase itself so the first order of business is to elaborate there. I think the best way to show the mishaps of the journey, however, isn’t through my words, but through the IRC chat from experienced high altitude ballooners commenting on our mishaps:
Our payload had a bit of an accidentSilver linings
I’m also able to share the moment we came across the payload in the forest in video format (apologies for the swearing):
The next order of business is to show some pictures from our camera in space! The view up there really is something else, so here’s a selection of the best images we got back from the meteorite payload that never should have survived:
Next up are a few more pictures from launch, plus a great video kindly filmed and edited by Mark Barnard:
To round things up, here’s a link to the presentation we gave the day after launch on dropbox: (link), and a link to Jon McNamara’s blog that he’s been running along side this one: (link)
I’d like to end with some final thoughts on the project from a perspective after the fact. It’s been a difficult project that only succeeded due to the help from the community at UKHAS (who we cannot thank enough) and a whole lot of luck along the way. In addition, one person we haven’t mentioned enough so far is our supervisor at IBM, Jon McNamara. He’s the one who kick started this whole thing in the first place, and without his vision to try a project as audacious as this none of it would have been possible. During the project itself he was also incredibly helpful and easy to work with, and lent us a hand with so many bits and pieces that would have been completely overlooked otherwise. The payload is now proudly displayed, safe and sound,in his office.
Other shoutouts go to Steve Upton for giving us guidance on our software’s entire architecture; Jeremy Pitt for being understanding of the roadblocks we ran into along the way and being flexible with us; everyone else at IBM such as Dominic Bramley who set up the innovation room for us; and everyone else involved at Imperial for setting up the industrial link so that this could happen.
There was also talk of a deeper relationship between Imperial and IBM as a result of this project, one of the outcomes being access to Bluemix for students at Imperial. It’s a fantastic piece of software, not without it’s bugs, but it really is the place to get the tedious bits of a project up and running so that you can focus on the innovative side of things. Speaking of innovation, there were ideas being thrown around of building a space at Imperial, similar to the Hursley innovation center, where students could be thrown into a room full of interesting tech, with the inevitable result being things such as this project happening.
The main players in this discussion were Jon McNamara and Jeremy Pitt, who are people with an appreciation for the potential of technology to not only solve problems, but to inspire an audience to push for further advancement in innovation. Tech can be a bit dry and corporate at times, and one big take away from this project is that it doesn’t have to be; in fact it really shouldn’t be if at all possible. This project is a perfect example of this in action, with ideas for the future being thrown around as a result of the launch – hopefully the end result will be a jumping-off point for even more cool projects to come and show what’s possible in this technologically auspicious world.
All the info you need to launch your own high altitude balloon: https://ukhas.org.uk/
OK... the title says it all - what happened on the launch and did they recover it... read on!
At the end of Part 1 I mentioned the biggest surprise of all occurring on launch day. Before I get to that particular surprise (which happened at the end of the flight), I’m going to keep you in suspense and walk through the launch itself. We arrived at the launch site, and quickly started assembling the hardware.
Half of us started tying the balloon and parachute together with cord, and then proceeded to fill the balloon. The other half got to work putting the payload together and praying that it would work following the disaster the previous day (detailed in Part 1). It wouldn’t let us off easy with the physical assembly either though, as putting all the pieces together came with it’s own problems; as the other half were happily filling up the balloon with the help of the guys from CUSF, suddenly a soldered joint on a wire to our LCD screen decided to break off.
I personally didn’t see it happen, but I looked over as Jake was dealing with the problem and over the course of ~10 seconds, panic washed over my entire body as I slowly realised what just happened. Curiously however, Jake, the man who I thought should have been the most worried because he discovered the problem first, looked completely zen. Even though he was probably frantically swearing to himself in his head, he calmly picked up the broken wire, stripped it with his teeth, wrapped it around the joint, and stuck it in place with duct tape.
Duct tape = MVP
We were all probably just as worried and sceptical about this solution as you are right now, but it miraculously worked for the entire flight! Duct tape quickly became our best friend, as we used it to stick everything else in place, and then taped on the lid to keep the whole thing secure(-ish).
After a few more minutes of filling the balloon, and an ingenious method of measuring the lift using water bottles (thank you convenient weight density of water), we were finally ready to launch. The balloon was nicely plump and trying to escape the chains of gravity, the payload was assembled, and everything was securely held together using a few metres of cord.
Praise the sun!
We released it and it actually rose up and flew into the air! I’m aware that this probably shouldn’t have been surprising, but after all that we’d done wrong it was a lovely change of pace to see that the most important component worked properly the first (and only) time, even though I have no doubts that this was all due to the help from the guys at CUSF.
The balloon rose into the air and it was majestic. As it climbed slowly out of sight it was the image of serenity, and we were graciously allowed a few moments to take stock and appreciate the beauty of life, the universe, and everything. Before long, however, we had to get a move on in our minibus and chase the balloon.
I honestly still can’t believe it actually rose
Chasing and recovering the payload is one of the best parts of launching a high altitude balloon, in fact it was personally my favourite. It’s not often in life that you get to track a flying probe on a map until it explodes, then falls all the way from space back to earth in the middle of nowhere. It’s almost as if you get to be a real life pirate, as you search for the treasure that you ‘buried’ all the way from space; you literally get to be a space pirate.
After 2 hours of following the balloon on the map, we were close to the predicted landing site and decided to grab some lunch in a nearby town while waiting for the balloon to burst, which was predicted to happen around an hour from the time that we stopped. Everything was going to plan; everything was going smoothly. However, as if on cue, the balloon burst early.
We were blissfully ignorant of this event while grabbing lunch, and it wasn’t until around 10 minutes after that we checked the IRC chat and found the guys helping us out telling us politely to get a move on! The original predictions were thrown out the window and we had to change our plans entirely.
The IRC chat at the time describes the events perfectly
However the real twist in the story hadn’t quite come yet, as fate had one more spanner to throw in the works – our parachute decided to not work.
The cruel hands of gravity had grabbed our poor payload with a lot more force than predicted, and it came hurtling towards earth at a rapid 25 miles an hour. The consensus in the IRC was that the parachute probably got tangled up in the remnants of the balloon and the flailing cord that tied it all together. This was bad news.
The payload however, as an autonomous entity without silly human emotions such as fear, was unfazed by the mortal danger it was in, and it kept on happily transmitting telemetry to the habhub receivers as it dived towards the ground. Despite the crisis, it was exciting to keep the habhub tracker page open and see the packets coming in one by one to update the map live; as it dropped closer and closer to the ground, the tracker received less and less packets, and following the map became a game of seeing if there’d be just one more…
In the end, the last packet came at an incredibly low 350 metres to landing, from a receiver over 50 kilometres away! We got lucky again. (Thank you to ‘db_G6ZH’ on the IRC for running the receiver! I mentioned it at the end of Part 1, but the receiving network run by UKHAS really is incredible. Make sure you don’t slack off in receiving though, any packets you upload will help them help you!)
This gave us a great chance for finding our payload, as the last packet being received so low let us off with a small search area. Whether the payload would will be in one piece where it landed was another question completely because of the speed it fell at, but we parked our minibus as close to the final coordinates as possible, and began the search.
The tracker gave us coordinates in and around a small forest, so we split up and started looking. Then, around an hour into the search, came the surprise that I first mentioned all the way back at the end of Part 1 of this post – the very same parachute that malfunctioned in the air managed to get caught on a tree branch, causing it to swing from side to side, preventing what would have been a fatal impact. We came across the payload in a small clearing within the trees, hanging from said branch around 5 metres in the air. It was like a gift from the gods.
a miracle
It was glorious. We had to take a few moments to realise the sheer unlikeliness of what just happened. Pretty much everything that could have gone wrong in the past couple of days did, but with the help of the community and a lot (a LOT) of luck, in the end we found our treasure. The thing was even still happily displaying tweets despite there being only duct tape holding one of the wires connecting the screen’s pins in place, and there’s a great picture that our pi camera took at the moment it landed in the forest:
Couldn’t have chosen a better tweet for this moment!
And here’s our final team photo sans sleepy-head:
Success!
Thank you for reading! This post is getting a little long so I’ll put the launch video, pi camera photos in space, and more funny bits of the IRC chat in one final post, so stay tuned!
Its the day of the launch! Here the team take us through the challenges and the bits they wish they had known before they started - but most importantly, how they did it...
First off, I’d like to thank the guys at UKHAS and HABHUB for all their support during this project. Without them, this would have been more than a disaster.]
[Also, this first part will only contain details on the preparation before launch day itself. Part 2 will contain all the pretty pictures and the story of the flight, but read on if you want to know about all the many things that went wrong beforehand.]
On the 24th June 2015, we finally launched our high altitude balloon, and it was, quite frankly, an absolute miracle. Let me tell you why.
To start with, we were very close to not even having a launch site. To launch a balloon in the UK, the Civil Aviation Authority (CAA) has to give to permission for your launch window so that they can notify airplanes to tell them not to crash into your balloon. Obviously to launch you need a launch site, and we originally applied for five or six locations ranging from the rather ambitious (the roof of the EEE building at Imperial in London) to the more conservative (Farley Mount). All of these applications were rejected.
However all hope was not lost because if a launch site has been approved in the past, then the CAA only needs 72 hours notice before granting a launch window. Luckily for us, the kind people at Cambridge University Space Flight (CUSF) were willing to let us use their launch site at Churchill College (thank you!). Unfortunately they were only on campus from the Monday on the 22nd, and our project presentation was on the 25th, so that only gave us a 3 day launch window to get the launch in before our deadline.
Usually launch windows are around a week long to have wiggle room depending on the weather, and the dates made sure that we’d only have 3 days. On the 24th, the day before our presentation, we got lucky and had great weather – sunshine and a gentle easterly breeze. We were lucky, but that really is just the beginning of our good fortune.
Sorting out the helium was also a close call. To get the gas to fill our balloon with, we ordered three small canisters from BOC, and had them delivered to our department stores. What we didn’t receive was a regulator to make sure that the air flow happened at a reasonable speed. If you happened to be in our labs when we collected the canisters, in fact probably if you were within the same building, and heard what sounded like a gunshot going off, that was the sound of us opening the valve and frantically closing it as fast as possible!
This was the day before launch so needless to say, we panicked. Running around campus and asking the chem eng department for regulators brought no success, so we were in trouble. Thankfully, later in the day Adam Greig from CUSF told us that we could use their regulator to save our bacon yet again.
We were also literally 15 minutes away from missing the 5pm deadline for booking the minibus to get us and the helium to Cambridge in the first place! If you didn’t know, it’s illegal to bring canisters of helium on public transport; we unfortunately didn’t consider this until the day before. All this trouble was because of an argument about the morality of reimbursement, and because of it we almost had no way of getting to the launch site! On top of that, if we hadn’t been lucky enough to have had Jake in the team, there would have been no chance of getting a minibus in the first place because he’s the only one who could book one from our union. Did I mention we were lucky?
And then, at 11pm the night before launch, came the biggest disaster of them all. Our SD card was corrupted, and had to be reflashed to install a fresh OS because it suddenly lost the ability to mount the main partition. Fortunately we had all the code backed up in a git repository; unfortunately, upon putting it all back in there, none of the telemetry from our transmitter was working properly. This could have been due to the new OS, or some missed packages, but the code was compiling fine, just not transmitting complete sentences and we could not work out why.
So we only had one choice – start from scratch. Our labs shut at midnight, so the only choice was to bring the pi home and to try and revert all the way back to the original code in Dave Akerman’s github. By the time I got home it was 1am, and we had to be back in school by 7am to get to Cambridge in time for a 10am launch. That left around 5 hours to get the whole thing done from scratch. Yikes.
This is the part of the post where I’m going to give a huge shoutout to Dave Akerman, the man who designed the Pi in the Sky that we’re using for communications. Without the code he wrote, we really would have been dead in the water. Waiting for the fresh code to install was the most anxious I’ve ever been, but the code ran and was being received perfectly by dl-fldigi.
The rest of the night/morning was spent adding as many features to the new code as possible, such as configuring the interface to the the screen or taking pictures with the camera. The only problem was that I didn’t have the payload with me at home, so I couldn’t test the code past the C compiler telling me that it compiled. The whole thing could have crashed as soon as the external hardware was attached, so the worries were far from over.
We now finally move onto launch day. It’s 7am and we’re packed up and ready to head out. Mostly. I won’t name names, but one member of our group failed to wake up in time, and we had to leave him behind. I won’t lie; part of me wished that I could stay as well because of the fear that everything would fall apart at the last minute. It almost did, but missing his alarm ended up being entirely his loss, because the day of launch brought the biggest surprise of all…
Which will be covered in Part 2 of this blog post – the launch itself. Thanks again to CUSF for all their help!
[I’m not sure where else to put this, so I’m going to quickly list some other pitfalls we almost fell into because the theme of this post is mistakes:
-Don’t touch the balloon without latex gloves on! Greasy hands (or greasy noses) degrade the silicon in the balloon.
-We almost attached our GPS antenna the wrong way up.
-Our antennas weren’t made correctly until a few days before launch, because we didn’t follow the correct tutorial! (ukhas.org)
-LCD quickly becomes CD at high altitude temperatures, so we should have used an OLED screen.
-Again, ukhas.org ukhas.org ukhas.org! If I could start over I’d read everything on there, then read it all again, then after a few weeks read it again because the stuff on there is critical because of everything that can go wrong.
-In terms of Bluemix, we should have made use of the HABHUB database api to funnel data to our outputs because it’s not feasible to track telemetry data all the way yourself.
-Relevant to point above: the (incredible) network of receivers that UKHAS set up to help balloonists track data was invaluable. It’s also all volunteer driven! However you shouldn’t rely on them entirely for tracking because any telemetry you upload helps them help you so don’t slack off!
-There’s probably a bunch of other things that we forgot about. If you have problems go to the IRC chat at #highaltitude (link). The guys there friendly and very experienced. We also enjoyed their wit, which you may see in Part 2 where there’ll be snippets of the chat for you to enjoy.]
Here the team from Imperial approach their deadline, and take stock of the work they have yet to do and attack it vigorously - legendary... read on!
It has been one of those weeks where it finally hits you, “THE DEADLINE IS IN A WEEK!”
It might have seemed like a quiet week for the blog, but believe you me, nothing about our work has been quiet. On the contrary, I have seen people run around the lab for broken solder joints and bang their heads on their laptop for buggy SQL queries.
Here are Constance and Jake, trying to get their heads around the optimal position to place sensors
Soldering the solder joint that unsoldered itself
But as we make our way through the patching and fixing, we are slowly wrapping up our project. The helium is on the way, the launch site is set, and our payload is about ready. The next big thing is for us to bid farewell to our beloved pi’s and let them teach us more about the edge of space.
Yes - incredible as it sounds, the team from Imperial will for your amazement unbox the components that will take the probe into space....
Last week we gave you a quick peak at our balloon kit that arrived from Sent Into Space. Today, as promised, we have for you an elaborate unboxing video where Jonny and Adi talk about the different components of the kit and how they fit together to make Edge of Space possible.
In this excerpt from the Imperials blog, Luke shows us firstly one of the main problems he encountered when processing the data from Space - and how he solved it with the magical Websockets.... read on!
Hello again! Thanks for getting this far, hopefully you enjoyed the previous posts too! The graphing tool is now live for you to have a play with if you haven’t had a chance to yet. I’m currently working hard on making it faster and better which I will talk about in this post.
This is final post of the series and possibly the most important. This post relates to the handling of the data itself and some of the problems I’ve faced along the way. I’ll talk you through how the data handling has evolved and the various tools I’ve used to improve the speed of the site and the accessibility of the data.
When it first came to accessing the data on the web page I went for what I knew – the http GET request. We were running a Node Red server that, when it received the request on a specific url replied with the data from the balloon as stored in a database. This worked locally just as expected and it worked well. The website displayed the data on the screen, all of it. We then moved to testing that across the internet and it didn’t work due to what is known as ‘the same-origin policy’.
The same origin policy dictates that requests can only be made to a server running on the same domain as the website. This was a problem but after a bit of research I found a way round it. Cross-domain requests can be made inside html script tags (like for accessing external libraries such as jQuery), combining this with the JSONP data structure allowed me to access the data cross-domain. JSONP works by wrapping JSON in a function call with the data as the argument, then when the script tag sends the request a function is called (which you define) and is passed the data. Voilà! I have defeated the same-origin policy with this work around but I still needed the data to be live.
Even with all of this in place I still required the user to refresh the page in order to get the newest data. I didn’t like this as I had set out to make the data live and forcing the user to get the data themselves was not efficient or live. To solve this I wrote a function to rewrite the script tag in the html in order to refresh the data periodically. This worked and the site now responded to new incoming data live. However (as you are probably thinking too) this is very inefficient. I quickly realised that although there was not much data at the moment, when it came to launch refreshing the entire dataset repeatedly is not a good way to do this. I thought there has to be a better way – and there was!
Our websocket server running in Node Red
This was when I discovered websockets. Why this wasn’t suggested for this task on every message board online I do not know because this solution seems clearly and obviously better. Websockets are like a http GET except the first connection is a handshake and then the channel is kept open in both directions. The client can query the server whenever is wants and the server can send over new data as and when it arrives! We set this up in the server (very quickly indeed with node red) and now the client can query the database directly – Perfect! This allows me to not only request only the data I need but also add new features that take advantage of this and would have taken too long with the old system. Are there any downsides to websockets? Yes, mainly that it is not supported in all browsers. However 85% of users have access to it and we have the old system in place as a backup for non-supported browsers.
Although websockets seem to be the answer there are some alternative solutions you could use. Hosting the website on the same server as the website would eliminate a lot of the cross-domain issues entirely and you could have direct access to the data. There is also a cross-domain protocol being put in place that is very similar to http GET called CORS. This would also work however I found it very difficult to use and seemingly in it’s infancy.
I enjoyed all of these challenges and hope by explaining my mistakes it will help someone else who is maybe battling the same issues. Currently the live site is not running the websockets code yet but I will migrate it soon so that you can check out the code. As always you can email me with questions at lde12@ic.ac.uk.
In this excerpt from the blog - the team show you how to take messages from space, and receive them and then use IBM technology to do something truly awesome with them, using MQ, Bluemix and a massive aerial.
Following up from the previous blog on sending messages to our raspberry pi on Bluemix (link), here’s a blog on how we’re going to receive messages from the raspberry pi and forward them to Bluemix. The hardware we’re using on the pi is Dave Akerman’s Pi in the Sky (link) and the hardware on the ground is the Funcube Pro+ Dongle (link) which plugs into my Asus netbook:
R is for receive, T is for transmit
To get good range on our receiver we’re using a yagi antenna (link), which is directional so it’ll have to be pointed in the direction of the balloon:
To get the pi sending packets through the Radiometrix transmitter on the Pi in the Sky you can follow the tutorial on this blog (link). This will be picked up by the dongle, where it’s driver places the signal into the sound card of your laptop. You then need some software that can understand these frequencies and convert them into something that packet decoding software can understand; in this case we’re using SDR# (link). Below is a picture of what you should see when receiving packets correctly. Make sure you’re using USB mode and have the ‘Correct IQ’ and ‘Swap I & Q’ boxes checked, then scroll to the frequency that your pi is sending on, and cover the ‘spike’ at your transmission frequency by changing the bandwidth to around the right size – it doesn’t have to be exact (these frequency and bandwidth settings will probably have to be tweaked to get the next piece of software working properly).
The input/output settings also have to be selected depending on your computer. On windows you need to go to your sound recording devices and turn on ‘Stereo Mix'; the software works by taking the radio waves received and putting it into your sound card and Stereo Mix allows SDR# to send its output to the next piece of software called ‘dl-fldigi). There’s an excellent tutorial on getting the settings in dl-fldigi for receiving Pi in the Sky telemetry here (link) so I’ll keep things short here. If you have your settings correct and sound card doing its job then, in the waterfall (the yellow/blue flowing section) there should be 2 clear and solid bands. If you click in the middle of these 2 then the software should do its job and you’ll start seeing your packets in the text log:
This software only forwards your transmissions to the habhub servers however (link), so you can’t get the data into Bluemix through the software alone (there are options in the menus for choosing a couch database URL to forward to, but we couldn’t get this working with Bluemix – even if we managed to then we wouldn’t be able to use their lovely website software to visualise the data). However you can log all the data into a text file by going in settings to Misc -> Text i/o -> Enable rx text stream. What we’re doing is running a python script to go trawl through this pile of text which looks like the picture below (due to the weird symbols logged because of the image packets):
Anybody who’s tried text manipulation with Python before has probably run into problems due to encodings and dreaded unicode errors, which isn’t helped by the fact that different versions of python handle text in different ways so you have to be very specific in your solutions. My solution uses Python 3.4 with the ‘linecache’ module imported, and to get around the unicode errors I typed ‘# coding: iso-8859-1′ into the top of the textout.txt log produced by dl-fldigi. This makes Python ignore any character outside of the original ascii set (link). Unfortunately this limits the characters you can use – for example our log now ignores dollar signs – but the main data in our telemetry is just numbers and letters to signify data such as coordinates or altitude so it does a good enough job to find what we want to send to Bluemix. With this you can use linecache.getline(‘textout.txt’, <line number>) to get the line you want while ignoring all the characters outside of the set defined.
regular expressions are a godsend
You can also see in the code above that the python script starts off by connecting to Bluemix’s quickstart service – tutorial at (link). We use the json module in Python to parse the data and publish to the topic ‘iot-2/evt/status/fmt/json’ (you can choose other topics if you register your device on the foundation but this use is simple enough to do it through quickstart).
our JSON format to send over MQTT
The flow in Bluemix is viciously simple (the left red bubble in the picture below). It’s just an IoT node connected straight into a Cloudant database. If you connect a debug node you should see something similar to our JSON packets in the log window on the right.
Accessing the data from this database and displaying it is something we’ll cover in a future blog, but for now I hope this is useful for anyone wanting to track a Pi in the sky or send data to Bluemix using MQTT.
