Linrad with rtlsdr with and the e4000 tuner.
Hello, This mail is sent to all the E-mail addresses I have found in the source code of tuner_e4k.c and librtlsdr.c I have made a couple of modifications to the software and I now want to ask whether you can make changes to the standard package that you supply so Linrad users will not have to download modified files from my site to get proper operation of Linrad in the future. The most important modification is the gain setting. The tuner code requires knowledge of the gain table or searcing for legal gain values by use of the returned error code. I think that this is impractical and I changed it so the routine will now always set the nearest possible gain value and return it to the caller. The routine e4k_set_enh_gain(...) does not affect the gain of my hardware so I allow the gain setting function to use it with always the same value because I have no idea what this function is intended to do.... The default IF gain is too high. I reduced it by 6dB for a 6 dB better dynamic range. With the tuner_e4k.c currently incorporated in Linrad there is an AGC action that degrades the dynamic range by about 10 dB. I do not know anything about the e4000 internals but in case this remaining AGC can be disabled and the gain set 10 dB lower in the particular gain step controlled by the AGC, the dynamic range would improve from 66 dB to 76 dB with respect to the usual MDS (noise in 500 Hz bandwidth.) That means going from outside the scale in the QST "Key Measurements Summary" in their product testing to a mediocre result 6 dB above the limit of the range they have for SSB radios. The rtlsdr would be superior to hand held units like TH-D72A or VX-8GR in adjacent channel rejection (QST July 2011 and September 2011) if the AGC could be disabled. The details are here: http://www.sm5bsz.com/linuxdsp/hware/rtlsdr/rtlsdr.htm The Extio_RTLSDR.dll file provides 6 dB worse dynamic range because of the high IF gain setting. It also has a poor noise figure. -------------------------------------------------------------- To be able to use the callback in Linrad I have had to include various structures in the Linrad c code. I need to have this code in Linrad: i = libusb_handle_events_timeout(dev_rtlsdr->ctx, &tv1); Therefore I need the structure rtlsdr_dev which is not included in rtl-sdr.h. That structure requires other structures and it would be a good thing if those things as well as something like this: #define MAX_RTL2832_SAMP_RATE 3200000 #define MIN_RTL2832_SAMP_RATE 900001 were included in rtl-sdr.h I attach the Linrad interface routine to rtlsdr in case any of you are interested to see how I use the library. I realize the chip is far more clever and that I do not use it well. There is a substantial DC offset that seems to be possible to auto-remove. The AGC I want to get rid of might be something related to: /* disable auto mixer gain */ e4k_reg_set_mask(e4k, E4K_REG_AGC7, E4K_AGC7_MIX_GAIN_AUTO, 0); Hard to know without any documentation on the chip.... 73 Leif / SM5BSZ
Hi Leif, On 22.06.2012 21:55, Leif Asbrink wrote:
The most important modification is the gain setting. The tuner code requires knowledge of the gain table or searcing for legal gain values by use of the returned error code. I think that this is impractical and I changed it so the routine will now always set the nearest possible gain value and return it to the caller.
That's exactly what we have rtlsdr_get_tuner_gains() for.
The routine e4k_set_enh_gain(...) does not affect the gain of my hardware so I allow the gain setting function to use it with always the same value because I have no idea what this function is intended to do....
Enhanced gain works only when both LNA and mixer gains are set to maximum, take a look at e4000_set_gain() in librtlsdr.c. Also be sure to enable the manual gain mode with the library function rtlsdr_set_tuner_gain_mode().
The default IF gain is too high. I reduced it by 6dB for a 6 dB better dynamic range.
We still have to add functions to set the IF-gain from external applications, this is something on the todo-list.
With the tuner_e4k.c currently incorporated in Linrad there is an AGC action that degrades the dynamic range by about 10 dB. I do not know anything about the e4000 internals but in case this remaining AGC can be disabled and the gain set 10 dB lower in the particular gain step controlled by the AGC, the dynamic range would improve from 66 dB to 76 dB with respect to the usual MDS (noise in 500 Hz bandwidth.)
The remaining AGC that's active is not in the E4K, but it's the Digital AGC (DAGC) of the RTL2832. Unfortunately we don't know how to disable it, since the way it's supposed to be disabled does not work.
To be able to use the callback in Linrad I have had to include various structures in the Linrad c code. I need to have this code in Linrad: i = libusb_handle_events_timeout(dev_rtlsdr->ctx, &tv1); Therefore I need the structure rtlsdr_dev which is not included in rtl-sdr.h. That structure requires other structures and it would be a good thing if those things as well as something
I don't really know why you're doing that... the way the asynchronous callback is meant to be used is spawning a thread and calling rtlsdr_read_async() from there. Just take a look at how gr-osmosdr or rtl_tcp handles it. Another example of correct usage is sdrsharp [1]. Regards, Steve [1] https://www.assembla.com/code/sdrsharp/subversion/nodes/trunk/RTLSDR/RtlDevi...
Hello Steve,
On 22.06.2012 21:55, Leif Asbrink wrote:
The most important modification is the gain setting. The tuner code requires knowledge of the gain table or searcing for legal gain values by use of the returned error code. I think that this is impractical and I changed it so the routine will now always set the nearest possible gain value and return it to the caller.
That's exactly what we have rtlsdr_get_tuner_gains() for. Good:-) I overlooked that and I will use it for the next Linrad version.
The default IF gain is too high. I reduced it by 6dB for a 6 dB better dynamic range.
We still have to add functions to set the IF-gain from external applications, this is something on the todo-list. OK. Do you have an idea about the time scale? It would be a good thing from my perspective if this would be implemented before I release the next Linrad version. The lower IF gain is a significant improvement on 144 MHz. I do not know anything about the design so I do not know whether one should set IF gain differently on other frequencies.
With the tuner_e4k.c currently incorporated in Linrad there is an AGC action that degrades the dynamic range by about 10 dB. I do not know anything about the e4000 internals but in case this remaining AGC can be disabled and the gain set 10 dB lower in the particular gain step controlled by the AGC, the dynamic range would improve from 66 dB to 76 dB with respect to the usual MDS (noise in 500 Hz bandwidth.)
The remaining AGC that's active is not in the E4K, but it's the Digital AGC (DAGC) of the RTL2832. Unfortunately we don't know how to disable it, since the way it's supposed to be disabled does not work. That is bad news:-(
Is there by any chance a way to reduce the sensitivity of the RTL2832? Something that would place the AGC onset at a point higher above the noise floor.
To be able to use the callback in Linrad I have had to include various structures in the Linrad c code. I need to have this code in Linrad: i = libusb_handle_events_timeout(dev_rtlsdr->ctx, &tv1); Therefore I need the structure rtlsdr_dev which is not included in rtl-sdr.h. That structure requires other structures and it would be a good thing if those things as well as something
I don't really know why you're doing that... the way the asynchronous callback is meant to be used is spawning a thread and calling rtlsdr_read_async() from there. Just take a look at how gr-osmosdr or rtl_tcp handles it. Another example of correct usage is sdrsharp [1]. I did it because that is the way I used to do....
I will check the timing of the conventional approach and switch to it if the difference is insignificant. I have tested the ExtIO_RTLSDR.dll which I assume is written by the book. It works fine on modern computers, even on less modern ones like a 2.4 GHz Pentium 4 but it fails on Pentium 3 with bad cpu overload (Win XP). The Linrad code runs fine at 2 MHz sampling speed on my old Pentium 3 at 650 MHz. (under Linux X11, 2.6.32 kernel) The cpu load is 80% and there are no glitches or other problems. The parameters are exactly the same that fail badly with the ExtIO dll on the same computer. The difference is most probably not due to Windows itself, it is the USB interface that is more demanding. Significantly more! Regards Leif / SM5BSZ
Hej Leif! Leif Asbrink wrote:
it is the USB interface that is more demanding. Significantly more!
Depends on how the software in the device and on the host is written. USB per se is not demanding, rather the opposite, as the host controller does DMA. A device which makes poor use of USB primitives will of course have poor performance. A host software which makes poor use of USB primitives will also have poor performance. What freedom the host software has is largely determined by the device, but of course it's always possible to write bad software.. I didn't look at the ExtIO_RTLSDR source code, so I can't say if it is doing efficient USB communication or not. Where is the source? Kind regards //Peter
Hello Steve,
We still have to add functions to set the IF-gain from external applications, this is something on the todo-list. OK. Do you have an idea about the time scale? It would be a good thing from my perspective if this would be implemented before I release the next Linrad version. Since there was no response on this I have released a new version of Linrad with new versions of rtlsdr.c and tuner_e4k.c to go with it.
Performance is now quite good. The noise figure is 7 dB with a dynamic range of about 74 dB (saturation vd MDS in 500 Hz.) When gain is reduced for a noise figure of 10 dB the dynamic range is 80 dB, 6 dB below the theoretical limit. http://www.sm5bsz.com/linuxdsp/hware/rtlsdr/rtlsdr.htm The gain setting is clumsy, I just added some things that seem similar to the existing routines. It seems to me that a new approach would be desireable. If one wants to set the gain of the E4000 chip by use of a single parameter one has to use some of theIF gain controls as well as the mixer gain and the lna gain. I have not been able to see any effect of the enhanced gain. I tried various bits blindly and found a setting that eliminates the AGC in the RTL2832 chip. That is a significant part of the performance improvement. Today the rtlsdr with Linrad under Linux is not a toy. It is a surprisingly good SDR receiver (in relation to cost.) Performance is about 20 dB below what we find in standard transceivers like IC706MKIIG and others. I do not know how to proceed. I see two options: 1) librtlsdr is rewritten with a gain setting routine that operates on lna, IF and mixer gains in a way that optimizes performance. 2) I will provide a Linrad specific library that supports only the RTL2832/E4000 combination. I expect the simple change required to disable AGC in RTL2832 to be implemented pretty soon. Hopefully ExtIO_RTLSDR.dll and SDRSharp will soon be updated to remove the AGC. A gain setting function would surely make these softwares far more useful. I think the best way of setting the e4k gain would be to place a matrix in tuner_e4k.c with as many rows as the number of stages that we want to use for gain setting and as many columns at the number of different nominal gains ẅe want to supply. That would be a lot of code to remove and not much to add - but I do not wish to take desicions for osmocom. Linrad-04.40 still uses its own callback and I may have to supply source code for todays version of tlsdr to go with it. In case the standard library from osmocom implements AGC off and a sensible routine for manual gain control I will adapt Linrad to the standard library. Regards Leif / SM5BSZ
I changed the numbers to get a reasonable agreement with the gain values I observed on the dongles I have. I did not care to match the gain setting to the real gain better than within 3 dB (the gain step size in Linrad.) The reason is that I assume that the routines from osmocom will be changed and that other softwares that support rtl dongles will allow gain setting in a reasonable way and that the performance will become similar to the current Linrad performance. When that happens I will rewrite Linrad to use the library as intended. I see two alternatives, there could be lna gain as well as IF gain as separate controls. The other alternative would be a single gain control, but in that case both lna and if gain have to be controlled. The first few gain reduction steps have to be on the IF because the most common problem is close range interference and the improved dynamic range is useful. (In case the lna gets blocked one should install a filter.) Regards Leif / SM5BSZ On Thu, 05 Jul 2012 02:06:31 +0200 la@tfc-server.de wrote:
The gain setting is clumsy If it only was your gain setting function, but no, even your gain values for the lna are just plain wrong. I just have to ask: Why? What made you "improve" them?
I assume everyone involved in constructing the Control Code for the Tuner Dongles started out by recording the I2C stream on the Dongle coming from the Original Dongle Software that comes with the Dongle for watching TV and FM Radio. -----Original Message----- From: osmocom-sdr-bounces@lists.osmocom.org [mailto:osmocom-sdr-bounces@lists.osmocom.org] On Behalf Of Leif Asbrink Sent: Thursday, July 05, 2012 6:27 AM To: osmocom-sdr@lists.osmocom.org Subject: Re: Linrad with rtlsdr with and the e4000 tuner. I changed the numbers to get a reasonable agreement with the gain values I observed on the dongles I have. I did not care to match the gain setting to the real gain better than within 3 dB (the gain step size in Linrad.) The reason is that I assume that the routines from osmocom will be changed and that other softwares that support rtl dongles will allow gain setting in a reasonable way and that the performance will become similar to the current Linrad performance. When that happens I will rewrite Linrad to use the library as intended. I see two alternatives, there could be lna gain as well as IF gain as separate controls. The other alternative would be a single gain control, but in that case both lna and if gain have to be controlled. The first few gain reduction steps have to be on the IF because the most common problem is close range interference and the improved dynamic range is useful. (In case the lna gets blocked one should install a filter.) Regards Leif / SM5BSZ On Thu, 05 Jul 2012 02:06:31 +0200 la@tfc-server.de wrote:
The gain setting is clumsy If it only was your gain setting function, but no, even your gain values for the lna are just plain wrong. I just have to ask: Why? What made you "improve" them?
Hello Jay, The e4k chip has many registers. For example the function e4k_manual_dc_offset() changes the way the if gain settings work. There could also be something that affects the lna gain. The purpose of the changed code that I made available is to allow rtlsdr users to have the full performance of the RTL2832/E4000 dongles NOW. Today. I do not have access to any data for the chips. Performance is reasonably close to the theoretical limit and all AGC functions are disabled so it is now a good radio with Linrad. The function e4k_manual_dc_offset() is named in a way that suggests one can change the DC offset on the output from I and Q. Pointless, at least with the dongle I have because the E4000 is AC-coupled to the RTL2832. (I checked with an oscilloscope.) Regards Leif / SM5BSZ On Thu, 5 Jul 2012 08:06:11 -0500 "Jay Salsburg" <jsalsburg@bellsouth.net> wrote:
I assume everyone involved in constructing the Control Code for the Tuner Dongles started out by recording the I2C stream on the Dongle coming from the Original Dongle Software that comes with the Dongle for watching TV and FM Radio.
-----Original Message----- From: osmocom-sdr-bounces@lists.osmocom.org [mailto:osmocom-sdr-bounces@lists.osmocom.org] On Behalf Of Leif Asbrink Sent: Thursday, July 05, 2012 6:27 AM To: osmocom-sdr@lists.osmocom.org Subject: Re: Linrad with rtlsdr with and the e4000 tuner.
I changed the numbers to get a reasonable agreement with the gain values I observed on the dongles I have.
I did not care to match the gain setting to the real gain better than within 3 dB (the gain step size in Linrad.) The reason is that I assume that the routines from osmocom will be changed and that other softwares that support rtl dongles will allow gain setting in a reasonable way and that the performance will become similar to the current Linrad performance. When that happens I will rewrite Linrad to use the library as intended.
I see two alternatives, there could be lna gain as well as IF gain as separate controls.
The other alternative would be a single gain control, but in that case both lna and if gain have to be controlled. The first few gain reduction steps have to be on the IF because the most common problem is close range interference and the improved dynamic range is useful. (In case the lna gets blocked one should install a filter.)
Regards
Leif / SM5BSZ
On Thu, 05 Jul 2012 02:06:31 +0200 la@tfc-server.de wrote:
The gain setting is clumsy If it only was your gain setting function, but no, even your gain values for the lna are just plain wrong. I just have to ask: Why? What made you "improve" them?
I assume everyone involved in constructing the Control Code for the Tuner Dongles started out by recording the I2C stream on the Dongle coming from the Original Dongle Software that comes with the Dongle for watching TV and FM Radio.
As far as the e4k is concerned: We're currently using the OsmoSDR driver which was written by people who have access to the e4k datasheet, this driver predates rtlsdr by quite a bit, and I'd dare to say that it is unwise to modify constants used by it unless your datasheet disagrees with ours. Unfortunately there is very little known about the other tuners, so their code is mostly just modified v4l code.
Hello, I've played around with your code and also had a look into the linux kernel driver which contains some elonics code [1]. There the LNA gains have an offset of 3dB compared with rtl-sdr. In the rtl-sdr header is also a constant defined but not used, to switch to 5dB gain steps. I'm wondering how this fit's with your observations. I've read your blog entry and would like to evaluate the gain values of my device, but it is not clear to me what equipment is needed - I assume at least a 144 MHz oscillator with defined level. Regarding your changes to the gain setting function, fear they contain lots of bugs, but I agree it would be nice to have a function which make IF-gain setting easier. The elonics code also contains a more stuff to configure the auto gain. Maybe this is interesting for rtl-sdr too. Regards Stefan [1] https://github.com/tmair/DVB-Realtek-RTL2832U-2.2.2-10tuner-mod_kernel-3.0.0... Am 05.07.2012 13:27, schrieb Leif Asbrink:
I changed the numbers to get a reasonable agreement with the gain values I observed on the dongles I have.
I did not care to match the gain setting to the real gain better than within 3 dB (the gain step size in Linrad.) The reason is that I assume that the routines from osmocom will be changed and that other softwares that support rtl dongles will allow gain setting in a reasonable way and that the performance will become similar to the current Linrad performance. When that happens I will rewrite Linrad to use the library as intended.
I see two alternatives, there could be lna gain as well as IF gain as separate controls.
The other alternative would be a single gain control, but in that case both lna and if gain have to be controlled. The first few gain reduction steps have to be on the IF because the most common problem is close range interference and the improved dynamic range is useful. (In case the lna gets blocked one should install a filter.)
Regards
Leif / SM5BSZ
On Thu, 05 Jul 2012 02:06:31 +0200 la@tfc-server.de wrote:
The gain setting is clumsy If it only was your gain setting function, but no, even your gain values for the lna are just plain wrong. I just have to ask: Why? What made you "improve" them?
Hello Stefan,
I've played around with your code and also had a look into the linux kernel driver which contains some elonics code [1].
There the LNA gains have an offset of 3dB compared with rtl-sdr. The absolute gain is insignificant. The dongle will convert an RF voltage to A/D converter bits and the number of mV per bit will change if there is an offset on gain values. I can not see that one is better than the other. Those who know the internals of the chip might want to set the scale offsets correctly because the different stages may actually have gain or cause attenuation. Such a strategy is not unambigous however. When the impedance level is changed we have to know whether dB refers to a power ratio or a voltage ratio.
In the rtl-sdr header is also a constant defined but not used, to switch to 5dB gain steps. I'm wondering how this fit's with your observations. I have no idea.
I've read your blog entry and would like to evaluate the gain values of my device, but it is not clear to me what equipment is needed - I assume at least a 144 MHz oscillator with defined level. You just need a signal that is stable in amplitude. Could be your local FM station or any signal generator in the range 55 to 1000 MHz. Probably higher, but I do not have generators above 1 GHz easy at hand so I have not verified that.
Regarding your changes to the gain setting function, fear they contain lots of bugs, but I agree it would be nice to have a function which make IF-gain setting easier. Not bugs, but clumsy code. I tried to not change more than necessary...
The elonics code also contains a more stuff to configure the auto gain. Maybe this is interesting for rtl-sdr too. In general purpose SDR we do not want any kind of auto gain.
Those who want to use the builtin decoders have a different situation. Regards Leif / SM5BSZ
Regards
Stefan
[1] https://github.com/tmair/DVB-Realtek-RTL2832U-2.2.2-10tuner-mod_kernel-3.0.0...
Am 05.07.2012 13:27, schrieb Leif Asbrink:
I changed the numbers to get a reasonable agreement with the gain values I observed on the dongles I have.
I did not care to match the gain setting to the real gain better than within 3 dB (the gain step size in Linrad.) The reason is that I assume that the routines from osmocom will be changed and that other softwares that support rtl dongles will allow gain setting in a reasonable way and that the performance will become similar to the current Linrad performance. When that happens I will rewrite Linrad to use the library as intended.
I see two alternatives, there could be lna gain as well as IF gain as separate controls.
The other alternative would be a single gain control, but in that case both lna and if gain have to be controlled. The first few gain reduction steps have to be on the IF because the most common problem is close range interference and the improved dynamic range is useful. (In case the lna gets blocked one should install a filter.)
Regards
Leif / SM5BSZ
On Thu, 05 Jul 2012 02:06:31 +0200 la@tfc-server.de wrote:
The gain setting is clumsy If it only was your gain setting function, but no, even your gain values for the lna are just plain wrong. I just have to ask: Why? What made you "improve" them?
Hello Steve,
The most important modification is the gain setting. The tuner code requires knowledge of the gain table or searcing for legal gain values by use of the returned error code. I think that this is impractical and I changed it so the routine will now always set the nearest possible gain value and return it to the caller.
That's exactly what we have rtlsdr_get_tuner_gains() for.
I have implemented the proper way of calling the original gain routine. Here is what I observe with rtlsdr as downloaded today: Set gain Signal level (dB) (dB) 49 49 47 49 45 49 43 49 42 49 34 42 29 42 24 37 21.5 35 19 32 16.5 28.5 14 27.5 11.5 24 9 22 6.5 19.5 4 17 1.5 13.5 -1 12 This does not look good. I have used a dongle bought here: http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item=260995356948 I have two of them and they behave the same. In Linrad with modified code for the rtlsdr library it looks like this: Set gain Signal level (dB) (dB) 36 36 33 31 30 28.5 27 25.5 24 21.5 21 20 18 16 15 14.5 12 11 9 9 6 3 3 1 0 -4.5 At maximum gain the noise figúre is 7.8 dB in both cases at 144 MHz. The dynamic range (1 dB compression) is 14 dB better with the modified code for Linrad. (lower IF gain.) It is a VERY significant improvement. Is there a way to get technical specifications for the chips used in the dongle? Regards Leif / SM5BSZ
participants (6)
-
Jay Salsburg -
la＠tfc-server.de -
Leif Asbrink -
Peter Stuge -
Stefan Sydow -
Steve Markgraf