[This is a post 1 in series, for software setup go here]
If you want to explore the radio world around you, enthusiasts long time ago noticed that TV tuners are, with their software-defined radio core, the easiest way to get into it. They are widely available, cheap, and listen-only. This listen-only is a really important stuff as not only you can get yourself in a lot of legal troubles by transmitting willy-nilly, but you can also mostly ignore all that antenna matching stuff and not burn your devices.
One family of tuners captured radio hobbyist hearts all around - RTL. There is a bunch of chips in that family, RTL2832 and RTL2832U being the current favorites. There is not much about those chips to distinguish them from other TV tuners but the fact there were there first and they are well supported by software. If application supports radio on cheap, it will support RTL chipset.
However, the basic TV tuner devices are not know for their frequency stability. Their main purpose is working in a single frequency range so tight regulation was not of a major concern. Because of that you have companies like NooElec that either know which SDR receivers work well and they just resell them or, in some cases, they equip SDR receivers with a better crystal (e.g. 0.5 ppm). And that helps a lot.
There are many models on their pages and , if you go with 0.5PPM TCXO you are in excellent shape. I myself opted for Nano 2+ but Mini+ with its aluminium enclosure sure looked tempting.
If you have a powerful PC to dedicate as the radio receiver, story can end here - download SDR# or Cubic SDR and enjoy. However, I had something else in plan.
As my main PC is a notebook I got bored connecting SDR receiver every night only to disconnect it some time later. And lets not speak about all the driver tricks you usually need to make radio applications recognize it properly in 64-bit Windows 10. Fortunately pretty much all applications that recognize RTL can also work with it over the network. And creating remote RTL-based server is a job best done on Linux.
For remote Linux I gave quite a few thoughts toward Stick computers but decided against them due to a new Raspberry Pi 3. It has more than acceptable specs (doing RTL server is not really processor intensive task) and at $35 it is third of the price. As a bonus it is completely passive so we don’t need to be worried about the fan noise.
Even better, it has a wired ethernet port that gives better network experience and enables us to turn off wireless and get a cleaner radio input. Although with all the 2.4 GHz networks and microwave ovens blasting around, it makes a little difference in the end. And no, this small SDR device is not stable on 2.4 GHz, thanks for asking. Realistically, if you want to go into the GHz range, you need a better radio frontend than a cheap TV card.
For Raspberry Pi you need an SD card that will hold the operating system - any 4 GB or above micro-SD will do. You also need a power supply - just scavenge whatever you have lying around. And finally you might want to think about a case - that you will have to buy.
To sum it up, here is the equipment list assuming you have nothing at all:
PS: All prices are without tax and shipping, as customary in States. Your total amount will be a smidgen higher.
PPS: I have no connections neither to Newark nor NooElec. In case of Newark (or Element 14), it was the only supplier that had all items in stock at the time. In case of NooElec, their devices seemed to be at a perfect price/performance point.
Although I kept Bimil, my password manager, without a version for more than five years, version 1.10 comes right on heels of the 1.00.
Most noticeable change is adding the Start window. While not offering anything that isn’t possible in rest of the program, it does help speed-up opening of recently used files. Opening files in read-only mode also becomes possible and I’m sure this will be handy feature to many.
Fields have been refactored a bit; two-factor authentication and CVV buttons are hidden by default and former has gotten an option to show code instead of just copy.
Alongside a few minor fixes, feedback form has been moved to https. It just felt wrong to have password manager send messages via unencrypted channels. :)
As always, upgrade is available directly from program or these pages while source can be found on GitHub.
Those familiar with me and blog might know I love some things about Linux - especially bash - and I have more Unix/Linux-based computers than ones running Windows (although the number is close). For server-like tasks - even at home - nothing beats Linux. Yes, learning curve is a bit steep due to heavy reliance on the command line but that becomes a strength once you get used to it. And don’t start me talking about superiority of SSH. Anybody with interest in technology is losing a lot if they don’t at least try Linux.
Reason for my less than warm welcome is because I already have all Linux command-line applications worth running under Windows. If you download Git for Windows, you will get Bash shell and bunch of tools that go with it. Frankly, I rarely go into Windows command-line (or its bastard child PowerShell) anymore. Bash is simply more powerful and more practical. With a few easily remembered commands you can do wonders - especially when filtering files. And anything bigger 95% of time has Windows version too.
I don’t view Ubuntu on Windows as a bad step. But I don’t believe it will bring much to developers who had bash running on Windows, one way or another, for years. Considering it is a Windows Store application I am sure there will be enough gotchas to keep it from being practical…
Of course, details remain to be seen once Windows 10 Anniversary edition is out.
Few days ago I’ve found a bug in a program of mine. As I have feedback built-in in most programs, I decided to use it for once. And failed. All I’ve got was an error message.
A bit of troubleshooting later and I’ve narrowed the problem down. It would work perfectly well over HTTPS but it would fail on HTTP. Also it would fail when redirected from my old domain, whether it was HTTP or HTTPS. And failure was rather unusual error code 418. That was an error I’m often using to signal something wrong with redirects. A bit of a digging later, I’ve noticed I was using POST method for my error reporting (duh!).
You cannot redirect POST requests. And I was doing server-side redirecting (or trying to) from my old domain to a new one and from HTTP to HTTPS.
At the end I’ve changed all my programs to use HTTPS, temporarily disabled redirecting to allow HTTP-only connections, and I’ve had to re-enable same script on my old site so I can get error reports from old versions without update. I knew this last domain move has gone too smooth…
Sometime you might want to protect your data in memory - the greatest example is when dealing with anything related to passwords. It is simply not smart to keep that data around in a plain-text.
Each of these has its advantages and disadvantages and definitely each can find its place in a security toolbox. However, I prefer ProtectedData because it doesn’t require any Win32 API magic to read (as SecureString), nor it has any limitations on block length (as ProtectedMemory). As long as you are ok dealing with byte arrays, you can use it almost as a transparent storage.
Most of the times I end up having something like this (the most basic form):
privatestaticRandomNumberGenerator Rnd = RandomNumberGenerator.Create();privatebyte[] RawDataEntropy =newbyte[16];privatebyte[] RawData =null;internalbyte[] Data {get{if(this.RawData ==null){returnnewbyte[0];}//return empty array if no value has been set so farreturn ProtectedData.Unprotect(this.RawData,this.RawDataEntropy,
DataProtectionScope.CurrentUser);}set{
Rnd.GetBytes(this.RawDataEntropy);//new entropy every savethis.RawData = ProtectedData.Protect(value,this.RawDataEntropy,
DataProtectionScope.CurrentUser);}}
On each write we let Windows encrypt the data using a random entropy (in addition to its standard encryption) while on every read we simply decrypt the data and return a copy of it. Care should be taken to delete copies lying around, i.e. when you set the property and encrypt data, you should delete the original. Best practice for delete is to use Array.Clear, e.g.:
Array.Clear(value,0,value.Length);
I will leave it for reader’s exercise why that might be preferred to a simpler value = null.
PS: Note that, as soon as you convert bytes to a string (e.g. to show it to the user), you have signed capitulation as now you have an unencrypted copy of the protected data in memory. Yes, sometime you need to do it, but keep it brief.