Total Pageviews

Tuesday, 12 December 2017

NOS (former TV Cabo) finally released their DVB-C bouquet in FTA!

Yesterday I received some good news for a change! I got an e-mail from NOS, who are better known as "TV Cabo", telling me that my TV could now render more than 110 channels.

After a quick reading, the issue was crystal clear: NOS has come to senses and removed their encryption on the base bouquet! This means that any TV equipped with a DVB-C tuner will be able to show all 110 channels of the base bouquet.

Before, you needed to rent an official NOS DVB-C receiver, but you could only have up to three and they cost extra money, of course. Well in a home like mine, we have 5+ permanent TV sets installed (not to mention my shack, which has at least another TV, if not more).

I always wondered why they would encrypt ALL their DVB-C channels (except a few international channels, which are FTA on satellite - I think for DRM reasons NOS had to keep them FTA when retransmitting them in their network).

Here are two pictures grabbed from my Emitor Megalook, which I managed to repair after studying the fault over 4 months... More info about that journey at EEV-Blog: http://www.eevblog.com/forum/repair/attempting-repair-of-tv-tuner/


The complete CATV spectrum as used by NOS

Constellation diagram of transponder at 354MHz, using QAM256

Here is the channel list for PORTO area:
  • 121500 kHz QAM256 SR6.000 kBaud/s
  • 184500 kHz QAM128 SR6.000 kBaud/s
  • 170500 kHz QAM256 SR6.000 kBaud/s
  • 219500 kHz QAM256 SR6.000 kBaud/s
  • 240500 kHz QAM256 SR6.000 kBaud/s
  • 247500 kHz QAM128 SR6.000 kBaud/s
  • 254500 kHz QAM256 SR6.000 kBaud/s
  • 261500 kHz QAM256 SR6.000 kBaud/s
  • 306000 kHz QAM256 SR6.875 kBaud/s
  • 314000 kHz QAM256 SR6.875 kBaud/s
  • 322000 kHz QAM256 SR6.875 kBaud/s
  • 330000 kHz QAM256 SR6.875 kBaud/s
  • 354000 kHz QAM256 SR6.875 kBaud/s
  • 362000 kHz QAM256 SR6.875 kBaud/s
  • 386000 kHz QAM256 SR6.875 kBaud/s
  • 426000 kHz QAM256 SR6.875 kBaud/s
  • 474000 kHz QAM256 SR6.875 kBaud/s
  • 490000 kHz QAM256 SR6.875 kBaud/s
  • 562000 kHz QAM128 SR6.875 kBaud/s
  • 570000 kHz QAM128 SR6.875 kBaud/s
  • 602000 kHz QAM256 SR6.875 kBaud/s
  • 626000 kHz QAM128 SR6.875 kBaud/s
  • 634000 kHz QAM128 SR6.875 kBaud/s
  • 658000 kHz QAM256 SR6.875 kBaud/s
  • 674000 kHz QAM256 SR6.875 kBaud/s
  • 690000 kHz QAM256 SR6.875 kBaud/s
  • 714000 kHz QAM64  SR6.875 kBaud/s
It is now debatable if it wouldn't have been a better choice to distribute these channels with DVB-T modulation, instead, as the required DVB-T receivers are more common and cheaper (thanks to the TDT - "Terrestrial Digital Television"). But that would of course mean a significant investment for NOS, to change all equipment.

So at the end of the day, yes, I am happy. No more noisy analogue pictures, welcome to the digital TV on ALL screens of the house.

The final question is: Will NOS keep the analogue channels? Or will they be shut off after a given transition period? What would the free frequency ranges be used for?

Regards,
Vitor


Monday, 4 December 2017

Teaser: VMA Simple Spectrum Analyzer for HackRF One

Hi,

As you know, I am a spectrum freak. There are two implementations already for the HackRF One:
  • qspectrumanalyzer - works well under Linux, but crashes right away under Windows
  • hackrf-spectrum-analyzer - works on Windows, but crasshes frequently when changing settings
Both are fairly limited in terms of functionality, but they show something impressive: the HackRF One is capabale to show a very high resolution spectrum over the whole supported frequency range (1MHz-6GHz). And the speed is incredible!

This motivated me to do a preliminary hack to see if the HackRF One could be used with my VMA Simple Spectrum Analyser software and the results are very promising:

Live spectrum (10MHz to 1000MHz)

Average Trace

Live, Min and Max Traces

Solid render of Live Trace

3D spectrum mode

The implementation is totally hacked and with errors:

  • I am not reading out the data correctly and there is some unfixed bug, which is why there is a blank on the right side of the spectrum in the above images
  • The frequency values are wrong
  • The frequency range cannot be set, nor can any other setting, as I have not implemented the protocol, yet

However, all other measurement functionality works and speed is fantastic! This could be a dream come true.

But there is a LOT of work required to get this to work and sadly I won't be able to manage it by myself.

First things first - the TODO list:
  • Better understand the hackrf_sweep protocol
  • Implement correct start/end frequency setting
  • Implement correct bin_width setting (FFT frequency resolution)
  • Implement num_samples setting (number of samples per frequency)
  • Implement interpretation of sweep output
  • Implement way to change current start/end frequency and other parameters (*)
(*) This is the crucial part: as it is, the hackrf_sweep.exe needs to be stopped with CTRL+C and restarted with new settings. This is not ideal, as it causes a significant pause.

Worse than that, under Windows, every CTRL+C crashes the HackRF One and a resume requires to press the physical RESET button.

Instead of having a hackrf_sweep.exe tool running in a shell outputting the sweep data to the console (from where I am reading it right now), I would prefer a TCP/IP communication to receive the sweep data and to send any new setting.

Unfortunately this requires to change the C++ sources of the hackrf_tools, something I am not literate to do.

If you know how to program VC++ and are interested in this project, please contact me!

Regards,
Vitor



Friday, 24 November 2017

Using HackRF One and GNU Radio on Windows 10

Hi,

So finally I got my very own HackRF One!


While I was waiting for the order to arrive, I started to learn about how to use the HackRF One and all instructions I found online pointed to one basic fact: you need to have Linux to fully use the HackRF One.

The problem is that I currently have only Windows 10 installed on my computers, because most programs I use, are only available for this operating system.

For the casual Linux use, I droped having a dedicated Linux partition and instead started to use Ubuntu inside a virtual machine. Using the free VirtualBox has been a great experience, as it works really well.

However, I discovered that for HackRF One, the bandwidth of the virtual USB port is simply not enough. While you can in fact use the HackRF inside a virtual Linux box, performance is not ideal. It does work, but don't expect to TX/RX the full 20MHz.

I tried my luck with Pentoo, a Linux distribution on DVD that has everything radio related pre-installed. It does work, but again there was a slight annoyance: I am used to my SSD, which is really fast and I use three monitors to have plenty of desktop space. With Pengoo, everything loads from DVD and that is really slow! Also, all three monitors show the same content with a lower resolution that would be possible.

And so I ended up giving GNU Radio for Windows a shot and guess what: it works actually amazingly well!

How to set it up? Look here: https://wiki.gnuradio.org/index.php/WindowsInstall

And yes, you get FULL HackRF One support, commands like "hackrf_transfer" are available and work.



I did a first test with my new HackRF One and this image shows the capture of a few seconds of just 2MHz:


Soon I ended up recording 20MHz bandwidth (basically the whole FM band in one go) and then transmitted it at 160MHz centre frequency... Why? Because I can!


The spectrum analyzer shows how it looks like...


...and my Uniden Bearcat UBC9000XLT could perfectly receive the relayed FM stations! Simply amazing!


Now I need to learn more about GNU Radio - it is an amazing piece of software!

So here is a prrof of concept that you can use the HackRF One with Windows, as opposed to basically all quick start instructions I have found.

Cheers,
Vitor

Saturday, 4 November 2017

Hacking the Schwaiger SPG101 into an analogue satellite modulator

Hi,

Last year I posted about a curious device, the Schwaiger SPG101 "LNB tester":



I finished my review with the thought that it should be easy to hack this device, to show a composite image instead of the test image with a grid.

Well, today I had some free time and so I finally looked at how to hack this device. I found the trace that transports the video signal from the generator and I interrupted it. Three wires were quickly soldered: one with the generated grid video signal before the trace interruption, one wire from a chinch connector I fitted to the case and a third soldered right after the trace interruption.

The idea is to switch between the external composite video input on the chinch connector and the internal video generator.

The results are promising, but not perfect:

There is a nice spot on the case, where a CHINCH connector fits in nicely!

Just place the modified SPG101 somewhere near the LNB.

 Tune the Satlook Digital Color to 11.288MHz.

And look at the video in analogue mode.
This is the original test pattern produced by the internal ZNZ234E.

Changing the jumpers and feeding some composite video on the CHINCH connector, we get a "real" satellite transponder on 11.228MHz. Best of all: it is in colour!

The problem is that the video signal from the generator is still visible over the external composite video signal. Just interrupting the trace is not enough. Because there is no space left for better shielding, I decided to cut another trace: the trace that powers the ZNA234E video pattern generator. Vcc is on pin 7, but naturally I got it wrong in the first attempt and cut the trace of the CROSS HATCH output on pin 14...

So I had to retrace that one, first. No harm done, as I am considering getting a switchable knob with 5 positions, since this video pattern generator can actually produce horizontal lines, vertical lines, grid, dots and a gray scale!


Because I did not have any switches at hand, for now I used two jumpers: one is to select between external or internal video, the other powers the pattern generator on or off.

Hopefully I can find a suitable switch to replace these two jumpers.

Now I can not only test if an LNB is working, I can actually broadcast video on 11.288MHz!


This is useful to test analogue SAT receivers, prior to modding them for ATV use. Another application is to test and/or review satellite field meters which still have an analogue mode, like my Satlook Digital Color.

Cheers,
Vitor

Saturday, 21 October 2017

Can it be real: A DVB-S modulator and transmitter each for under 25 Euro?

Hi,

A DVB-S modulator and transmitter for under 25 Euro?

A DVB-S receiver and demodulator for under 25 Euro?

See this video and find out:


You need:

  1. Raspberry Pi
  2. RTL2832U dongle
That's all!

Does it work great?

No. If you want an amazing modulator for your tests, this is what you need:


Is it amazing?

Hell yes. I learned a lot trying to get it to work!

Cheers,
Vitor


Friday, 20 October 2017

Why not use a RTL2832U dongle for a faster spectrum refresh rate?

Hi,

The RTL2832U dongles are very popular for a cheap entry to SDR (Software Defined Radio).

People who used SDR# (sdrsharp), are amazed by the super fast beyond real time refresh rate of the spectrum - not to mention the high resolution!

Why not use such an SDR dongle as a spectrum analyser? What is the advantage of the SMA/NWT devices?

Well, first off, some quick explanation: the cheap RTL2832U SDR dongles will digitize 2.4MSPS (Mega Samples per Second) and then perform a Fast Fourrier Transformation (FFT) to convert the discrete samples obtained in TIME DOMAIN (signal level in time) into FREQUENCY DOMAIN (signal level in frequency). Because 2.4MSPS are used, this will allow for a span of aproximately 2MHz.

The SMA/NWT devices, however, will capture samples across the frequency range specified, efectively sweeping the band, which is why they are SSA (Sweep Spectrum Analysers) - well sort of, as they are much simpler than "real" spectrum analyser.

Anyway, they manage to get 500 samples in 1-2 seconds. Considering that you can well display a span of 1GHz in 500 pixels, this gives a refresh rate of 1-2 frames per second.

Now, I am surely not the first who thought about using the FFT in 2MHz steps to eventually conver a broader span.

This is what you can do with QSPectrumAnalyzer, a Linux implementation for SDR devices.

Here is the result:


Note that each screen refresh takes about 70 seconds! The reason is fairly simple: a 1GHz range requires 500 2MHz steps for the FFT operation - there goes the fantastic speed...

Here the same signal rendered with the SMA/NWT device using my software:


In this case, the screen refresh takes around 1 second!

My intention is by no means to bash the RTL2832U devices - I love them! I just wanted to explain the difference.

Some notes of interest:

  1. If you look closely at the first image, you will notice that I use Ubuntu with a VirtualBox virtual machine under Windows 10 and it sees the RTL2832U dongle just fine!
  2. Don't buy the cheapest RTL2832U dongles you can find on eBay. Some will suffer from frequent crashes, which will really take any fun of using them.
  3. I just bought the NooElec Smart Premium.It is reasonably priced (around 25 $/£/€) and features a propper design.
  4. The first stop for any RTL-SDR related information is of course: https://www.rtl-sdr.com/
  5. Need some guidance for RTL-SDR under Linux? Look here: https://ranous.wordpress.com/rtl-sdr4linux/
Cheers,
Vitor

Sunday, 15 October 2017

VMA Simple Spectrum Analyser: How to remove the Google Maps warning on the "Log on Maps" function

Hi,

Perhaps you may have noticed that some time ago Google Maps started to complain about the no longer supported browser version when using the "Log on Maps" function.

If you have no complaints - ignore the rest of this message!

This is what pops up (sorry for the Portuguese message - I am using a Portuguese Windows 10 version, but you certainly get the idea):


Though you can click away this message for now, it is annoying and it was worrying me that one day it would no longer work. So I tried to understand what was going on.

The answer is simple: my software uses the browser control provided by Visual Studio. It will emulate by default an old Internet Explorer version and Google Maps correctly flagged this version as not secure anymore.

The fix consists in adding a new entry to the Registry, telling the Browser Control to emulate the latest Microsoft Internet Explorer 11 browser:



  1. Open regedit.exe
  2. Go to: Computer\HKEY_CURRENT_USER\Software\Microsoft\Internet Explorer\Main\FeatureControl\FEATURE_BROWSER_EMULATION
  3. Add a new DWORD and name it "VMA Simple Spectrum Analyser.exe"
  4. Set its value to "11000" in decimal mode
  5. Restart the the VMA Simple Spectrum Analyser application
That's it!

Atrernatively, you can copy the following green text to Notepad and save it with any name and the *.reg file extention (i.e. "vma.reg"):


Windows Registry Editor Version 5.00

[HKEY_CURRENT_USER\Software\Microsoft\Internet Explorer\Main\FeatureControl\FEATURE_BROWSER_EMULATION]
"VMA Simple Spectrum Analyser.exe"=dword:00002af8


Then double-click on the file and allow importing it to the Registry.

The "Log on Maps" function should now run again without any warning message.


Regards,
Vitor