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.

Toshiba Encore first impressions

For Christmas I received a Toshiba Encore WT8-A32 8-inch Windows tablet. It has 2 GB RAM and 32GB storage. It was refurbished but like-new and cost only $91.19. It was an amazing deal because it's hard to find a working Windows tablet with that much RAM and storage under $100.

Tablet's best qualities

• Dual-band Wi-Fi (both 2.4 and 5GHz; 802.11abgn)
• 2 GB RAM (most cheap ones have 1 GB)
• 32 GB solid-state storage (16 GB on most cheap ones)
• 8 inches - pretty big
• Quad-Core Intel Z3740 CPU - fast and uncommon in cheap tablets
• This CPU family is said to be able to hardware-decode H.263, H.264, and even VP8, among others
• The GPU (built into the CPU) is new enough that it runs the latest Stellarium without problems

The Wi-Fi seems good. My Lenovo T60p was able to connect and do pings on a G network from much further away than the tablet, but it was a business-grade laptop and had bigger antennas, so that's to be expected. But the tablet's Wi-Fi is by no means bad. Aside from supporting 802.11n, which the Lenovo doesn't, it's been able to connect to the Wi-Fi at Sams Club while I was sitting in a car in the parking lot.

When I first turned it on, I was shocked at the display's contrast ratio. It uses IPS technology, so it's no OLED, but it looks a lot better than most other screens I work with.

Battery life is nice as long as the screen is dim. Just try to avoid Flash video on websites whenever possible. I use the latest Opera, which supports HTML5, and YouTube always selects HTML5 for me. I've read that it's more power-efficient that Flash, and I've observed it to be true. My battery went to almost nothing after watching a little bit of AFV on the official ABC website, which uses Flash, but I've been able to watch YouTube with HTML5 for hours without a recharge.

I also installed the K-Lite Codec Pack which comes with Media Player Classic. I experimented to see which hardware decoder would have the least CPU load. I downloaded the official music video of Little Talks by Of Monsters and Men from YouTube in 720p H.264 format using 4k Video Downloader, which is a lot nicer for this task than Any Video Converter. After trying both Intel Quicksync and DXVA2 Native, I saw that DXVA2 Native used significantly less CPU than Quicksync. I even asked about this on a forum related to K-Lite and the admin confirmed it.

You'll need a good dedicated USB device charger (included). Some mobile devices, including this tablet, will not charge off computers and certain wall chargers. I have, however, been able to charge it in the car.

I also learned that the Lithium-Ion batteries used in mobile devices should not be fully charged and discharged except once a month or even less. I'd always heard that batteries had a memory and so should be fully cycled, but everyone says this type does not have a memory and lasts longer if kept between 40% and 80%. Maybe that's how my Lenovo T60p's battery got ruined...

Battery pitfall

Recently the battery charge indicator had gotten stuck at 100%. It thinks it's 100%, runs down to nothing, and suddenly shuts off. Even if I stop charging at 82% or 74%, it's stays at that value. I did some searches online and this is a very common problem for mobile devices. It has to do with the battery not calibrating. I couldn't find a Windows tablet app to calibrate the battery, so I did some more reading and at least one person on a forum suggested letting it charge to 100%, running it until it turns off, and then charging it again. This is supposed to make it automatically re-calibrate the battery. But over the last 3 days the battery had been exhibiting this condition with no indication of stopping. I was concerned that I may have gotten a dud tablet.

How I saved my battery

Today I realized the tablet had only gotten stuck at 100% when I went to Sams Club 3 days ago. I normally kept my screen at its dimmest, but that day I set it one or two ticks brighter. It subsequently got stuck at 100% when I charged it. The next day it just turned off. After charging and dying several times over three days, today (1/13/2016) it went down to 67% when I had left it at 74%. It hadn't gone down at all in 3 days so this was a relief, but I had to be sure it wasn't just a fluke. Since AFV is notorious for draining the battery, I played a couple minutes of it, and sure enough, the battery went down at least 2 percentage points. The lesson? Expect a few days of automatic recalibration if you change your screen brightness.


The tablet has front and rear cameras and an ambient light sensor. Most of the time the Camera app just shows blackness because sometimes the cameras can't be connected to. Skype's camera preview showed green once when this happened but for some reason Skype can now connect without issues.

The tablet has a GPS sensor, a Broadcom BCM4752 chip. It supports 4 different satellite constellations and supposedly works indoors by triangulating Wi-Fi, although I haven't seen any way of doing that. The tablet rarely gets fixes when stationary and when it does they are very inaccurate. For me, at least, you have to be going about 3 mph (a brisk walk) or faster to get any fixes at all. If you are moving then it will consistently get fixes once per second and they are usually surprisingly accurate. I've even tested it in the car while traveling over 65 mph and it still got dependable position fixes once per second. The GPS sensor only provides info over the Windows Location Platform. It will not natively output NMEA 0183 streams. However, there are people on forums who are able to use conversion software to emulate a regular serial GPS.

The tablet runs Windows 8.1, which takes up most of the hard drive. I've read that upgrading to Windows 10 would free up a lot of space, but I don't think I'll upgrade for quite a while. My Lenovo T60p runs Windows 10 and seems to get slower every day. To some extent, so does a more recent laptop I upgraded. It also runs out of memory on my T60p way before it should, but that started recently. I looked it up online and I think it's a bad Windows Update (gotta love mandatory updates.)

Why I won't be upgrading my tablet to Windows 10 (yet):

1. Constantly phones home to Microsoft
2. Runs mysterious processes in the background for no reason, using hard drive, memory, and CPU time
3. The Start menu and taskbar notification icons are a bit unresponsive and sometimes the Start menu doesn't let you enter search keywords
4. Low on Memory errors and program crashes when there's still 500MB RAM left
5. All Windows Updates mandatory and automatic
6. Battery life rumored to be worse versus Windows 8 (no surprise: see #1 and #5)

On older Windows versions, such as XP, menus popped up immediately. The fact that the new Start menu and especially notification icons sometimes take a while to respond implies to me that that part of Windows' interface may be running on top of some emulator. Still, it's free, so we should expect some issues. I really like how XP was tolerant of low memory and you could be reasonably certain your computer was truly idle when you weren't using it.

Capturing Weather Satellites Easily

I've been wanting to capture weather satellite signals for quite a while. This was one of my considerations when I chose the SDRPlay, since the high-quality digital mode is 4 MHz wide. Tonight I was able to capture the low-quality analog signal.

For this and most of my other experiments, I used TV rabbit ears. They're from Target and cost about $20. This is my go-to antenna, offering great performance on VHF and up. With it, I've been able to receive broadcast FM, 1900 MHz GSM, and everything in between. Just don't expect it to do HF very well.

I'm particularly interested in the digital HRPT signals, but since I'm not fully set up for that yet, I had to settle for the analog one. That's OK, because I didn't even see anything on the HRPT frequencies when NOAA-19 passed by this afternoon.

Unlike what I first expected, it's not hard to capture weather satellites, even though some online tutorials might look hard. My favorite radio projects are those that accept an audio signal through Stereo Mix and decode it live. I don't like having to record, transcode, feed IQ into complex software, etc. I will if necessary, like I did with GNURadio and ATSC, but I really prefer live audio-based decoders.

I did manage to capture a weak signal of NOAA-19's analog broadcast. It was too weak, so I didn't get a good decode. Later, NOAA-18 made a pass and I managed to tune it in. The funny thing was, Stellarium reported it as transmitting on 137.1 MHz. I didn't see anything when I tuned there, so I checked Wikipedia and it said that NOAA-18 is actually on 137.9125 MHz, having moved to that frequency in 2009. It's a good thing I didn't just wait for a signal, because I would've missed a great pass.

I tried to look up what LRPT looks like on sigidwiki.com, but there was nothing. Turns out the signal is actually called APT. LRPT is a Russian digital (but low-res) format. I've included pictures of APT below.

Very strong:

Really bad when it passed over my house:

I also would've appreciated a sound sample so I could positively identify it, so I've included one. It's recorded in NFM.

Directions:

I managed to find a program called WXtoImg that can decode by sound instead of pre-recorded files. It's free but you can pay for more features if you want.

Next you need a program to tell you where and when the satellites will pass. I use Stellarium. Since I have an older video card, I have to use the 0.12.x series. Enable the satellites plugin and make sure it updates the orbital elements (it should do so automatically.)

Now zoom out and scroll in such a way that the ground wraps around so that the sky is a circle in the middle. This lets you see the whole sky at once. Go into Stellarium's Date and Time dialog, click in the minute, and push the Up arrow key. Stop when a weather satellite shows up (Hint: NOAA-17 is dead.) Try to find a good, high pass. I ignore any passes that just skim the horizon. You might want to look up which other NOAA satellites are dead. NOAA-15, -18, and -19 are functional at the time of this writing. Make a note of the time and direction the satellites rises. Try to find a window that faces that direction or go outdoors when it's time.

When the time comes, turn on HDSDR, set the mode to FM, bandwidth to about 30 KHz, tune to the proper frequency, and notice how it is a few kilohertz off. This is due to Doppler shift. Zoom in and tune to the actual center frequency. Since this is FM, being off-center will hamper the signal. Be sure that Stereo Mix is your default recording source and that the volume is about right.

You can also record 48 KHz IF and demodulate it later if you prefer. It's quite easy in HDSDR, just right-click the Record button and check the IF checkbox. This would let you go back and try different settings without missing the pass.

Be sure to turn on AFC in HDSDR. This tells HDSDR to automatically stay centered on the signal as the frequency shifts.

Open WXtoImg. Click File->Record. Under Record and auto process, click Create image(s). Then click Manual Test. It should now start scanning upwards. You should see test patterns on the side and be able to recognize clouds. If you're indoors, the signal will go away abruptly as the satellite passes directly over your house and sets, even if the antenna is in a window. It might work better if the antenna is outside with a clear view of the sky.

Here is the final, but unprocessed, picture:
(click to enlarge)

Notice how the lines in the waterfall above are slanted? As the satellite rises and sets, the Doppler shift constantly changes the signal's perceived frequency. This is why you need to enable AFC.

My opinion of Digital TV

I think digital TV is a great concept, but is not implemented correctly.

(Update 1/13/2016) I found out from the GNURadio mailing list that the ATSC group is working on a new version of ATSC (version 3) that uses OFDM. The new standard was exhibited at the Consumer Electronics Show in Las Vegas last week and will probably solve the unreliability issue.

In 2009, most TV stations in the United States were forced to turn off analog transmitters. In September 2015, the last few stations were told to turn off their analog channels. Cable and satellite are still allowed to use analog, but it's cheaper for them to use digital because they can pack more channels into the same bandwidth.

The government claimed it needed a lot of the old analog channels for mobile broadband (LTE) and public safety communications. It seems to me that TV broadcasters could have just been told, "We're kicking you off the high channels because a cell company offered us a lot of money," and let them keep transmitting analog in their new channels. Analog probably wouldn't have bothered the higher-frequency services. It isn't a "waste of bandwidth" as some say, because in terms of RF bandwidth, digital channels use the same amount (although they do multiplex multiple channels onto it.) Also, it makes no sense to ban analog on low bands like 50 MHz. Cell companies obviously have no use for those bands, so why waste spectrum by outlawing analog transmission in them? I'm pretty sure the ionosphere would never let ATSC work in a band like that.

I seem to remember reading, possibly on the FCC website, about how digital stations have increased coverage because they're more efficient. I even saw a map comparing coverage areas before and after the transition. Anyone who's watched over-the-air digital TV knows that's a lie. Far away, you could get a snowy picture. Even if you couldn't get the picture, the sound on analog was pretty reliable. Now it's all or nothing. If you don't get perfect reception, you get none at all.

But, assuming it was necessary to change to digital, how could things have been done better?

Whoever designed ATSC should have known that VSB (vestigial sideband) was a bad idea. VSB is a form of AM, and we all know AM isn't very reliable in bad conditions. Old analog channels used VSB for the picture and ordinary FM (the same format as broadcast FM) for the sound. I'd love to see digital TV get implemented in ultra-wide FM, maybe 10-20 MHz wide. I'm sure that would make the signal nearly unstoppable, but it would also take up too much spectrum.

We've had since the 1940's to figure out that VSB is prone to issues. Why would we choose it for our digital standard? In Europe they use OFDM for their DVB-T standard. Some say OFDM is better. It's what other services like Wi-Fi use. Wikipedia says it's more reliable in the presence of multipath and bad weather than digital VSB. Multipath is what keeps TV from working in a moving vehicle. And what about passing vehicles? If they reflect the signal just right, the signal will go out. If you look online, you can find a story about a US company that wanted the FCC to give TV broadcasters the choice of OFDM vs digital VSB. The FCC said no, so we're stuck with VSB.

I know analog was great because I remember one rainy day in the mountains with a portable TV. The FM sound came through, but the AM picture was obliterated by the rain.

I'd like to see analog come back as a broadcaster's choice, but that's not likely. It turns out I'm not the only one who wants analog back. Here's what someone commented at http://moronstalkingrubbish.com/dontTurnOffAnalogueTVAust.htm

A small majority of us, here, in the US are currently petitioning our congress to bring back analog since signal interference is caused by trains, snowmobiles, & autos. It's almost 2013 and the dtv has not become better for the millions of lower class who once had reception on functioning equipment.

There are many others online who feel the same way. There are some petitions you can sign online asking the government to allow analog TV again. The higher frequencies are gone to cell companies, but analog in the low bands would still be great. I'd sign them if I thought it would do any good, but if you're interested here are some links:

Petition2Congress: Bring Analog TV Back!!!!!!!
GoPetition: Bring back Analog for the people who can't afford to switch to Digital TV
thepetitionsite: bring back analog TV

ATSC now possible on magnetic drives

I have found a way to reduce the data rate of ATSC IQ recording from 32 MiB/sec to 14 MiB/sec.

Last night I was taking some recordings of Fox, recording clips of World's Funniest. I was annoyed at only being able to take 1 minute at a time and then having to wait almost two minutes transferring it from RAM to my external hard drive. Taking 1 minute clips spaced 2 minutes apart causes you to miss so much and because of this I looked into reducing the required data bandwidth.

To make a long story short, I found a way to take 8-bit IQ recordings and thus reduce data bandwidth to the point where you can actually take IQ recordings to an ordinary hard drive. Why is this important? Because with hard drives being so cheap versus SSD's, you can buy an 8 TB model like mine and (at least in theory) take recordings of virtually unlimited length.

This new way of recording will take the required data from the 32 MiB/sec in my original work down to 14 MiB/sec, while still yielding good decodes! This should be well within what a magnetic drive can handle, plus it takes less data so your hard drive space goes further.

A few notes/tips:

• Use 7 MHz bandwidth on the SDRPlay. Although I said to use 8 before, 7 has been proven to provide flawless recordings while taking up less data.
• If you can find one, I would suggest you use an older version of SDRSharp. All my recent perfect decodes were recorded in SDRSharp. As I said before, it has superior DC cancellation.
• SDRSharp also has an 8-bit recording option

Some math...

Last night I was limited to 1 minute 12 seconds on a 2-GiB RAM drive. I was using 7 MHz bandwidth at 16 bits per sample. I used a stopwatch app on my phone to time how long it takes Windows to move this onto my external drive, since Windows' reported transfer rate is inaccurate. It took me 102 seconds to transfer. The files were about 1.92 GiB each.

1.92 GiB divided by 102 = about 19 MiB / sec average transfer rate. At 16-bit sampling, this would only allow you to record 4.75 MHz of spectrum, which is obviously not enough for TV. When I calculated this, I saw that if I could switch to 8-bit recordings, my hard drives would be sufficiently fast.

Recall in my last post that I said it would take 16 MiB/sec to do an 8 MHz @ 8 bit recording, which is below the 19 MiB/sec I just calculated. But now that I'm using 7 MHz, it would only take 14 MiB/sec, well below the limit.

But 8-bit recordings didn't work last time. Then it dawned on me: if GNURadio can't natively decode 8-bit ATSC recordings, why not trick it by taking an 8-bit recording and upsampling to 16 bits?

After some more tests I noticed SDRSharp is limited to 2 GiB, which is about 2 minutes. This is a hard limit of the official WAV format, and SDRSharp doesn't support RAW or WAV64. If anyone finds a fix for this please comment below.

How I did it:

Today I took an 8-bit recording in SDRSharp. It was a WAV file, not RAW, so I was able to open it in Audacity and merely save it as a 16-bit WAV. I knew Audacity likes to dither, but that doesn't seem to happen on upsampling. I verified the 16-bit WAV I had just generated by opening it in SDRSharp and, sure enough, it looked like a great signal, so I knew Audacity hadn't messed it up.

Below: live waterfall of WACH Fox.

Below: 8-to-16 bit converted WAV recording

As you can see, there's very little difference.

I fed the 16-bit converted WAV through GNURadio as usual, and waited expectantly. For all I knew, I could get the dreaded "!!! atsc_fs_checker" errors, or simply an empty TS file. Neither happened (see below) but I still had no proof it would play.

To my surprise it actually played! (although it did skip in 2 spots)
(pictured below)

I think the skips were caused by minor sample dropping, so it should work perfectly with a very fast and defragmented hard drive. Of course, PrimoCache would still be a great idea to smooth out any hard drive latency, such as what occurs during recalibration, but only as long as the IQ data rate doesn't exceed your drive's average write speed.

I did more tests on Sunday, but with a RAM drive this time to avoid latency. 8-bit recording is indeed very reliable, not to mention space-efficient, as I was able to fit 2 minutes 33 seconds into my 2-GiB limit. I had been concerned about the reduced dynamic range afforded by 8-bit sampling, but my fears seem to be unfounded.

It would be amazing to leave this recording, latency smoothed out, to my 8 TB drive, to catch shows I'd miss. Below are two ideas for software fixes that would allow us to set up a full software-based DVR.

1. HDSDR supports unlimited file length but has a minimum bit depth of 16. It should be updated to support 8-bit recording,
2. SDR#, on the other hand, supports 8-bit recording but [its native recorder] is limited to 2 GiB. It should be updated to use a format other than WAV. See new recorder for SDRsharp breaks 2GiB limit. With a certain 3rd-party plugin, we can now take 8-bit recordings of unlimited length in Wave RF64 format using SDRsharp.

Thanksgiving ATSC Tests

Yesterday I did some more ATSC experiments.

(above) Finally... the elusive WZRB ION channel 47 comes in. On the right edge is WACH Fox 57.

(I'm using the older copy of SDRSharp I mentioned in my previous post)

Since hard drive recording is spotty, I copied SDRSharp to a RAM drive, since it only records to its own program directory. SDRSharp kept setting the SDRPlay's PPM correction to a crazy value and changing it kept locking up the computer.

SoftPerfect RAM Disk also kept locking up when I tried to unmount disks. I would turn it off in Task Manager and restart it from the Start menu. That caused it to forget the RAM it had previously taken and I would have to reboot. I eventually switched to IMDisk and kept working.

Adding to my troubles, when I tried to decode it, I accidentally used the old flowgraph from my previous post, the one that expects 8-bit samples. Of course, my TS file stayed empty, and it took me a while to realize the issue. (Pictured below)

Even after fixing this, I wasn't able to decode WZRB, even though the TV had no trouble. However, I did manage to get a long successful recording of WRLK PBS.

Pictured below is WAGT NBC. As I write this, I can't get it to come in on my TV.

I've seen this kind of fading in other stations, most notable PBS. This picture was taken with my SDRPlay hooked to a rooftop Yagi. For some reason, a few cases of this fading can be cured by using indoor rabbit ears and rotating them until it goes away. Strangely, I've actually had far better results on PBS with indoor rabbit ears than an outdoor Yagi. I don't yet know why certain portions of the station would fade before reaching me, considering that it leaves the transmitter as a uniform distribution of power over the whole 6 MHz. I know that ATSC doesn't work for moving receivers, but I'm not moving, so why would only certain sections fade as opposed to others?

In summary, trying to decode ATSC is more of a hit-and-miss process since it's hard to know if a station will be readable. In several situations, software-based solutions perform better than embedded hardware, as is the case with DRM radio reception. But from what I've seen, if a TV can't receive a station, GNURadio certainly won't. Sometimes even if a TV is perfectly OK with a certain station GNURadio still can't decode it. I wonder if they'll update GNURadio's blocks for better results? In theory you should be able to decode just as well (if not better) in software as you can with a hardware decoder, since you have more control over processing.

ATSC Update 2

I'd like to share three more aspects of ATSC recording you might not be aware of.

First.

In previous posts I stressed the need for high-speed recording media when recording ATSC IQ samples. A few days ago I proved myself wrong.

I was using an older copy of SDRSharp, one that still works with the SDRPlay. SDRSharp has superior DC cancellation functionality, which it labels "IQ Correction."

I used the Baseband recording option at 16-bit sampling and managed to record 44 seconds to a fast magnetic hard drive before dropping samples. The IQ file yielded a perfect decode. You can download the final TS here: 183mhz_decoded.ts.7z. (70 MiB)

You'll probably still need a RAM drive for longer recordings, but this opens up a lot of possibilities. Someone just needs to write a program that will "buffer" writes to a hard drive to smooth out latency. Ideally this would work by registering a virtual drive and creating a RAM buffer, and having two separate threads, one to accept the write requests and store them in RAM, and another to write them when the drive is ready. That way, SDR programs never see the delay in the hard drives.

(Update) I've found a paid program that should do this. It's called PrimoCache and the concept is called deferred write. It costs $29.95 USD and comes with lifetime free upgrades.

Second,

You've probably noticed that most digital channels offer an EPG (Electronic Program Guide.)

I learned that if you open a valid decoded TS file in MediaInfo you can retrieve the EPG, among other things, such as channel resolution and bitrate.

Click here to read a TXT file of MediaInfo's output for the TS file I offer above. The EPG's for each channel are at the bottom.

(Update 11/24/2015) Interestingly, there is a Start and End UTC near the top. MediaInfo can apparently look at the timestamps embedded in TV channels to find the start and end time of the recording. Note that the recording's Start and End span 38 seconds, 6 seconds less than the 44 seconds of IQ data I took. This implies that the syncing (and de-syncing) periods take off 3 seconds at both the beginning and end.

Third,

During the experiment under "First," I also tried taking 8-bit IQ samples, which cut bandwidth and storage requirements in half from 32 to 16 MiB/sec. I was not able to decode this IQ file, but maybe someone else will figure out a way.

Of course, one big advantage of the SDRPlay over the RTL dongle is the 12-bit sampling. and the loss of dynamic range incurred by downsampling to 8 bits might hamper decoding no matter what you do.



As always, feel free to comment below.