It had been forever since I took to the streets by night (actually it was only around 6 PM) armed with just my camera to take some pictures. Granted, I was somewhat inspired by Pierre T. Lambert, but then I also used to do this often years ago (I would link to the old blog, but it has degenerated into a backup on a dusty disk somewhere). Anyway, long story short, it was fun walking around again taking pictures of whatever seemed interesting. I decided to devote a blog article to the pictures for two reasons, firstly because I think it’s fun to share that I did this again. Secondly because I think not all of the pictures are interesting enough to put in the portfolio, if you want to call it that, but they’re fun enough to share within this context. So here they are.
GNSS receivers can suffer severely from radio frequency interference (RFI). RFI can introduce errors in the position and time calculations or if the interference is very severe, can lead to a total loss of GNSS reception. This vulnerability of GNSS can have large implications on critical infrastructure such as power plants, telephony, aviation or search and rescue operations. RFI is a real threat to GNSS as many interfering incidents are reported every day.
A common type of RFI is chirp interference, which is a sweep over a wide range of frequencies that overlap with the frequencies used by GNSS. This is often emitted by cheap Personal Privacy Devices that can be bought online. The question in this thesis was how well such interference can be modelled and if modelling could help mitigation against it.
This thesis consists of two main parts. In the first part a novel estimator is proposed that assumes a mathematical model of a chirp and estimates its parameters from recordings of chirps. The estimator has shown to work well in simulations for chirps with an SNR of −9 dB or more. On real recordings the estimates were accurate for 66.7 % of the signals.
In the second part the estimator was used to derive a filter. The filter is based on the subtraction of a replica of the chirp interference from the received signal. It uses the proposed estimator to create the replica. In simulations, the filter is able to improve correlation strength by up to 7 dB. On real recordings the performance was worse as for only 46 % of the recordings the GNSS correlation was increased.
Both the estimator and filter have many ways in which they could be improved. The estimator can be improved to allow for more complex chirps, which would in turn improve the filter. Both can also be made more computationally efficient.
Furthermore, in order to get a better understanding of Personal Privacy Devices, one such device has been tested. It was found that the signal from the device was very unstable and changed much over time, it was also highly dependent on ambient temperature.
So I wanted to natively print from my Macbook at the TU Delft, but that turned out to be a bit more involved then the manual made it seem. The manual (here) suggests to just download the XEROX driver they supply and all is good. Unfortunately, after installation nothing really happens. No printer is added, nor are any drivers installed. So let’s dig a little deeper.
The XEROX ‘driver’ that is supplied is a regular .pkg file that can be extracted and it reveals some interesting bits of information. Let’s extract it. For the sake of tidiness, create a folder and extract the contents into it.
$ mkdir xerox-drivers
$ cd xeros-drivers
$ xar -xf ../XEROX-PRINTER-HTTPS-EN-MAC-1.0.pkg
Alright, now we have four files (Bom, Payload, PackageInfo and Scripts). Now one might assume Payload carries the important stuff, but no. Let’s extract the Scripts file instead.
$ cat Payload| gunzip -dc | cpio -i
Guess what, a bunch of files appear.
Upon further inspection of the postinstall file, we see that the printer location is actually in that file, particularly lines 4-6,
as well as the printer type two lines further down
PPD="Xerox AltaLink C8035.gz"
Very well then, we now know the printer type and location. What we also know is that this installer appears to be some kind of wrapper around the actual printer drivers from Xerox. Probably they wanted to make the installation process smoother for Mac users, but since the installation fails somewhere without throwing any kind of errors or warnings, it doesn’t do a great job. Anyway, let’s carry on.
Start of by installing the actual Xerox drivers – I figured the latest ones would be fine (4.19) – by simply opening the .pkg from Finder. Walk through the installation and skip the part where you can add a printer, it is unable to find it anyway.
Next up is adding the actual FollowMe printer. Although I don’t understand exactly why, the ‘add printer’ dialog from the ‘Systems Preferences’ doesn’t seem to get the job done.
What worked for me was doing it through the CUPS (underlying printer infrastructure on Mac/Linux) web interface. It has to be enabled first however:
$ cupsctl WebInterface=yes
Then find it at http://localhost:631. Go to administration, log in with your user credentials (from your Macbook, if you’re unsure about your username do a quick whoami from a terminal ). Go to ‘Add printer’, choose internet printing via https. Type in the url ( https://webprint.tudelft.nl/printers/FollowMe/.printer ), continue and choose the proper drivers (Xerox C8035).
This will set it up. I then tried to print a test page from the CUPS interface, but it got stuck at status ‘Held for authentication’. Makes sense, since we haven’t logged in with our NetID yet. To overcome this, I went to the printer settings from ‘System preferences’, opened the queue for the FollowMe printer and hit the little retry button for the test document in the queue. This magically prompted me for my credentials, so I logged in with my NetID and guess what. I walked over to the printer and out came the CUPS test print.
A bit of a hassle, but we have native printing from my Macbook. Perfect.
I’ll refrain from phrases such as crazy/weird/challenging/uncertain times. Or did I?
Here’s the thing, in the earlier weeks of the lock down, online drinks became a thing. I’ve never been a huge fan, but it was something. One thing was really missing though, some game to play during those drinks! I’m talking drinking games, obviously.
One of the most popular, if not the most popular, drinking games in Delft is called ‘Mexen’. I’ll spare you the details, but it entails throwing dice and of course some reasonable (or not so reasonable) amounts of beer.
In order to cheer up my fellow students, a friend and I (with the help of yet another friend) cooked up a little online version of that game. It didn’t take much longer than a week and a half before it was up and running and gaining popularity. Give that another week or two and it was pretty much bug free.
The project was built using Node.js as a server and an Angular client, which was built and styled mostly by my pal Tijs. Every player fires up a Socket.IO connection to the server and this way the game is kept in sync.
I was really surprised by the difficulty of getting all the game dynamics right, especially since it really is a very simple game. This started by figuring out exactly how the game works. Normally you just play the game, but now we had to find out the exact rule set. Once we thought we figured this out, we moved to building a finite state machine or FSM to model the game states and how to transition from one to another.
Then came the bugs. And there were a lot. Not only was our initial FSM not very neatly implemented, there were also a bunch of scenarios that we hadn’t seen coming. What if the player that is up next leaves the game right before his move? What happens if all players wait for one player to drink his drinks and then that player leaves? There were dozens of problems like these, but at some point we had the majority figured out and improved the FSM. There were also some stability improvements and there it was, a drinking game for our students. It was a very educative project and we’re happy with the result.
To give it that final touch Tijs even implemented a chat box with the old MSN Messenger sound effects, that got some laughs.
The game may not be as relevant anymore, it was at least fun while everyone was locked indoors and we had fun building it!
Yes, really. This is one of those moments where you’ve been trying to achieve something for a number of years but still haven’t. Of course I was going to build my own website. First in PHP (remember Yii2?). That was off the table not much later. AngularJS + Loopback 3 was up next, this one actually got quite far, I had image upload and galleries all set up. Still however, it was not far from ready for release (I hadn’t understood the idea of rolling out straight away, agile, …, yet…). Of couse AngularJS is an archaic framework now, so that would have had to be replaced by – you guessed it – Angular (which one are we on yet?). Also, Loopback 3 has its flaws and NestJS seems a worthy opponent.
You get the point. I don’t have enough time to build a reasonable website for myselft, nor do I feel like it, nor can I decide on which framework to use. Enter simplicity. Who cares what it looks like, just pick something that works. And here we have it, 36 lines of YAML and the WordPress Docker image is spinning away. Thankfully I had some infrastructure in place from some earlier projects.
Anyway, here is a website. Expect some blog items (maybe, we’ll see) and some pictures (hopefully). If none of these things happen, at least you won’t get a 404 if you try to find me.