Supported devices: USB DVB-T adapters (non-exhaustive list, see here for how to install device driver on Windows):
- The following are the names of some common devices, but others not listed here will work if their USB ID is the same:
- Hama nano
- Terratec Noxon 1 & 2
- Dexatek 1 (also Logilink/MSI)
- Dexatek 2 (also ZAAPA HD)
- Dexatek 3
- Ardata MyVision/Gigabyte GT-U7300
- Terratec Cinergy T 1
- DIKOM HD
- Genius TVGo 2
- Tuners are probed automatically now!
- You can override the tuner too, if you wish:
- Linux: select the appropriate tuner from the list in the GRC block properties
- Windows: add tuner=e4000/fc0012/fc0013/fc2580 to the device hint
- If your device is NOT recognised (missing from device table):
- Linux: type in the VID/PID into the GRC block
- Windows: add vid=0x#### pid=0x#### to device hint
- Code: use the simple API to set these 'USB device override values'
- Source: add one line to the device list in 'rtl2832.cc'
You can contact me with information (name/VID/PID/tuner type) regarding other devices that are not recognised automatically.
- Cross-platform source code: librtl2832++ is the C++ interface that abstracts the functionality of the hardware (demod & tuner). It compiles:
- as a DLL on Windows
- directly into the gr-baz baz module for GNU Radio
- You can freely take the rtl2832-* files from the lib directory out and re-use them in any other project where you need to control an RTL2832-based device!
|ADC Resolution||8 bits|
|Dynamic range|| (Not that great - theoretically 48 dB?, but still enough for many applications.)
This can be improved by:
|Minimum sample rate||> 900 ksps (must be greater!)|
|Maximum sample rate||3.2 Msps|
|Nominal sample rate||1 Msps (much higher leads to subtle signal degradation)|
|Clock||28.8 MHz internal oscillator (expect large drift and phase noise)|
|Spectrum flatness||(Definitely not flat at centre, worse with low gain)|
|AGC|| Disabled for E4000, but still active somewhere (in RTL2832 demod chip itself?)
You can test this by tuning a strong carrier to be near/on the centre frequency.
If you know about this, please tell me.
|Sensitivity||TBD (decent all things considered)|
|Quality||Don't expect anything remotely close to a USRP.|
|Price||For ~$20 you'd be crazy not to try it!|
- Disabled E4000 DC offset loop to avoid period 'jumps' in time-domain signal: I have disabled the DC offset loop in the E4000 tuner as I was seeing additional crud on the right of the centre frequency. In the time-domain, you can see it as a period jump in the incoming signal. I'll add an option to re-enable it so you can experiment (or you can modify the E4000 init function and un-comment the function call).
- I2C errors when tuning rapidly: personally I haven't had this problem, except when using a GRC flowgraph where the down-stream sample rates are mismatched. However, other people have reported this in normal use. Therefore this issue is as yet unresolved, as perhaps because the device wasn't designed to be rapidly re-tuned. One option is rate-limiting tune requests and/or investigating async control transfers in libusb.
- I2C failure when tuning certain frequencies on E4000: For example, on both Windows and Linux if you tune to 90 MHz, then 89 MHz then back to 90 Mhz, you will see:
_I2CWriteByte: the control request was not supported by the device [-9] @ int PLL(rtl2832::tuner*, int, int):1749 "I2CReadByte(pTuner, 200, 5, writearray)"
- If you inspect the referenced E4000 PLL function, you will see an if blocks that set various registers depending on the requested tune frequency - this may hold the key. Otherwise, any other theories are welcome!