osmocom-sdr

osmocom-sdr@lists.osmocom.org

1 participants
912 discussions

Start a nNew thread

sdr# version rtlsdr
by Ingo.Wolf＠gmx.de 14 Aug '19

14 Aug '19

2 1

rtl_tcp update
by Richard Frye 29 Jul '19

29 Jul '19

I have enabled the direct sampling option to the rtl_tcp. I would like to submit it as a PR but I need authorization. How do we get authorization? Thanks, Richard Frye

1 0

Re: usbfs zerocopy broken on ARM/ARM64
by Nuno Gonçalves 25 Jul '19

25 Jul '19

Dear Steve, Could you give a note if there is still work in progress for a linux fix? I noticed I am affected by this on 5.2, and the last message I find about this is yours on the arm-kernel list dating back to 9 Nov 2018. Thanks, Nuno

1 0

[PATCH] contrib/jenkins.sh: osmo-fl2k build verification
by Oliver Smith 24 Jul '19

24 Jul '19

Related: OS#3203 Signed-off-by: Oliver Smith <osmith(a)sysmocom.de> --- contrib/jenkins.sh | 18 ++++++++++++++++++ 1 file changed, 18 insertions(+) create mode 100755 contrib/jenkins.sh diff --git a/contrib/jenkins.sh b/contrib/jenkins.sh new file mode 100755 index 0000000..8c3b1cf --- /dev/null +++ b/contrib/jenkins.sh @@ -0,0 +1,18 @@ +#!/bin/sh -ex +# This is how we build on jenkins.osmocom.org. + +CFLAGS="-Werror" + +if ! [ -x "$(command -v osmo-clean-workspace.sh)" ]; then + echo "Error: We need to have scripts/osmo-clean-workspace.sh from osmo-ci.git in PATH!" + exit 2 +fi + +osmo-clean-workspace.sh +cmake \ + -DINSTALL_UDEV_RULES=ON \ + -DCMAKE_C_FLAGS="$CFLAGS" \ + . +make $PARALLEL_MAKE +make DESTDIR="_install" install +osmo-clean-workspace.sh -- 2.11.0

1 0

Receiving UTAs on 978 Mhz
by Yaron Haddi 22 Jul '19

22 Jul '19

2 5

ADS-B reed-solomon ?
by Brad Walker 20 Jul '19

20 Jul '19

I've been studying the rtl_adsb.c code and it's very interesting how it works.. But, I have question. I noticed that if I request verbose output using the "-V" option, then the CRC is printed out. But, it doesn't look like the code actually does any Reed-Soloman error correction to the data the ADS-B specification documents. Am I reading this correctly? Thanks. -brad w.

2 1

Patch submission
by Vincent Perrier 12 Jul '19

12 Jul '19

Fix memory leak in librtlsdr. The problem came up when using rtlsdr_open() twice with the same index. The variable dev->devh is never cleaned if libusb_claim_interface() fails. This causes a leak if the device is already claimed by another handle. rtlsdr_close() did not free that space since the returned handle is invalid if libusb_claim_interface fails Here is the patch file in text format. (it is also joined to this email). ~~~~ diff --git a/src/librtlsdr.c b/src/librtlsdr.c index a71609b..89ec903 100644 --- a/src/librtlsdr.c +++ b/src/librtlsdr.c @@ -1520,10 +1520,6 @@ int rtlsdr_open(rtlsdr_dev_t **out_dev, uint32_t index) r = libusb_claim_interface(dev->devh, 0); if (r < 0) { fprintf(stderr, "usb_claim_interface error %d\n", r); - if (dev) - { - libusb_close(dev->devh); - } goto err; } ~~~~ -Vincent Perrier

1 0

RTL_SDR "output_block_size (default 16*16384)"
by P C 02 Jun '19

02 Jun '19

In RTL_SDR, option -b What does: "output_block_size (default 16*16384)" mean? I have been searching and I just can't find that explained anywhere. Thanks, Pete

2 4

Re: fl2k output voltage level changes every few seconds
by Ioannis Makris 27 May '19

27 May '19

And another thing - the configuration demonstrated on the image you provided is an actual Π (pi) type low pass filter composed by R-L-R elements. There, the individual resistor is 150 ohm, in DC they are parallel, in RF they make a low pass filter along with the coil in btw. Some implementations do not use any coil but a 0-ohm shunt resistor instead. That means the resistors are parallel and they yield 75 ohms. Cheers On Sat, 25 May 2019 at 16:10, Ioannis Makris <makrisj(a)gmail.com> wrote: > I mean that each RGB analog output of the FL2k on the PCB has permanent > fixed terminations of 150 ohm. Still, I need to apologise for having to add > a correction: > > Some of the dongles having only analog output are being terminated @ 75 > ohms at the factory. > > Ref.1: http://www.marsport.org.uk/smd/mainframe.htm > Ref.2: See attached image > > This is normal. Those outputs are most probably open emitter outputs; > hence they need a termination in order to actually produce any current. > Leaving them floating in DC would most probably lead to unexpected and > unaccounted for results. > One could experiment by adding different values for termination or even a > 330 ohms trimmer in rheostat configuration,while maintaining at least an 75 > ohms resistor in series so as to give a range of 75-405 ohms of > termination. > What is to be monitored is the actual spectral behavior of the DAC rather > its maximum output, as there are unwanted spectral elements that could > register as power output on the wanted frequency in conventional needle > meters, when it actually that is far from truth. > Affecting terminations yields intermodulation in amplifiers and unwanted > spectral elements may occur due to several effects I can think of. > Always monitor spectral output if you want to transmit with this thing. > What I've seen is that if you just add 20dB of gain on its output without > applying heavy filtering beforehand you could easily end up to jail for > interfering aviation frequencies used at airports nearby. >

2 1

RFC: osmo-clk-gen v2
by Harald Welte 24 May '19

24 May '19

Hi! due to work overloead I've asked Martin to take over doing the various design changes of osmo-clock-gen towards v2. As the work progresses, we have some questions about your preference. The major changes performed so far in the design: 1) switch from SAMD11 to SAMD21 processor (more flash/ram) https://osmocom.org/issues/3856 We also used the opportunity of having more UARTs available to use a different UART on the UEXT than on the 2.5mm console port. There are no questions here. 2) allow different output voltages for two of the four banks of the Silabs chip https://osmocom.org/issues/3905 * have jumpers in-line of two of the four output banks of the PLL chipc * jumper closed: reference is drawn from one (shared) "other voltage" LDO onboard * jumper open: reference voltage can be provided/injected by user from external reference What's still open to discuss is whether or not the LDO will be fixed (you have to change resistors to change the voltage) or adjustable. In the latter case, we'd apply the DAC output of the SAMD21 as an input to the tracking input of the LDO. However, this would mean that we'd no longer have the DAC output for driving a VCTCXO. Which brings us to 3) should we keep the VCTCXO? I really only placed it in v1 as PCB space was available. Note that while v1 can drive the VCTCXO Control voltrage from the microcontroller, there is no circuitry on board to acually measure/compare/count the output frequency and hence it's not possible to really have a control *loop* as the feedback is missing. That makes it rather useless. So for the v2, we can either a) remove the VCTCXO altogether and use the DAC output for software-modifiable output voltage levels of [some of] the clocks, or b) try to come up with a way to actually count the clock cycles and compare it against some reference. I'm not sure the SAMD21 could do a very good job of that, as I'm assuming that all inputs are sampled to some internal clock and hence experience jitter. I personally would go for 'a', as to me this board/module was always only about the PLL, and not about providing a stable reference itself. I'd much rather have a separate board/module with a GPS-DO, which then provides a 10MHz reference into any number of osmo-clk-gen boards to derive any number of other clocks. Sort of like the good old unix philosophy of doing only one thing in one program and chaining them together. Any thoughts? There's also still to be done: 4) Use SAMD XOSC / PLL / GCLK to allow lower reference frequencies https://osmocom.org/issues/3857 Where we'd actually use one of the SAMD GCLK outputs as one of the intputs to the Si5351C, and expose a GCLK input of the SAMD on an external header. This way, much lower frequencies can be used to driver the Si5351C. Or one could even go for deriving them from the SAMD RTC XTAL. Regards, Harald -- - Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

4 6

← Newer
1
...
16
17
18
19
20
21
22
...
92
Older →

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

osmocom-sdr