Drives over 2TB on Windows XP?

Before I bought my 8 TB Seagate external backup drive, I did a lot of research to see if it would work under Windows XP. Most sources claim that under no circumstances can XP read a drive over 2.2 TB. The then-price of $250 was a lot to gamble if it didn't work, so I had to know for sure. Fortunately, one source (probably Seagate or their Amazon listing) listed XP among compatible operating systems, so I bought it and it worked perfectly.

Most drives in the past (~1980s through early 2010s) had 512-byte sectors. Recently they've moved up to 4096-byte sectors. How does this help? Because each sector needs error correction codes, and it's more efficient to store 8 sectors' worth of information and error-code it once than to do it 8 times separately. This translates to higher drive capacity. The only catch is that ordinary BIOS-based computers can't boot from them (but they can be read as data drives by a running OS).

Most people argue that Windows XP can't read drives over 2.2 TB because the MBR partition table can only address 2^32 sectors, and since sectors are 512 bytes this means a 2TiB limit. One answer is to use GPT, but XP can't read that, so they conclude that GPT is the only option and hence XP is barred from using big drives. Microsoft's official stance is that XP can't read big drives, although I think this is to encourage sales of their newer operating systems.

The 2^32 part is right, but what these people fail to see is that MBR is addressing sectors, which is an arbitrary measure. Since drives now are 4K, each individual sector holds more, so bigger drives can be used by old operating systems.

This is all well and good if you buy a drive, because it would be pre-formatted. But what if you want to format the drive yourself? You shouldn't do it in an older operating system (probably includes Windows Vista) because, although it will format and be valid, the OS doesn't know to align the partition based on the sector size. Aligning it to an arbitrary offset was fine for 512-byte sectors, but it would slightly reduce performance on a 4K drive. Your partition should be offset by a multiple of 4096. If you want to verify that it is, then (under Windows XP), Click Start, Run, type msinfo32 and press Enter. In the System Information window that pops up, go to Components->Storage->Disks. Find your 4K drive and look for Partition Starting Offset.

One more concern voiced on a forum was that XP would only read the first 2TiB and experience errors on anything higher. I have disproved that by filling my 8 TB drive with about 3 TB of data and doing a search in Windows XP. There were no errors, so I am confident that XP had no issues. Besides, I went through some of the directory structure myself and looked at a few photos from a huge family album that has to have crossed the 2TB mark.

I think I've said enough. Here's a screenshot of the drive in Windows XP.

In a nutshell:

Myth #1: You can't use >2TB drives on Windows XP because they require GPT

Truth: While it's true XP doesn't support GPT, large drives don't need it*, so you're fine.

*Of course, if your >2TB drive has 512-byte sectors then you are out of luck.

Myth #2: XP only supports 512-byte sectors; Microsoft's official stance

Truth: Yeah, right. See first screenshot, in the Bytes/Sector field.

Myth #3: XP will only read and write the first 2 TB and then fail

Truth: No, my full-drive search under XP proves this is false.

I hope this helps the many uninformed people (like myself, previously) who waver over a drive purchase. I have backed up my points with real tests and pictures, not the unconfirmed advice you find on forums.

It's quite refreshing having recently made the switch back to XP.  Its clean, simple interface is unparalleled and the speed of Windows Explorer is amazing, even in the face of huge amounts of data. It's no secret why Windows XP still has nearly 11% market share. A new computer should be coming in the mail soon, and it has Windows 7 x64. I'll use that for things that need modern Windows.

LED TV interference

I was trying to receive some Iridium signals and turned on my TV while I worked. The TV is right beside my SDR and L-band patch antenna. It's an RCA LED TV from 2014, and when the screen came on I got interference all over the spectrum window. I noticed that the lines got weaker when there was less motion, suggesting the MPEG-2 decoder was the culprit. Or maybe it was the LCD controller. Whatever it was, when the TV show's intro briefly showed the static logo, the lines went away completely.

Iridium decoding: almost there

Recently I've been working on getting the Iridium Toolkit up and running. The Iridium Toolkit is a set of Python programs written by the CCC (a German hacking club) to decode whatever comes off an Iridium satellite. In one of their videos they describe how the system is proprietary and how they had to start from scratch, using trial and error to guess how it worked. They've finally figured it out pretty well and have published their findings.

I realized pretty quickly that this was one project my $20 rabbit ears couldn't handle, so I proceeded to build an L-band (1-2 GHz) antenna.

I first tried a helix, but it barely worked. I don't understand it, but I seem to have a knack for building bad antennas, even when I follow directions, so I was not surprised.

Then I tried a patch antenna. I'd heard that these work well on the L-band. I was expecting a small 1.5-inch square like those little GPS antennas, and I wondered how that could possibly work, but I was willing to try. On researching it, I found that it actually needs to be about 7 inches square with a ~4-inch square in the middle. This particular antenna was designed by Adam 9A4QAV. This RTL-SDR Blog post shows his antenna and its performance with the SDRplay. Notice how the Inmarsat signals look like blowtorches. What's most important is that you don't need an LNA or downconverter to make this happen with the SDRplay; it already comes with an LNA and full L-band support.

The instructions for this antenna can be found on another RTL-SDR Blog post. Finally, you should see killmore231's Adam's Imgur page which contains in-depth pictures. I was blown away by the waterfall images. Killmore231 describes how he tried the RTL dongle, HackRF, and SDRplay with this antenna and how the SDRplay beat out all of them by a huge margin.

I proceeded to build his antenna out of aluminum. I cut everything precisely, down to the millimeter. The only thing I couldn't do was solder to it, what with it being aluminum. I instead put some varnished wire through it, connected to the patch, and used a alligator clip to clip to the back plate. The first few times I hooked it up, it wouldn't show any satellite signals, making me think this was yet another dud.

Today, however, I realized that using varnished wire might leave conductive areas that could touch the back and short it out, so I ran a cut alligator clip to the patch, the plastic insulation providing guaranteed protection against contacting the back plate. I still needed an alligator clip to clip to the back plate. Then I hooked it up, leaned it near a window, and was able to get some strong Iridium signals.

Before, I had only gotten vague blue and green smudges, but these are sharp and have red areas. Below I have zoomed in on some of them:

There's no doubt this is Iridium. All this trouble makes me wonder how an Iridium phone's built-in antenna can possibly work. I watched a YouTube video of an Iridium phone in action and it got all the bars using just its little antenna.

I decided to mount my antenna on a pole sticking out of a second-floor window that's 25 feet above the ground. It gets great reception when it's outdoors like that.

I'm close to decoding Iridium but there are a few things I still don't understand:
1. Why do I only get the bursts? Why not the constant signals like in Adam's pictures?

2. Why doesn't Inmarsat show up? When I tune the Inmarsat band all I see is a strong signal that looks like GSM (see below)

3. What is keeping Python from running the Iridium Toolkit? I managed to install the dependencies it needed, like SciPy, but when I run extractor.py it seems to run but gives constant errors. I don't see any output files, either, so I assume it's not decoding anything.

Slovakia, Oman, and (almost) DRM

Yesterday evening I was tuning my SDRplay and heard two unfamiliar stations. One turned out to be from Slovakia and the other from Oman. According to HDSDR's S-meter, they were both S+40. Since I've never heard either country, I recorded them and uploaded the samples. I narrowed the AM filter partway through the Oman recording.







I also set up HDSDR's recording scheduler to record Radio Romania's DRM program when it comes on around 1:30 AM. Every morning I come and play it back to see if I can decode it. I use 38 kHz FM as the recording mode, centered on the signal, so I can play it back as an IQ file rather than audio. This gives me increased flexibility versus an audio file, since I can make minute changes to the tuned frequency and change things like the AM demodulator's AGC.

This morning I found I had gotten a stronger signal than usual. I was so close to being able to decode Radio Romania International's DRM program. (click to enlarge)

Understanding Spread Spectrum (Direct Sequence)

I've recently been working on some spread-spectrum DSP software for an experiment I'm conducting. I'm very familiar with frequency-hopping spread spectrum (FHSS). In fact, I own a pair of the discontinued TriSquare walkie-talkies. However, it took me a while to wrap my mind around direct-sequence spread spectrum, and now that I understand it I'm providing a simplified explanation for the benefit of others like me.

Background

Spread spectrum involves spreading a signal's bandwidth to enable many users to share a frequency band. It has the added benefit of providing decent privacy as it's very difficult to de-spread a signal unless you know the unique code used to spread it.

Before I got an SDRplay, I tuned my RTL-SDR to 900 MHz and spoke into a TriSquare walkie-talkie. On the waterfall I could see very short bursts of relatively wide FM. When a burst happened to land on my passband I could hear my voice momentarily. This came as a surprise since I had thought these walkie-talkies used encrypted digital voice. Even when not using my TriSquare I have seen similar bursts in the same band, and they are quite strong. These walkie-talkies are extremely rare so I knew it had to be another device. My research makes me think these are electric and gas meters.

I am particularly interested in creating a DSSS transmitter, but I didn't understand how to spread a signal evenly over a band, as opposed to hopping. This YouTube video was extremely helpful.

What doesn't work:

I misunderstood the video the first time around. Here's what I thought it meant:

Let's say I want to spread the string "SaaS" with a 20-byte spreading code of

"356A192B7913B04C54574D18C28D46E6395428AB".
(By the way, that's the SHA-1 hash of "1")

I thought spreading worked by literally spreading the whole message (or at least a chunk) over the spreading code. Here's what I imagined:

You repeat each letter of the string 5 times, and since the string is 4 bytes this becomes 20 bytes:

SSSSSaaaaaaaaaaSSSSS
In hex that is 5353535353616161616161616161615353535353

Then you XOR it with your 20-byte spreading code:
              5353535353616161616161616161615353535353
XOR     356A192B7913B04C54574D18C28D46E6395428AB
------------------------------------------------------------------------------
             6066651262585323565850522351551066676664

All seemed well and good until I wanted to despread it. I was completely at a loss as to how that would be done and, looking over the video again, saw that it would be a mess, if it was possible at all.
(On a side note, I know I could just XOR it again like a one-time pad and thereby recover the data, but if I had combined it with other signals then it likely would have been unrecoverable.)

What does work:

I found that in fact each bit of the message must be spread with the entire spreading code. So let's say I have a spreading code of 10010101. Just XOR each message bit by the entire spreading code. If I want to transmit a 1, then it would look like this:

            10010101 (entire spreading code)
XOR    11111111 (just one message bit)
----------------------
             01101010 (spreaded bits, chip rate 8x)

Now here's where it gets interesting. The signal must be transmitted as a waveform, so these bits are converted to voltages. The standard convention is 0 = +1 volt while 1 = -1 volt. However, when I was writing my modulator and demodulator I found it easier to think of it as 1 = +1 and 0 = -1. Using my convention, the message wave voltages would be:

-1 +1 +1 -1 +1 -1 +1 -1

Repeat the process with all the transmitters that must share the band. Then add their values together to get a composite waveform.

How do you recover just one stream? Assuming you tune in at the beginning of a bit's spreading cycle (which you can assume since you're working with samples in a file), simply multiply the +1/-1 values of the desired spreading code by the corresponding values of the composite waveform. This will yield a lot of crazy, fluctuating values. Average them. Unlike the YouTube tutorial, the average you get will not be clean-cut or precisely 1 or 0. You will have to depend on the sign to determine the actual bit. The software provided below takes this into account.

If you want to try this concept, I have written a program that generates *.CSV files of the waveforms of whatever text you like. It uses the 0=-1/1=+1 convention and uses just the sign of the average to determine the bits. Just save several different CSV files with different spreading codes and copy-paste them into their own Excel columns in one document. Then apply Excel's Average Add function to the final column. Copy-paste that column into its own file called "compositewaveform.csv" or whatever you like. The demodulator will read this file, accept the spreading code in a variable, despread the message, and show it on screen.

Here are download links for my program:
Written in Liberty BASIC v4.50

Spreader (proper_adjustable_spreader.bas)

Despreader (dsss_demod.bas)

Note that if you don't feel like combining several waveforms in Excel, you can still tell the demodulator to open just one waveform file and it will still despread it, provided you have given it the right spreading code.

You can experiment with spreading codes to see which ones coexist well. I have experimented with using the first 16 bits of SHA-512 hashes of consecutive numbers. My favorite hashing tool is a hex editor called HxD Hex Editor. It also has a great disk editor. However, I don't think it can copy-paste excessively large chunks. For that, use HHD Hex Editor Neo.

I have found that some of the data is corrupted when too many signals are together in the composite waveform. Also, some spreading codes do not coexist well at all, losing all the data in their streams. But higher chip rates, while reducing throughput, also reduce errors.

New recorder for SDRsharp breaks 2GiB limit

In my post ATSC now possible on magnetic drives I said that SDRsharp was the perfect solution for TV recording but lamented its 2 GiB limitation.

In my opinion, HDSDR and SDRsharp are the two best SDR applications. HDSDR has minuscule computing requirements (low CPU usage) and more reliable recording while SDRsharp draws a slightly better waterfall and (at least for older versions) is more fun to use overall.

I especially like that HDSDR is written (AFAIK) in rock-solid, no-frills Win32 C++ instead of SDRsharp which was done in C# .NET. Pure C++ produces smaller and lighter programs that don't crash or bog down the CPU quite as easily.

Since the recording function is so reliable and well-written in HDSDR, not to mention the support it has for files of unlimited size, I have written 2 emails to the author of HDSDR asking him to add 8-bit recording. However, he has not gotten back to me. On the HDSDR website it says the latest version is from 2013, implying that he has halted development. That fine by me, though. Apart from the lack of 8-bit recording, HDSDR is perfect and I hate when software developers mess with perfection.

Last week I emailed Youssef Touil, the author of SDRsharp, requesting that he update SDRsharp to support larger files. After I explained that it wasn't specifically for the SDRplay he kindly sent me links to plugins that will unlock >2GiB recording. Here they are:

Baseband Recorder (http://rtl-sdr.ru/uploads/download/basebandrecorder.zip)
WavPlayer (http://rtl-sdr.ru/uploads/download/wavplayer.zip)

Today I had a chance to test the Baseband Recorder. To use it yourself, open the zip file after downloading and go into the basebandrecorder folder:

I only needed the Baseband Recorder because my goal is to convert the files in Audacity, not play them back. Just select the 4 files you see and do Ctrl+C. Then go into your SDRsharp folder and paste.

Then you will need to open MagicLine.txt and do Ctrl+A and Ctrl+C. Close MagicLine.txt and open Plugins.xml in your SDRsharp folder. Paste the line in where indicated:

You may have more or fewer plugins than I do, but you get the general idea. Also, as you can see, it needn't be tabbed over.

Save Plugins.xml and open SDRsharp. You should see the new recorder at the bottom of the sidebar.

Click the arrow to expand it.

And there you have it: a flexible new recorder that even supports choosing an output directory. To show just how flexible it is, here is the Configure dialog:

What... did that just say WAV RF64?!? Yes it did!

With this plugin we are very close to being able to do some awesome stuff with ATSC decoding. Now the last step is to figure out how to capture the necessary 7 MHz bandwidth as opposed to SDRsharp's baseband which is limited to 250 KHz. I was really hoping I could capture the whole bandwidth with this plugin.

(Update 03/01/2016)

I made a mistake above. I had confused Baseband with passband. Baseband in SDR# is the same as RF in HDSDR, which means that this plugin will record your full RF bandwidth. I had my SDRplay set to about 200 kHz during the first test, and so the WAV file's properties said 200 kHz sampling, reinforcing my false assumption that this plugin only records passband.

I am very pleased to see that progress bar underneath "Dropped buffers: 0". In case you didn't know, the progress bar represents the recording buffer. In a previous post I suggested that a buffer be used to smooth out the latency inherent in magnetic hard drives. It seems that the author of this plugin has taken that into account. I don't think the buffer is very big, but it's certainly better than nothing (ever notice how the native SDR# recorder seems so prone to dropping samples? I suspect the native recorder has no buffer.)

Today I made some TV recordings on 8-bit with this plugin, converting them to 16 bits in Audacity and decoding them. Sure enough, the plugin works as I had hoped. I was able to take recordings of unlimited length and I chose to stop them at 8 GB because I didn't want Audacity to take too long to convert them. Both final decodes were rife with errors, although WACH had some perfect spots. I only used the two blowtorches in my area, WJBF and WACH. These two have always been the most reliable, so it is obviously something wrong with the new method. I think it has something to do with 8-bit and the reduced dynamic range because no buffers were dropped.

In conclusion, if you can get around the reliability problem then it is now possible to take TV recordings of virtually unlimited length using magnetic hard drives.

Special thanks to Youssef Touil for showing me the final piece of the puzzle that made this possible.

Why I still prefer Windows XP

A few days ago I restored my laptop to Windows XP from a hard drive image I made before upgrading to Windows 10. As you know, I only upgraded so I could use Visual Studio and Office 2013. I prefer XP and here's a major reason why:

Above you can see I've set my SDRplay to the full 8 MHz of bandwidth. It's tuned to a Volmet upper-sideband weather report and there is no stutter. HDSDR reports only about 50% CPU usage. (Notice how overall usage is not ~100%, like Windows 10 would be?)

Fortunately, I also imaged the drive before going back to XP, so I have a Windows 10 drive image. After a nice break from Windows 10, I have to restore it so I can finish an app I'm working on in Visual Studio.

I restored my Windows 10 backup. Here in Windows 10 I've got HDSDR tuned to some RTTY on lower-sideband and it stutters incessantly. CPU usage is almost 100%. (If you click to zoom in, you can even see a strip of waterfall smear at the top where HDSDR froze.)

But maybe Windows 10 isn't really to blame. Maybe my laptop is just too old to hardware-accelerate all the visual styles, so it has to be done by the CPU. I would like to blame it on the background processes, but HDSDR itself is at nearly 100% CPU, and the overall CPU reading is only marginally higher. A newer computer should be able to run HDSDR with 8 MHz bandwidth without breaking a sweat, but there's no denying XP was a much leaner OS.